Ticket #5626 (closed defect: fixed)

Opened 7 months ago

Last modified 3 months ago

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
Severity: normal Keywords: TabContainer, gap
Cc:

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

tabs.png (53.0 kB) - added by nonken 6 months ago.
tabs2.png (93.7 kB) - added by nonken 6 months ago.
Same happens to Accordion

Change History

Changed 7 months ago by bill

  • status changed from new to closed
  • resolution set to worksforme

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.

Changed 6 months ago by alex

  • status changed from closed to reopened
  • resolution deleted

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

Changed 6 months ago by bill

  • priority changed from normal to high
  • owner set to bill
  • status changed from reopened to new

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.

Changed 6 months 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.

Changed 6 months 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.

Changed 6 months ago by bill

  • status changed from new to closed
  • resolution set to fixed

(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 6 months ago by nonken

Changed 6 months ago by nonken

  • status changed from closed to reopened
  • resolution deleted

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 6 months ago by nonken

Same happens to Accordion

Changed 6 months ago by bill

  • priority changed from high to normal

Changed 5 months ago by nonken

This also exists in Safari 3.1.

Changed 5 months ago by jburke

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.

Changed 5 months ago by ttrenka

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

Changed 5 months ago by ttrenka

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

Changed 5 months ago by ttrenka

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

Changed 5 months ago by bill

  • priority changed from normal to high
  • milestone changed from 1.1 to 1.2

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.

Changed 3 months ago by bill

  • status changed from reopened to closed
  • resolution set to fixed
  • summary changed from gap under TabContainer on themeTester.html (Safari3/mac) to 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.