Steps to reproduce: Navigate to the following testcase. Actual result: The background image overlaps with the scroll bar. Expected result: The background image does not overlap with the scroll bar. Reproduceable: always. Occurs on: Latest cvs build on Windows 2000. 2000072520 nightly build on Windows 2000. Doesn't occur on: M16 on Windows 2000.

Confirmed. We are not allowing for scrollbars when drawing the background. In CSS terms, we are including the scrollbars in the definition of our viewport. Background issue. Taking QA. Nominating for nsbeta3. This is a CSS1 compliance issue which works fine in IE5.

Marking Future: We'll get to this after beta3/RTM

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

I ran into a similar problem with a page that looks like this: 1111111111111111111111111111111111111111111 <div style="background-color: #aaccff; position: absolute; width: auto; height:auto; top: auto; bottom: 40; left: 5; right: 5; ">foo</div> If you resize the page to make a horizontal scrollbar appear, the padding from border:5 goes away.

(Jesse: Note that unitless lengths like that will only work in quirks mode.)

Thanks. (Oops, I meant to say bottom:5 in both places, not bottom:40 and border:5.)

Reassigned to dcone who used to take care of background problems, knowing that everything that scrolls is evaughan's fault.

I think the placement of this object by style is messing up. The background cod e will place the image where it is told.. and the position seems to be were the scroll bar is. Style has to take this into account when it calculates this position.

related to bug 44192?

Correct. *** This bug has been marked as a duplicate of 44192 ***

Related to, maybe, but it's not a priori the same bug (although it is possible that the same fix would resolve both, that remains to be seen). Reopening so that we don't lose track of this bug in case the other is fixed without resolving this issue.

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

Sending to layout.

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

I'll have a whack.

nsPresShell.cpp already has "static GetRootScrollFrame", maybe you can make it public and use it?

I did notice that but it gets me the wrong frame if we are using a GFX scrollport. See the comment in my method. The presshell method may want to use this, but not the other way around. I'd have factored it out if we had an nsLayoutUtils or similar...

Comment on attachment 109130 [details] [diff] [review] Proposed fix Shouldn't GetRootScrollableFrame at least warn or something if what's passed in is not a viewport frame? Are there cases when the scrollbars are on the other side? If so, we should have ways of detecting it...

We can only have scrollbars on the right or bottom. This may change someday (and probably should). So yes, I'm aware that my code makes an assumption that will eventually change, but its my only real option, today. I can add the warn, which is a good idea. But if its okay with you, I'll keep my position in David's queue and not attach a new patch for it. :-) #ifdef DEBUG else { NS_WARNING("aRootFrame is not a viewport frame"); } #endif // DEBUG

Comment on attachment 109130 [details] [diff] [review] Proposed fix sounds good.

Comment on attachment 109130 [details] [diff] [review] Proposed fix >+ nsCOMPtr<nsIScrollableFrame> scrollableFrame(do_QueryInterface(scrollFrame)); r=dbaron if you change this to nsIScrollableFrame *scrollableFrame; CallQueryInterface(scrollFrame, &scrollableFrame); so that you don't use |nsCOMPtr|s on frames.

Checked in.

Some crashes in PaintBackgroundWithSC started showing up in the 12-23 builds in talkback. Related?

I filed the crash sa bug 186752.

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

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

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

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

v