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.

confirming on 2000062808 linux

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.

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]

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

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.

moving evaughan non-nsbeta3+ bugs to Future milestone, per xptoolkit triage.

Note: this problem _not_ fixed by nsViewManager2 2001-03-24 Win95. Gerv

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

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.

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

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.