User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20080311 Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20080311 Firefox/188.8.131.52 When loading the supplied URL most of the page is blank. Others running builds form 3/26 and 3/28 can't repro the problem. If you change between windowed/maximized or resize the window the rendering is repaired. If you use the tab key to change focus between widgets the widgets move into what little content area is rendered. I will attempt to attach a screen shot in a few minutes. Reproducible: Always Steps to Reproduce: 1.load referenced URL 2. 3. Actual Results: See details Expected Results: fully rendered window
This is a recent regression. From an e-mail Pete sent me, the 3/28 build was still OK. Pete, do you have an exact build date when this broke?
Version: unspecified → Trunk
Marco, I don't. The only thing I can tell you is that I first noticed it on April 8 which is the first time I tried this application. I always refresh my build before I do anything so I didn't try it on whatever version of Minefield I had before that.
I see it as well. If I force a reflow by pressing Ctrl+plus or resizing the page everything suddenly shows up.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Aaron, What machine are you running? Mine is a T61. Others are not seeing it so it might be a hardware interaction.
I'm also running a T61, but I'm skeptical about the hardware connection anyway. I haven't heard of layout bugs depending on that.
Major clue -- the bug does not happen if I reset this pref: general.useragent.extra.firefox = Minefield/3.0pre I had changed it to Firefox/3.0pre
This coule be a Dojo bug actually, because the regression occured when you changed your user agent string, right? When I change my string back to Minefield it works again. So I think Dojo is doing something wrong when the user agent string says Firefox 3. I would go back to older versions of Firefox 3 betas and see if the same problem occurs.
I get the same behavior, i.e. no problem when Minefield is in the string. FF3 builds back from 3/26 and 3/28 do not fail, but these reports come from those running on other machines. Also, changing the code to use the BorderContainer layout widget instead of the LayoutContainer and SplitContainer also cause the problem to disappear as can seen at http://becky.dojotoolkit.org/DOJOtest_041108/Testcase/MainTree.html The use of LayoutContainer/SplitContainer is at http://becky.dojotoolkit.org/DOJOtest_032608/Testcase/MainTree.html I opened dojo ticket http://trac.dojotoolkit.org/ticket/6514 and cross referenced this one - until someone figures out which code contains the bug.
Not sure what's up w/the version string thing but this is surely one of the typical race conditions we see (in both firefox and safari), racing between: 1) downloading JS 2) downloading CSS 3) browser initialization In this case during our initialization, FF tells us that the size of the outer <div> (which is supposed to be the size of the browser window) is height=88px. (Of course if you query again a second later you get the right answer.) Not sure what to do about that. The obvious workaround is to add a timer or at least a timer to check if the size of that div has changed, but would be nice to find a real solution.
Will using document.height fix it for you?
More specifically, I haven't tried it, but I suspect the doc container always knows its height, but the contents don't know their height until they are rendered (which is asynchronous). A timer might do it but I'd be nervous that it would fail in some case.
I bet using document.height would fix this case but the problem is that (at least theoretically) we want to support something like: <body style="height: 100%";> <div style="height: 90%; width: 90%"> ... ... in which case the div is obviously shorter and narrower than the viewport. The other idea is to get sizing on the real document load event (like in <body onload="...">), rather than DomContentLoaded, but I guess you are saying that's not guaranteed either (just lessens the race condition perhaps)?
If you set a timeout of 0 after onload, I think everything will have been rendered. Also probably true for a 0 timeout after DOMContentLoaded, except that images and plugins won't have been rendered yet. I *believe* those things to be true :) More research would be needed.
Well, it's a working theory. Would you happen to know about CSS loading, whether the CSS (including CSS files included by other CSS files) are guaranteed to be loaded by the time that setTimeout(..., 0) fires?
I would say it's only guaranteed if the CSS is in that HTML file -- iow not an external file that's linked to. But, the best thing would be to check the main Mozilla newsgroups or developer.mozilla.org or #developers on IRC. I'm just the a11y guy :)
The link from testcase is not available anymore. Is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E). Thanks.
Marking this as Resolved: Incomplete due to the lack of response from the reporter. If anyone can still reproduce it on latest versions, feel free to reopen the issue and provide more information.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.