On Linux 2000062820, the right and bottom scrollbars cover text. I have checked this at 1024x768. This is not a new problem. I had thought originally thought this was part of bug#36211, but the page for that now works for me correctly, so I'm now guessing it's a different bug. I'll will attach a simplified test case shortly.
Created attachment 10788 [details] This file works fine, and forms part of my comparison for expected behaviour
Created attachment 10789 [details] "columntest" is like "scrolltest" with a div added to shuffle all the text into column 2. The bug is triggered by this. I used column 2 to demonstrate both the side and bottom cut offs.
confirming on 2000062808 linux
Status: UNCONFIRMED → NEW
Ever confirmed: true
Changing platform to all - I see this problem on Windows 98 2000062820 as well. Verifying this on Win98 is more difficult, because the text doesn't display at first, until I grabbed the invisible scrollbar and moved it. Then the scrollbar and the text both appeared with the same symptoms as Linux.
OS: Linux → All
Thanks. We really have two problems here: (1) the originally reported problem: I see in the second attachment, that the gfx scrollbar indeed does cover the rightmost characters in the column. (i.e., the right edge of the wrapped text is located underneath the scrollbar). [mac/linux/win32 -- win32 after you get the text to display]. However, I'm not clear what you mean by 'bottom scrollbar covers text'; with 'overflow:scroll' the bottom scrollbar is created and it must intersect with the overflowing text. However, when I scroll to the end of the text, none of that text is covered by the scrollbar (which is the correct result). (2) the followup problem that was noticed: on win32 (and on mac) there are some painting problems. I will fill a separate bug for that. Note that with _native_ scrollbars on mac/win32/linux, the attached testcase reveal a whole slew of different problems and the page is pretty much unusable (but the focus is on gfx scrollbars now, and native is slowly rotting). Passing on to evaughan (who may be slightly bummed to hear that there are a couple of lingering problems). [Tested with win95/mac/linux 2000062914 respin builds]
Assignee: trudelle → evaughan
Created attachment 10833 [details] This is an image of what I see on my machine. The scroll bar is all the way to the bottom and I can highlight the text under the scroll bar. It has covered the words "fratrum nostrorum subscriptorum."
Ah, yes. I do see that the bottom scrollbar is covering the last line of text. (Hey. So how was I supposed to know that I was looking at an incomplete Latin sentence :-).
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
I still see this on Linux build 2000071120. I will check again with tommorows build on both Linux and Windows.
Reopening bug - I still see this on Linux 2000071208, and Asa confirms 071208 NT4. If it's not clear, (Bugzilla lays this out poorly on the page) the test case is the second attachment 06 [details]/29/00 01:18.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
moving evaughan non-nsbeta3+ bugs to Future milestone, per xptoolkit triage.
Target Milestone: --- → Future
Note: this problem _not_ fixed by nsViewManager2 2001-03-24 Win95. Gerv
Summary: Scrollbars cover text → scrollbars cover right/bottom of fixed positioned elements
*** Bug 89293 has been marked as a duplicate of this bug. ***
Bug 89293 resolved itself somewhere between August 10th and 17th. Why ? Nobody knows... My page works now as intended.
*** Bug 46814 has been marked as a duplicate of this bug. ***
There is a very nice and simple testcase at attachment 12075 [details] under bug 46814 which was closed as dup.
Created attachment 122417 [details] minimal-ish testcase Position:fixed is incidental here; I get the same results with position:absolute for the outer div. The key is the margin on the inner div -- we seem to not be taking that into account when computing the overflow area....
Over to the right component.
Assignee: eric → position
Status: REOPENED → NEW
Component: XP Toolkit/Widgets → Layout: R & A Pos
Priority: P3 → --
QA Contact: jrgm → ian
Target Milestone: Future → ---
Do we have a bug somewhere on not including margins in overflow areas? I think so...
There is bug 47710, but that's not quite the same... Note that we _do_ include the top margin of an in-flow element in the overflow area. The inner div being absolutely positioned is necessary to cause the problem in this testcase. I tried hacking the child bounds computations in nsAbsoluteContainingBlock by moving over the child bounds by the size of the computed margin in Reflow(), but that had no effect (it may be that Reflow() is not even being called here and IncrementatlReflow() is what I should have poked at....)
14 years ago
Depends on: 47710
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050603 Firefox/1.0+ ID:2005060305 Is this bug still present? I am a little unclear what the testcase is meant to show, but all 25 lines are present for me now.
There's a good chance that roc's scrollframe changes helped here.
*** Bug 307071 has been marked as a duplicate of this bug. ***
Isn't bug 211562 actually a duplicate of this bug? Just asking..
I don't think it is -- one uses fixed pos, the other absolute pos. They're using different parent frames, etc.
Ok, Boris. Thank you for clarifying this.
The URL (http://hurddocs.org/) is now "Server not found". So I try attachment 122417 [details] with Minefield/3.0a4pre rv:1.9a4pre build Gecko/20070404 (under XP Pro SP2) and I can view/read the "Line 25": in other words, the last line of text is NOT covered by the bottom horizontal scrollbar. The other issue (5em bottom-margin of #column2) is bug 47710 as far as I understand this. Is this bug fixed?
Looks like it to me.
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.