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)
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.
Reporter | ||
Comment 1•21 years ago
|
||
Comment 3•21 years ago
|
||
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•21 years ago
|
||
*** Bug 215108 has been marked as a duplicate of this bug. ***
Comment 5•21 years ago
|
||
Comment 6•21 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
Assignee | ||
Comment 7•21 years ago
|
||
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•21 years ago
|
||
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•21 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
Comment 10•21 years ago
|
||
*** Bug 228560 has been marked as a duplicate of this bug. ***
Comment 11•21 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•21 years ago
|
||
*** Bug 235911 has been marked as a duplicate of this bug. ***
Comment 13•21 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•21 years ago
|
||
*** Bug 193209 has been marked as a duplicate of this bug. ***
Comment 15•20 years ago
|
||
*** Bug 268959 has been marked as a duplicate of this bug. ***
Comment 16•20 years ago
|
||
*** Bug 274738 has been marked as a duplicate of this bug. ***
Comment 17•20 years ago
|
||
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•19 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•18 years ago
|
||
*** Bug 313670 has been marked as a duplicate of this bug. ***
Comment 20•18 years ago
|
||
*** Bug 269002 has been marked as a duplicate of this bug. ***
No longer blocks: 269002
Comment 21•18 years ago
|
||
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•18 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
Assignee | ||
Comment 24•17 years ago
|
||
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)
Assignee | ||
Comment 25•17 years ago
|
||
The compositor will fix this by removing child widgets...
Depends on: compositor
Depends on: 384681
Comment 30•17 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?
Comment 32•17 years ago
|
||
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".
Updated•17 years ago
|
Severity: normal → critical
Comment 33•17 years ago
|
||
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•17 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•17 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•17 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•17 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.
Comment 39•17 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
Comment 48•17 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.
Comment 53•16 years ago
|
||
There have been a bunch of recent dupes on this: any reason for that? Should it be picking up wanted?
Comment 54•16 years ago
|
||
the dupe I filed (bug 415411) did not manifest itself until we switched to cairo
Assignee | ||
Comment 55•16 years ago
|
||
I don't know why there would be new dups. We really can't do anything for 1.9.
Comment 56•16 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.
Comment 59•16 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.
Assignee | ||
Comment 60•16 years ago
|
||
What specific page and platform are you seeing this on?
Comment 61•16 years ago
|
||
See the last duped bug (bug 434686).
Assignee | ||
Comment 62•16 years ago
|
||
That's a zipped testcase, platform "All".
Bug 434546 looks better.
Comment 63•16 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•16 years ago
|
Flags: blocking1.9?
Comment 64•16 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•16 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.
Assignee | ||
Comment 66•16 years ago
|
||
I don't see this problem on Mac, but I do see it on Windows.
Comment 67•16 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•16 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•16 years ago
|
||
It does work in FF2 on the test case I submitted. I have no problems viewing that page on FF2.
Comment 70•16 years ago
|
||
That is on Windows and Linux where I have tested.
Comment 71•16 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•16 years ago
|
||
Oops, apologies for bugspam, not FF 1.5alpha but Mozilla 1.5 alpha, which means firebird ~0.6
Comment 73•16 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.
Comment 74•16 years ago
|
||
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-
Comment 76•16 years ago
|
||
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
Updated•16 years ago
|
Attachment #129217 -
Attachment is obsolete: true
Comment 77•16 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•16 years ago
|
Flags: wanted1.9.1?
Comment 81•16 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•16 years ago
|
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: wanted-next+
Comment 83•16 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).
Comment 84•16 years ago
|
||
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•16 years ago
|
||
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•16 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•16 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•16 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•16 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
Comment 94•16 years ago
|
||
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)
Updated•16 years ago
|
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)
Alias: big-long
Assignee | ||
Updated•16 years ago
|
Flags: wanted1.9.1-
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Comment 119•16 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.
Comment 123•16 years ago
|
||
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•16 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•16 years ago
|
||
Are you volunteering to contribute a fix? If not then your comment is superfluous.
Comment 132•15 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.
Comment 133•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
Uh, my previous comment was wrong (I was so sure!). I am very very sorry for the bugspam which I just added :((
Assignee | ||
Updated•15 years ago
|
Depends on: widget-removal
Comment 141•15 years ago
|
||
Unzip it and open the "resultats.htm" file. Scroll down and see what's happening !!
Updated•15 years ago
|
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
Comment 143•15 years ago
|
||
This was fixed by bug 352093.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 144•15 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
Comment 145•15 years ago
|
||
(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•14 years ago
|
||
Updated•10 years ago
|
Flags: wanted1.9.1-
Flags: blocking1.9.1-
Flags: blocking1.9.0.1-
Flags: blocking1.9-
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•