TabContainer: gap under TabContainer on themeTester.html (Safari3/mac)

[guest]

Try ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/layout/test_TabContainer.html There is intermittently a bug where there's a gap under the tab, maybe same issue as #5591?

[bill]

Ugh, can't reproduce this now. Probably same problem as #4058, and could probably be fixed by upping the timer in the code

if(dojo.isSafari){
	// sometimes safari 3.0.3 miscalculates the height of the tab labels, see #4058
	setTimeout(dojo.hitch(this, "layout"), 0);
}

but as for now can't reproduce. If someone else can reproduce then trying changing 0 to 250 and see if it make a difference.

[alex]

I'm seeing this in a bunch of places on Safari 3.0.4 against the linked test page.

[bill]

Must be related to having a built dojo.js file, since it happens for me now too on ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/layout/test_TabContainer.html, but *doesn't* happen on http://dojotoolkit.org/~bill/svn/dijit/tests/layout/test_TabContainer.html. Of course, that's not so surprising as it's the nature of race conditions.

[bill]

On FF I'm seeing a small gap, apparently caused because dojo.css loads too late and thus the font-size: 13px takes effect after the size of the TabController? has been computed. On Safari there's a big gap, presumably because TabContainer?.css float: left on the TabButtons? hasn't loaded when we measure the height, and each button is on a separate line.

[bill]

More notes: On ​the build, the CSS actually loads faster since the @imports are mostly collapsed (everything except dojo.css). However, templates are also inlined into the JS files, which means that widget construction also happens faster. A sort of arms-race between the CSS loading and the JS execution.

On FF test_TabContainer.html, the first TabContainer? in the file is set at height 20em, which at the time TabContainer?.layout() runs is 320px but then presumably after loading dojo.css, it becomes 260px. That problem will probably be lessened when #3887 is fixed but still, need someway to defer TabContainer? startup until all the CSS finishes loading.

[bill]

(In [12703]) Do CSS imports before <script> tags, in order to lessen chance that widgets instantiate before CSS has finished loading. I believe this fixes #5626, #5591. Also removed a few obsolete tests.

[nonken]

I am still finding this error - screenshot attached. Also in my lasy tutorial a comment on ajaxian confirmed the bug :) ​http://ajaxian.com/archives/rounded-tabs-with-dijit#comments

[nonken]

Same happens to Accordion

[nonken]

This also exists in Safari 3.1.

[James Burke]

Maybe try polling for all CSS link nodes on the page and check for existence of linkNode.sheet.cssRules. This is used in the current patch for requireCss in ticket #5402. Note that this test should not be done for Firefox because it will error out if the link node's href is on a different path from the page. But perhaps it is enough to use it to get Safari to work. Although, I'm not sure that the existence of cssRules means the rules have been applied. It may or may not. Just have not had a good test to know one way or the other.

[Tom Trenka]

(In [13148]) Temporary fix for #5626 by forcing Safari to resize itself. !strict, refs #5626.

[Tom Trenka]

(In [13149]) *Really* Temporary Ugly Fix for #5626 by forcing Safari to resize itself. !strict, refs #5626.

[Tom Trenka]

(In [13157]) A fix for the *Really* Temporary Ugly Fix(tm), forcing Safari to resize itself; connect to window.onload instead of using dojo.addOnLoad. !strict, refs #5626.

[bill]

Move all milestone 1.1 tickets to 1.2, except for reopened tickets and tickets opened after 1.1RC1 was released.

Note that the fixes above ([13148], [13149], and [13157]) may not be necessary, as the test files are "incorrect" in that they load dojo.js before loading the CSS files, whereas the recommended way is to the opposite. The test files do it strangely to allow on-the-fly theme switching w/out benefit of a server.

[bill]

Fixed by [13696], thanks dante! (This is another ticket that should have been closed automatically but wasn't)