Firefox fails to draw charts in jquery UI tabs

Hello, I noticed a strange issue with firefox when using your chart library inside tabs of jquery UI. The chart is rendered correctly on the first tab, however it fails completely on other tabs. I’m using tabsactivate event to create a chart, at this moment tab panel is fully visible. While investigating I see it throws exception NS_ERROR_FAILURE excecuting function getBBox() inside getMaxTickWidth() at line 784:

    function getMaxTickWidth(id) {
        var maxWidth = 0, axisClass = id === 'x' ? CLASS.axisX : id === 'y' ? CLASS.axisY : CLASS.axisY2;
        d3.selectAll('.' + axisClass + ' .tick text').each(function () {
            var box = this.getBBox();
            if (maxWidth < box.width) { maxWidth = box.width; }
        });
        return maxWidth < 20 ? 20 : maxWidth;
    }

I’m using latest firefox v28, however IE9-11 and latest chrome work fine in this case. Please take a look at live example here: http://jsfiddle.net/Lm2e5/4/ Line 784 is not the only one where getBBox() is used, so if I configure to hide axis, exception will be rised in a different place of the code.

I tracked down that jquery UI is not responsible for this exception, because it can be reproduced by toggling visibility of adjanced DIVs. The key is to create a chart and hide it with visibility:none. Then set visibilty:block to nearby DIV and draw a new chart, while the first one is still there hidden in the DOM.

As a temporary workaround I replaced getBBox() with getBoundingClientRect(). It seems to work fine in Firefox, but I can’t understand why getBBox() fails. For instance another D3 based charting library called Dimple also uses getBBox function, but it’s charts work well inside tabs.

[lblb]

Hi Masayuki, thanks for looking into this. I also noticed that IE has problems evaluating getBBox in similar cases, however it returns {0,0,0,0} object instead exception as Firefox. Hence only axis fails to render but not all the chart. So it looks like not a browser bug. I did some further investigation and I believe getBBox should be changed into getBoundingClientRect, because it seems to work pretty well with SVG elements in all modern browsers. Even though it gives large errors for more complex shapes with transformation applied, but it’s still better than getBBox, see example: http://jsfiddle.net/6M5zf/15/ (Unfortunatelly getBBox does not return correct X and Y offsets, so it’s not possible to draw bounding boxes…)

In addition getBoundingClientRect is computed significantly faster: http://jsperf.com/getboundingclientrect-vs-offsetwidth/8

However If you can track down why getBBox fails, probably it would be better to leave it as it is, because it’s a specific function for SVG. In contrast getBoundingClientRect gives different results in different browsers. IE and firefox include stroke width in calculations, however chrome excludes it.

[CHR15-]

Great I’ll give it a shot.