Opened 12 years ago

Closed 11 years ago

#5626 closed defect (fixed)

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

Reported by: guest Owned by: bill
Priority: high Milestone: 1.2
Component: Dijit Version: 1.0
Keywords: TabContainer, gap Cc:
Blocked By: Blocking:

Description

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?

Attachments (2)

tabs.png (53.0 KB) - added by nonken 12 years ago.
tabs2.png (93.7 KB) - added by nonken 12 years ago.
Same happens to Accordion

Download all attachments as: .zip

Change History (17)

comment:1 Changed 12 years ago by bill

Resolution: worksforme
Status: newclosed

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.

comment:2 Changed 12 years ago by alex

Resolution: worksforme
Status: closedreopened

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

comment:3 Changed 12 years ago by bill

Owner: set to bill
Priority: normalhigh
Status: reopenednew

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.

comment:4 Changed 12 years ago by 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.

comment:5 Changed 12 years ago by 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.

comment:6 Changed 12 years ago by bill

Resolution: fixed
Status: newclosed

(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.

Changed 12 years ago by nonken

Attachment: tabs.png added

comment:7 Changed 12 years ago by nonken

Resolution: fixed
Status: closedreopened

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

Changed 12 years ago by nonken

Attachment: tabs2.png added

Same happens to Accordion

comment:8 Changed 12 years ago by bill

Priority: highnormal

comment:9 Changed 12 years ago by nonken

This also exists in Safari 3.1.

comment:10 Changed 12 years ago by 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.

comment:11 Changed 12 years ago by Tom Trenka

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

comment:12 Changed 12 years ago by Tom Trenka

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

comment:13 Changed 12 years ago by 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.

comment:14 Changed 12 years ago by bill

Milestone: 1.11.2
Priority: normalhigh

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.

comment:15 Changed 11 years ago by bill

Resolution: fixed
Status: reopenedclosed
Summary: gap under TabContainer on themeTester.html (Safari3/mac)TabContainer: gap under TabContainer on themeTester.html (Safari3/mac)

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

Note: See TracTickets for help on using tickets.