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

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Isaac Hwak Han]

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.

Comment 1

[Isaac Hwak Han]

Attachment: Testcase

Comment 2

[Mats Palmgren (inactive)]

WFM, 2003-08-01-05 trunk Linux

Comment 3

[Christian 'CeeJay' Jensen]

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

Comment 4

[Mats Palmgren (inactive)]

*** Bug 215108 has been marked as a duplicate of this bug. ***

Comment 5

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 6

[Mats Palmgren (inactive)]

Confirming bug, 2003-08-04-05 trunk Linux using Testcase #2.
The first testcase seems to work on Linux.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 8

[Isaac Hwak Han]

Attachment: 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.

Comment 9

[Isaac Hwak Han]

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

Comment 10

[Mats Palmgren (inactive)]

*** Bug 228560 has been marked as a duplicate of this bug. ***

Comment 11

[Greg Childers]

Here is what I believe is another real world test case: 
http://chroma.mine.nu/zooi/impstats.php?id=35 

Comment 12

[Isaac Hwak Han]

*** Bug 235911 has been marked as a duplicate of this bug. ***

Comment 13

[James Napolitano]

(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

Comment 14

[James Napolitano]

*** Bug 193209 has been marked as a duplicate of this bug. ***

Comment 15

[gavin long]

*** Bug 268959 has been marked as a duplicate of this bug. ***

Comment 16

[Uri Bernstein]

*** Bug 274738 has been marked as a duplicate of this bug. ***

Comment 17

[Uri Bernstein]

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.

Comment 18

[Felix Miata]

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.

Comment 19

[Brian Polidoro]

*** Bug 313670 has been marked as a duplicate of this bug. ***

Comment 20

[James Napolitano]

*** Bug 269002 has been marked as a duplicate of this bug. ***

Comment 21

[James Napolitano]

Attachment: a testcase from a bug dupped to this one

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.

Comment 22

[James Napolitano]

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

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Changing summary and making this the dup target of all 16-bit widget coordinate bugs...

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The compositor will fix this by removing child widgets...

Comment 30

[Aaron Rister]

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?

Comment 32

[James Justin Harrell]

Attachment: problem on jump, but not scroll

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

Comment 33

[James Justin Harrell]

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.

Comment 34

[Baldvin Kovács]

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?

Comment 35

[Thomas Zumbrunn]

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.

Comment 36

[Baldvin Kovács]

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

Comment 37

[Baldvin Kovács]

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.

Comment 39

[Alexis Wilke]

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

Comment 48

[Thomas K. (:tom)]

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

Comment 53

[Mike Beltzner [:beltzner, not reading bugmail]]

There have been a bunch of recent dupes on this: any reason for that? Should it be picking up wanted?

Comment 54

[Andrew Schultz]

the dupe I filed (bug 415411) did not manifest itself until we switched to cairo

Comment 55

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't know why there would be new dups. We really can't do anything for 1.9.

Comment 56

[David Greenspan]

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.

Comment 59

[Deven Phillips]

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.

Comment 60

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What specific page and platform are you seeing this on?

Comment 61

[Brian Polidoro]

See the last duped bug (bug 434686). 

Comment 62

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That's a zipped testcase, platform "All".

Bug 434546 looks better.

Comment 63

[Deven Phillips]

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.

Comment 64

[Deven Phillips]

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?!?!

Comment 65

[David Greenspan]

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.

Comment 66

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't see this problem on Mac, but I do see it on Windows.

Comment 67

[Deven Phillips]

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.

Comment 68

[Wladimir Palant]

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

Comment 69

[Deven Phillips]

It does work in FF2 on the test case I submitted. I have no problems viewing that page on FF2.

Comment 70

[Deven Phillips]

That is on Windows and Linux where I have tested.

Comment 71

[Radek 'sysKin' Czyz]

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.

Comment 72

[Radek 'sysKin' Czyz]

Oops, apologies for bugspam, not FF 1.5alpha but Mozilla 1.5 alpha, which means firebird ~0.6

Comment 73

[Daniel.S]

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

Comment 74

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 76

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

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

Comment 77

[RNicoletto]

(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

Comment 81

[Zeno-McDohl]

Real world case:
http://www.mudbytes.net/index.php?a=files&s=displayfile&fid=943&d=smaug1.8/src/&f=smaug1.8/src/comm.c

Still happens in Fx3.

Comment 83

[Chris Tyler]

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

Comment 84

[Martijn Wargers (dead)]

Would it be possible to secretly make those elements be overflow: visible when those overflow:auto/scroll divs exceed the 16-bit coordinate?

Comment 85

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

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?

Comment 86

[Cheba]

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

Comment 87

[henryfhchan]

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.

Comment 88

[henryfhchan]

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.

Comment 89

[James Napolitano]

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.

Comment 94

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

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.

Comment 119

[IU]

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.

Comment 123

[Faisal Abdul Moid]

Attachment: Rows of the table gets hidden within the div (overflow!=visible)

Rows of the table gets hidden within the div whose overflow!=visible, this bug is not present in Chrome and IE7 or above

Comment 124

[Leandro]

Unbelievable, this bug was reported more than five years ago and has no solution! I suggest mozilla get help with Google Chrome team.

Comment 125

[Brian Polidoro]

Are you volunteering to contribute a fix?  If not then your comment is superfluous.

Comment 132

[booc0mtaco]

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

Comment 133

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 134

[Radek 'sysKin' Czyz]

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?

Comment 135

[Radek 'sysKin' Czyz]

Uh, my previous comment was wrong (I was so sure!). I am very very sorry for the bugspam which I just added :((

Comment 141

[cyril.masset]

Attachment: A test case of my problem

Unzip it and open the "resultats.htm" file. Scroll down and see what's happening !!

Comment 143

[Sander]

This was fixed by bug 352093.

Comment 144

[Syophone]

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

Comment 145

[Ryan VanderMeulen [:RyanVM]]

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

Comment 157

[soget]

https://bugzilla.mozilla.org/show_bug.cgi?id=280661