Bug 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]

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
--
critical
RESOLVED FIXED
14 years ago
2 years ago

People

(Reporter: Isaac Hwak Han, Assigned: roc)

Tracking

(Depends on: 1 bug, {testcase})

Trunk
x86
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: PLEASE READ COMMENT #133 BEFORE)

Attachments

(5 attachments, 2 obsolete attachments)

(Reporter)

Description

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

Comment 1

14 years ago
Created attachment 129170 [details]
Testcase

Comment 2

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

Comment 4

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

Comment 5

14 years ago
Created attachment 129217 [details]
Testcase #2

Comment 6

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

Comment 8

14 years ago
Created attachment 129238 [details]
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
(Reporter)

Comment 9

14 years ago
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. ***

Updated

14 years ago
Depends on: 126592

Comment 11

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

Comment 12

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

Comment 13

13 years ago
(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

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

Comment 15

13 years ago
*** 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.

Comment 18

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

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

Comment 20

11 years ago
*** Bug 269002 has been marked as a duplicate of this bug. ***
No longer blocks: 269002

Comment 21

11 years ago
Created attachment 249560 [details]
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

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

Updated

10 years ago
Duplicate of this bug: 333994
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: 374980
Duplicate of this bug: 368249

Updated

10 years ago
Duplicate of this bug: 343000

Updated

10 years ago
Duplicate of this bug: 383876

Updated

10 years ago
Duplicate of this bug: 384614
Depends on: 384681

Comment 30

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

Updated

10 years ago
Duplicate of this bug: 397462

Comment 32

10 years ago
Created attachment 284669 [details]
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".
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.

Comment 34

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

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

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

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

Updated

9 years ago
Duplicate of this bug: 418066

Comment 39

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

Updated

9 years ago
Duplicate of this bug: 390454

Updated

9 years ago
Duplicate of this bug: 332756

Updated

9 years ago
Duplicate of this bug: 360724

Updated

9 years ago
Duplicate of this bug: 255706

Updated

9 years ago
Duplicate of this bug: 307405

Updated

9 years ago
Duplicate of this bug: 296368

Updated

9 years ago
Duplicate of this bug: 366162

Updated

9 years ago
Duplicate of this bug: 415411

Comment 48

9 years ago
(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.

Updated

9 years ago
Duplicate of this bug: 425394

Updated

9 years ago
Duplicate of this bug: 427971

Updated

9 years ago
Duplicate of this bug: 428256

Updated

9 years ago
Duplicate of this bug: 431913
There have been a bunch of recent dupes on this: any reason for that? Should it be picking up wanted?

Comment 54

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

Comment 56

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

Updated

9 years ago
Duplicate of this bug: 434546

Updated

9 years ago
Duplicate of this bug: 434686

Comment 59

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

Comment 61

9 years ago
See the last duped bug (bug 434686). 
That's a zipped testcase, platform "All".

Bug 434546 looks better.

Comment 63

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

Updated

9 years ago
Flags: blocking1.9?

Comment 64

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

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

Comment 67

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

9 years ago
(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

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

Comment 70

9 years ago
That is on Windows and Linux where I have tested.

Comment 71

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

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

Comment 73

9 years ago
(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-

Updated

9 years ago
Duplicate of this bug: 435139
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

Comment 77

9 years ago
(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

Updated

9 years ago
Duplicate of this bug: 440300

Updated

9 years ago
Duplicate of this bug: 441251
Flags: wanted1.9.1?

Updated

9 years ago
Duplicate of this bug: 441539

Updated

9 years ago
Blocks: 429134

Comment 81

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

Updated

9 years ago
Duplicate of this bug: 443743
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: wanted-next+

Comment 83

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

Comment 86

9 years ago
(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

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

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

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

Updated

9 years ago
Duplicate of this bug: 440879

Updated

9 years ago
Duplicate of this bug: 353314

Updated

9 years ago
Duplicate of this bug: 366290

Updated

9 years ago
Duplicate of this bug: 291359
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)
Blocks: 440879

Updated

9 years ago
Duplicate of this bug: 429134
No longer blocks: 429134

Updated

9 years ago
Duplicate of this bug: 447802

Updated

9 years ago
Duplicate of this bug: 449020

Updated

9 years ago
Duplicate of this bug: 434024
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)

Updated

9 years ago
Duplicate of this bug: 390952

Updated

9 years ago
Duplicate of this bug: 448511

Updated

9 years ago
Duplicate of this bug: 410871
Duplicate of this bug: 403759
Duplicate of this bug: 451033
Blocks: 333994
No longer blocks: 440879

Updated

9 years ago
Duplicate of this bug: 452946
Alias: big-long
Duplicate of this bug: 448333

Updated

9 years ago
Duplicate of this bug: 455297
Flags: wanted1.9.1-
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-

Updated

9 years ago
Duplicate of this bug: 459555

Updated

9 years ago
Duplicate of this bug: 460565

Updated

9 years ago
Duplicate of this bug: 459602

Updated

9 years ago
Duplicate of this bug: 464473
Duplicate of this bug: 466437

Updated

9 years ago
Duplicate of this bug: 466651

Updated

9 years ago
Duplicate of this bug: 467604

Updated

9 years ago
Duplicate of this bug: 361815

Updated

9 years ago
Duplicate of this bug: 278442

Updated

8 years ago
Duplicate of this bug: 424194

Updated

8 years ago
Duplicate of this bug: 242582

Updated

8 years ago
Duplicate of this bug: 469312

Comment 119

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

Updated

8 years ago
Duplicate of this bug: 471826

Updated

8 years ago
Duplicate of this bug: 474126
Duplicate of this bug: 474342

Comment 123

8 years ago
Created attachment 360485 [details]
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

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

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

Updated

8 years ago
Duplicate of this bug: 480336

Updated

8 years ago
Duplicate of this bug: 482000
Duplicate of this bug: 482668

Updated

8 years ago
Duplicate of this bug: 486557

Updated

8 years ago
Duplicate of this bug: 487798

Updated

8 years ago
Duplicate of this bug: 488532

Comment 132

8 years ago
(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 :((

Updated

8 years ago
Duplicate of this bug: 489105

Updated

8 years ago
Duplicate of this bug: 490693

Updated

8 years ago
Duplicate of this bug: 396382

Updated

8 years ago
Duplicate of this bug: 459584
Depends on: 352093

Updated

8 years ago
Duplicate of this bug: 498605

Comment 141

8 years ago
Created attachment 383461 [details]
A test case of my problem

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
Duplicate of this bug: 503337
Blocks: 470358

Comment 143

8 years ago
This was fixed by bug 352093.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 144

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

Updated

8 years ago
Duplicate of this bug: 221614

Updated

8 years ago
Duplicate of this bug: 511913
Duplicate of this bug: 513626

Updated

8 years ago
Duplicate of this bug: 516463
Duplicate of this bug: 517868
Duplicate of this bug: 518093
Duplicate of this bug: 524377
Duplicate of this bug: 531410

Updated

8 years ago
Duplicate of this bug: 532051
Duplicate of this bug: 538045

Updated

7 years ago
Duplicate of this bug: 531271

Comment 157

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

Updated

6 years ago
Duplicate of this bug: 631753

Updated

2 years ago
Flags: wanted1.9.1-
Flags: blocking1.9.1-
Flags: blocking1.9.0.1-
Flags: blocking1.9-
You need to log in before you can comment on or make changes to this bug.