Closed Bug 215055 (big-long-large-32767) Opened 21 years ago Closed 15 years ago

(PLEASE READ COMMENT #133) Content of tall pages is clipped and can't be displayed if overflow!=visible [16 bit widget coordinates]

Categories

(Core :: Web Painting, defect)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: isaachh, Assigned: roc)

References

Details

(Keywords: testcase, Whiteboard: PLEASE READ COMMENT #133 BEFORE)

Attachments

(5 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718

A block-element with overflow: scroll or overflow:auto is rendered incorrectly,
if its (rendered) height exceeds a certain threshold value.

Reproducible: Always

Steps to Reproduce:
1. Open the testcase in Browser.
2. Scroll toward the end of the page by dragging mouse on the (browser's
default) vertical scroll bar.
3. and/or jump to the end of the page by pressing END key.
Actual Results:  
If scrolled by mouse, at some point around number 1000 (dependent of Browser UI
setting), the screen shows many garbled text which resembles the last correctly
rendered line.
If jumped by END key, the viewport remains the same.

Expected Results:  
Because the PRE element in the testcase has no parent element with constrained
height, Browser should render the same result rendered with overflow: visible
style applied.

Alt-tabbing or task switching to other window and getting back to the testcase
window, also causes the similar problem.
Attached file Testcase (obsolete) —
WFM, 2003-08-01-05 trunk Linux
Keywords: testcase
I can reproduce this bug in :
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030803 Mozilla
Firebird/0.6.1
*** Bug 215108 has been marked as a duplicate of this bug. ***
Attached file Testcase #2 (obsolete) —
Confirming bug, 2003-08-04-05 trunk Linux using Testcase #2.
The first testcase seems to work on Linux.
Assignee: block-and-inline → roc+moz
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Layout: Block & Inline → Layout: View Rendering
Ever confirmed: true
OS: Windows XP → All
This is a duplicate of one of my existing bugs. I think. I know what the problem
is, anyway ... native widgets that only support 16-bit coordinates.
Attached file Testcase #3
Mr. O'Callahan possibly mean Bug 126592. I doubt this bug is a dup of it,
because all testcases of Bug 126592 work fine for me (on Windows XP).

However, after some more experiments, the accurate starting point of damaged
viewport is 16384 pixel height, which is absolutely related with 16-bit
coordinates.

Here's a revised testcase modified from attachment 129170 [details] (testcase #1) , to
hopefully make it platform-independent.
Attachment #129170 - Attachment is obsolete: true
Sorry for spamming but here are two real-world testcases. Both pages have BODY
element with overflow:auto. (They are Korean pages and you may need Korean font
for proper viewing.) 

http://www.baldursgate2.co.kr/zero/zboard.php?id=forum&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=395
http://dnd3.nalove.org/cgi-bin/technote/read.cgi?board=dnd3&y_number=2&nnew=2
*** Bug 228560 has been marked as a duplicate of this bug. ***
Depends on: 126592
Here is what I believe is another real world test case: 
http://chroma.mine.nu/zooi/impstats.php?id=35 
*** Bug 235911 has been marked as a duplicate of this bug. ***
(In reply to comment #8)
> However, after some more experiments, the accurate starting point of damaged
> viewport is 16384 pixel height, which is absolutely related with 16-bit
> coordinates.

I have been working on bug 193209 (which should be marked as a dup of this bug),
and found the exact same thing, problems after 16,384 = 2^14 pixels.  You might
want to take a look at that bug for some alternate discussion, screenshots, and
my testcase.

> Mr. O'Callahan possibly mean Bug 126592. I doubt this bug is a dup of it,
> because all testcases of Bug 126592 work fine for me (on Windows XP).

There were two related bugs Mr. Callahan worked on.  Bug 164625 was for windows
which are less than 30000 pixels high and was supposed to have been fixed on all
platforms; bug 126592 only happens with windows that are at least 30000 pixels
high and is supposed to only remain for Win 9.x systems.

Neither of those bugs seems to fit what we are seeing, as they don't involve
overflow:scroll.  Also, our bug affects Windows XP and Linux, not just Win 9.x
systems.  Just as with you, the testcases in bug 126592 WFM but the ones here do
not, and there are no testcases for bug 164625.

BTW, my user agent string is 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:) Gecko/20040302
*** Bug 193209 has been marked as a duplicate of this bug. ***
*** Bug 268959 has been marked as a duplicate of this bug. ***
Blocks: 269002
*** Bug 274738 has been marked as a duplicate of this bug. ***
On Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6)
Gecko/20041216 Firefox/1.0+, This has the additional effect that after scrolling
down and up a bit (e.g. on testcase #2), the scrollbar "freezes" (can't be moved
anymore), and the main viewing area does not update when switching tabs, going
back/forward, etc. (only the window title does).
This makes this a potential dataloss bug.
Testcase 3 corrupts at line 1638 on XP 1.7.8 at 1600x1200, and at line 950 on
OS/2 trunk at 1280x960.

http://www.ubuntuguide.org/ seems likely to be another in the wild testcase,
with 4 classes using overflow: auto in http://www.ubuntuguide.org/style.css, and
a HTML filesize of ~180K. To see the problem may require zooming or a minimum
font size set.

But, it seems if it sniffs a M$ US string that your IP gets redirected to an
unrelated site at http://67.15.97.2. I loaded it in OS/2 and Linux successfully
before trying XP, but XP couldn't locate http://www.ubuntuguide.org/, and now
neither can OS/2 or Linux.

I saved to disk before being blocked. OS/2 displays gray like in the #3 testcase
in inappropriate places, while XP displays various white backgrounds with no
visible content in those areas. Commenting overflow: auto out of the local css
eliminates the corruption.
*** Bug 313670 has been marked as a duplicate of this bug. ***
*** Bug 269002 has been marked as a duplicate of this bug. ***
No longer blocks: 269002
This testcase is essentially the same as the last, but uses multiple <br> tags instead of one huge <pre> so it is easier to measure positions with the Dom Inspector.
(In reply to comment #18)
> Testcase 3 corrupts at line 1638 on XP 1.7.8 at 1600x1200, and at line 950 on
> OS/2 trunk at 1280x960.
> 

On Gecko 1.9alpha1 with WinXP at 1280x1024, this bug still occurs, and I also get corruption just after line 1638.  Using the DOM Inspector, line 1638 lies almost at a position of 32768, or 32K pixels.  Note that testcase 3, from 3 years ago, says corruption occurs at line 819, which is half of 1638.  Apparently before the problem occurred at 16K pixels, but now it is occurring at 32K.

I'm modifying bug summary slightly to make finding this bug easier.
Severity: major → normal
Summary: incorrect rendering of a vertically long block-level element with overflow: scroll/auto → incorrect rendering of a vertically long block-level element with overflow: scroll or overflow:auto
Changing summary and making this the dup target of all 16-bit widget coordinate bugs...
Summary: incorrect rendering of a vertically long block-level element with overflow: scroll or overflow:auto → incorrect rendering of a tall element with overflow: scroll or overflow:auto (16-bit widget coordinates)
The compositor will fix this by removing child widgets...
Depends on: compositor
Another example in the wild: http://forums.sinsofasolarempire.com/?forumid=440&aid=155859&p=1

div.Main_Body_Region2 stops drawing content after 32768px.

Any progress with a fix for this issue?
This testcase shows a bug that only occurs when jumping around the page, like when clicking an anchor that links to an #id. Just scrolling doesn't show any problems.

Also, on Firefox 2.0 and a recent trunk build of Firefox 3.0 (both on Ubuntu 7.04), Testcase #3 immediately crashes the browser. Due to that, shouldn't this be marked as critical, or at least major? A bug that causes a crash is more severe than just "normal".
Severity: normal → critical
A lot of blog archive pages suffer from this problem. Example:
http://sciencetrack.blogspot.com/2007_07_01_archive.html

While scrolling with the scrollbar, the problem flashes on and off. When I stop scrolling, the page sometimes looks fine, and sometimes is badly corrupted. When I use the scroll wheel, it's always badly corrupted.
I am working on an extension where I need very tall <browser/> xul elements.
I had some freezing problems on MacOS X Leopard, then I assembled a 
trivial test
page: <a href="http://thiblo.com/~baldvin/prg/mozilla/iframe32768/">http://thiblo.com/~baldvin/prg/mozilla/iframe32768/</a>.

Could somebody please check it out, and tell me if that is this bug, or that is
and other one?
just tested under windows vista ultimate Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 and had no issues seems to work ok from here I've ended up to activate the scrolling when the size goes over 32768 to be sure that I've no issues.
Anybody who could test it on MacOS X, please? On vista, the situation is much 
better. The extension I am working on is not freezing at least (though displays
just black after 32768 pixels). But on MacOS X I am experiencing freezes, which
I thing might be related to the test case I have linked in.

Thanks, Baldvin
Update: I have tested it with Firefox 3 beta 2 for MacOS X, and the bug did
not appear. Also, the freezes with the extension I am implementing have
disappeared. So I guess I will just make my extension windows-only for firefox 2,
and roll it out for macintosh just from firefox version 3.
Quick note:

I updated my SeaMonkey to 1.1.8 not too long ago and its date could suggest that it would have included this bug fix. But no, it is still bogus. The bottom of the table still breaks in this version.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8
(In reply to comment #37)
> Update: I have tested it with Firefox 3 beta 2 for MacOS X, and the bug did
> not appear. Also, the freezes with the extension I am implementing have
> disappeared. So I guess I will just make my extension windows-only for firefox
> 2,
> and roll it out for macintosh just from firefox version 3.
> 

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008032604 Minefield/3.0b5pre

I just tested all the valid testcases and they all work just fine, so yeah.
There have been a bunch of recent dupes on this: any reason for that? Should it be picking up wanted?
the dupe I filed (bug 415411) did not manifest itself until we switched to cairo
I don't know why there would be new dups. We really can't do anything for 1.9.
This is really a huge and inexcusable bug.

Is there no way it can be fixed on its own, now?  The fact that it will be resolved when the brand-new "Compositor" reaches production is not the comfort I was looking for.

I would be more comfortable if someone could explain what the timeline is for the Compositor, and why this bug is too difficult to fix independently of that large rewrite.
Honestly, this should be a show-stopper for 3.0. I cannot use Firefox in this state. We have a large number of Wiki pages which cannot be modified to account for this bug. There are a number of pre-build applications which will not work with Firefox unless this is fixed. The primary example I would give is XWiki, but I have also seen this in OpenNMS. A great number of people are not going to have the expertise required to modify the appropriate style-sheets to make their applications work. Also, we should not expect application developers to work around the bugs in Firefox on a major release.
What specific page and platform are you seeing this on?
See the last duped bug (bug 434686). 
That's a zipped testcase, platform "All".

Bug 434546 looks better.
I am seeing this on Windows and Linux. This happens on any page with "overflow: auto" where the length is over 120KB. I am seeing this happen in canned applications like OpenNMS, XWiki, MediaWiki, etc.... If this gets released, we're going to have a lot of end users (like me!) very annoyed.
Flags: blocking1.9?
I suppose that technically, I could go in and modify the CSS for XWiki (etc...) to not use "overflow: auto", but what about other users who are not as technically adept or do not have access to modify the sites that they are viewing?!?!
To be clear, the behavior I observed is that drawing goes haywire when a scrolling view becomes more than 32767 pixels tall or wide (in my case it's in design mode).  I've observed this on Mac and Windows, and I'm not aware of a workaround.
I don't see this problem on Mac, but I do see it on Windows.
The people tracking the compositor bug have made it clear that it will not be
possible for 1.9, so, it seems to me that it would be advisable to find a fix
that does not rely on the compositor for 1.9. This works in FF2.x, so there
must be a method to work around this.
(In reply to comment #67)
> This works in FF2.x, so there must be a method to work around this.

This bug is much older than FF2. The testcase you attached to bug 434686 doesn't work properly in FF2 either (on Windows), so it isn't a regression. If you don't have lots of angry end users yet, you won't get them once FF3 is released either. And by that I don't mean that this bug shouldn't be fixed, but pushing it for 1.9 is unrealistic.

Strange enough, bug 307405 that was duped against this one is fixed in the current nightly (both example page and minimized testcase work fine).
It does work in FF2 on the test case I submitted. I have no problems viewing that page on FF2.
That is on Windows and Linux where I have tested.
If you have something that regressed between 2.0 and 3.0, it's a new bug. This bug was filed against firefox 1.5 alpha.
Oops, apologies for bugspam, not FF 1.5alpha but Mozilla 1.5 alpha, which means firebird ~0.6
(In reply to comment #53)
> There have been a bunch of recent dupes on this: any reason for that? Should it
> be picking up wanted?

Ah, no. It was mostly me trying to do some Bugzilla cleanup. But yeah, this bug gets a dupe every once in a while. Too bad it won't make 1.9.1.

(In reply to comment #68)
> Strange enough, bug 307405 that was duped against this one is fixed in the
> current nightly (both example page and minimized testcase work fine).

Is that the bug you meant? The second attachment doesn't work (or to be exact only works in certain cases) in Fx3RC1 which should be identical to the latest nightly.
Minusing based on roc's repeated comments about how nothing can be done here in the 1.9.0.x codebase, adding wanted-next to indicate that we'll look at this for a future platform release.
Flags: wanted-next+
Flags: blocking1.9?
Flags: blocking1.9.0.1-
Flags: blocking1.9-
Currently I can reproduce the bug with the testcase #3 - https://bugzilla.mozilla.org/attachment.cgi?id=129238 - at line 1638. 

I can reproduce it also with jump testcase - https://bugzilla.mozilla.org/attachment.cgi?id=284669 - setting the height equal to 17,895,463 pixels. Notice than max height of a div is 17,895,697 (hex 1111111), so it's not a great problem...

Testcase #2 is now obsolete, since it's not high enough.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008060906 Minefield/3.0pre
Attachment #129217 - Attachment is obsolete: true
(In reply to comment #76)
> Currently I can reproduce the bug with the testcase #3 -
> https://bugzilla.mozilla.org/attachment.cgi?id=129238 - at line 1638. 
> 
> I can reproduce it also with jump testcase -
> https://bugzilla.mozilla.org/attachment.cgi?id=284669 - setting the height
> equal to 17,895,463 pixels. Notice than max height of a div is 17,895,697 (hex
> 1111111), so it's not a great problem...
> 
> Testcase #2 is now obsolete, since it's not high enough.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008060906
> Minefield/3.0pre
> 

Confirmed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061505 Minefield/3.0pre
Flags: wanted1.9.1?
Blocks: 429134
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: wanted-next+
The Smooth Scroll option has an effect here -- toggling it off seems to resolve artifact issues (tested against http://planet.fedoraproject.org/ which is usually a very long page).
Would it be possible to secretly make those elements be overflow: visible when those overflow:auto/scroll divs exceed the 16-bit coordinate?
I don't think it's a good idea. See this for example (derived from testcase 3):
http://pazziaumana.netsons.org/example.html
If you turn overflow to visible, this example can't be scrolled.

A mad idea: can't the value type be changed to unsigned long int only when Firefox really need it, instead of change the default type for all height values?
(In reply to comment #83)
> The Smooth Scroll option has an effect here -- toggling it off seems to resolve
> artifact issues (tested against http://planet.fedoraproject.org/ which is
> usually a very long page).
> 

I can reproduce this bug with Smooth Scroll option turned off in ff 3.1 nightly on the example provided by Lucas Malor.
with attachment https://bugzilla.mozilla.org/attachment.cgi?id=284669#body ,
i get the box staying right as if the separator was only 0px high after setting the separator larger than 17895697px.

with testcase https://bugzilla.mozilla.org/attachment.cgi?id=249560, I get 1725 half cut off.  When I attempt to select the numbers and drag over the cut off part, the page 'jump' to the top.  However, if I drag from where it was cut off (in a blank space) and end my drag at 1724 or lower, and press CTRL+C,  I get all the numbers!

With other testcases other than the first two, I get a big black box instead of something white, and letters are cut much earlier, around 1600.
Oh, and, shrinking the page zoom feature twice, makes http://planet.fedoraproject.org/ show properly.

Shrinking fonts once also corrects it.

If I don't do anything, and I scroll super quick down the end with scrollwheel or dragging the knob, I see an extra right pointing scrollbar arrow at the bottom of the page, exactly next to the down scrollbar arrow, and it's clickable!  Clicking on it draws two horizontal black lines that run from the left of the window and right of the window: one on the top of the button and one under it.

That shows it's much more complicated.
Please, no more testcases, confirmations, or advocacy. This bug has already been confirmed and is on the developers' radars; they know what the underlying problem is and how best to fix it. Unfortunately no fix can be made for any Firefox 3.0.x release. Any further comments that do not contribute to a fix simply pile up in developers' inboxes (affectionately called "bug spam"), distracting them from their work and often leading them to just unsubscribe from the bug's CC list.
Whiteboard: Please read Comments #74 and #89 before commenting
I change the title a bit, hoping duplicates will be fewer.

I add the request for 3.1 blocking, too much reports and troubles with this bug. A patch before Bug 374980 landing seems to me highly desirable.
Flags: blocking1.9.1?
Summary: incorrect rendering of a tall element with overflow: scroll or overflow:auto (16-bit widget coordinates) → Content of tall pages is clipped and can't be displayed if overflow!=visible (16 bit widget coordinates)
Summary: Content of tall pages is clipped and can't be displayed if overflow!=visible (16 bit widget coordinates) → Content of tall pages is clipped and can't be displayed if overflow!=visible [16 bit widget coordinates] (big-long)
Flags: wanted1.9.1-
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
I this bug the same thing affecting this page?: http://blogs.orlandosentinel.com/features_orlando/2007/10/new-chef-at-jik.html

Click on the image of the woman and notice it doesn't show the full length.  Compare with IE which does.
Rows of the table gets hidden within the div whose overflow!=visible, this bug is not present in Chrome and IE7 or above
Unbelievable, this bug was reported more than five years ago and has no solution! I suggest mozilla get help with Google Chrome team.
Are you volunteering to contribute a fix?  If not then your comment is superfluous.
(In reply to comment #89)
> Please, no more testcases, confirmations, or advocacy. This bug has already
> been confirmed and is on the developers' radars; they know what the underlying
> problem is and how best to fix it. Unfortunately no fix can be made for any
> Firefox 3.0.x release. Any further comments that do not contribute to a fix
> simply pile up in developers' inboxes (affectionately called "bug spam"),
> distracting them from their work and often leading them to just unsubscribe
> from the bug's CC list.

Out of curiosity, what prevents a fix to the 3.0.x versions? And, would this be possible to be fixed in a 3.x release if one is planned? I have some naive assumptions in my head, but would sooner ask than assume. If there is a resource which explains how/when changes get put into firefox releases, a link to this might also be of assistance.
Were it not for all the bugspam hiding the useful information in this bug, the answer to your question would have been easier to find :-(.

Comment #7 and comment #25 answer your question. Native widgets only support 16-bit coordinate space. The solution is to remove the use of them, which requires roc's Compositor, which is a massive code overhaul. The scope of the changes required for the Compositor make it unsuitable for 3.0.x or 3.5.x inclusion. As it stands right now, the Compositor *may* land for Gecko 1.9.2, which will be the basis for whatever version of Firefox comes after 3.5.x, but even that is not guaranteed at this point in time.

If you want to follow the progress on the Compositor, CC yourself to bug 374980. Please refrain from commenting in that bug, though, so it doesn't turn into the tangled mess this bug has become.
The only information effectively missing from this bug is why most of the symptoms are a regression from Mozilla 1.8. This bug was almost silent until Firefox 3 because it was relatively hard to find examples of it before 1.9.

Most of the dups are for the regression from Firefox 2, not for underlying problem.

It's something I don't know myself either - is it because the 16-bit coordinates now store units smaller than pixels, or something like that?
Uh, my previous comment was wrong (I was so sure!). I am very very sorry for the bugspam which I just added :((
Unzip it and open the "resultats.htm" file. Scroll down and see what's happening !!
Alias: big-long → big-long-large-32767
Summary: Content of tall pages is clipped and can't be displayed if overflow!=visible [16 bit widget coordinates] (big-long) → (PLEASE READ COMMENT #133) Content of tall pages is clipped and can't be displayed if overflow!=visible [16 bit widget coordinates]
Whiteboard: Please read Comments #74 and #89 before commenting → PLEASE READ COMMENT #133 BEFORE
This was fixed by bug 352093.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Is this fix included in 3.6.2pre?
It seems that some page could not show well without overflow=visible

http://www.hkepc.com/forum/viewthread.php?tid=1209429
(Assuming you meant 3.5.2pre, not 3.6.2pre) The fix for this bug landed on the trunk for what will become Firefox 3.6. It will not be included in any Firefox 3.5.x version.
Flags: wanted1.9.1-
Flags: blocking1.9.1-
Flags: blocking1.9.0.1-
Flags: blocking1.9-
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.