lots of unrendered space on page

RESOLVED INCOMPLETE
(NeedInfo from)

Status

()

--
major
RESOLVED INCOMPLETE
11 years ago
2 years ago

People

(Reporter: pete, Unassigned, NeedInfo)

Tracking

({regression})

Trunk
x86
Windows XP
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

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
(Reporter)

Comment 1

11 years ago
Created attachment 314925 [details]
rendering bug shown in this PNG
(Reporter)

Comment 2

11 years ago
Created attachment 314926 [details]
proper rendering is shown in this PNG

Comment 3

11 years ago
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?
Keywords: regression
Version: unspecified → Trunk
(Reporter)

Comment 4

11 years ago
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.

Comment 5

11 years ago
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

Updated

11 years ago
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
(Reporter)

Comment 6

11 years ago
Aaron, What machine are you running?  Mine is a T61.  Others are not seeing it so it might be a hardware interaction.

Comment 7

11 years ago
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.

Comment 8

11 years ago
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

Comment 9

11 years ago
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.
(Reporter)

Comment 10

11 years ago
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.

Comment 11

11 years ago
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.

Comment 12

11 years ago
Will using document.height fix it for you?

Comment 13

11 years ago
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.

Comment 14

11 years ago
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)?

Comment 15

11 years ago
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.

Comment 16

11 years ago
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?

Comment 17

11 years ago
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.
Flags: needinfo?(pete)
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.