Fixed positioned elements in the above page (the two on the right edge of the page) draw over top of the page's scrollbar in viewer. I didn't check apprunner. If you drag the scrollbar, they are mostly, but not completely, erased.

-> M6

Doesn't happen in appRunner on NT, need to check Win95. Chris, would you please verify that? If it's viewer-specific, might not fix.

Whoops... the drawing on top of scrollbars depended (I think) on a positioning bug that has been fixed (once it was fixed, they were no longer in a position to be under the scrollbars). I will attach a new testcase that shows the problem, along with a screenshot of that testcase in Windows 95.

This is working much better now, but we still have some widget z-index problems. We need an XP way to ensure that widgets and views have consistent z-index. Overlapping widgets just don't work right yet.

A fix for this has been checked in on the Mac, but may still need some work on Linux/PC. Moving to M12.

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...

This happens even better with GFX scrollbars. Giving to eric vaughan to handle in M14. We need to make sure that fixed positioned elements appear BEHIND scroll bars.

putting on beta1 radar

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

targeting

Mass-moving most M15 bugs to M16

nominating for nsbeta2. Should fix this so HTML fixed pos elements show up correctly.

[nsbeta2+] 6/1

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

Note that (ref. bug 38131), in addition to the z-order problem (contents draw above the scrollbars) there is a problem with GFX vs. Native scrollbars -- for gfx 'right:0;' is relative to the right hand edge of the window (viewport) when using GFX scrollbars, but relative to the left-hand edge of the scrollbar when using native scrollbars for win32/mac/GTK). See http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8501 for a narrow testcase showing this.

Mass-moving all dated nsbeta2+ bugs to M19

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

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

Updating from [6/1] to [6/15]

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

Cleaning status whiteboard by marking beta2 minus (6/15 has passed) Folks are too doomed to handle this for beta2

As per meeting with ChrisD today, taking QA. Nominating for nsbeta3. This gives very bad user experience, and can prevent the use of scrollbars in some cases. It also makes it very difficult to write pages that use bleeding fixed positioning (where a fixed positioned box 'leaks' out of the viewport, for example if it is going to be animated in later).

nsbeta3-, no time for this, have to get in 6.0.1

Almost Duplicated this bug - but creating an attachment out of my testcase anyway, just in case you haven't got too many yet...

I have the describesd behaviour for all testcases on MacOs 9.0.4-D, Build ID: 2000122010 I think Platform and OS should be updated to "All"

Seeing this on Linux too. OS->All.

->moz1.0

Ian/David, I just tried with the new, new, viewmanager, and dbaron's testcase 8/11/99 works pretty well (the only obvious problem being that you can't immediately begin to drag the thumb; click first below it, then it works). Try this stuff out with user_pref("nglayout.debug.enable_scary_view_manager", true); I think this is supposed to go live Real Soon Now.

Definitely a view manager issue that should be fixed in the new view manager. The new view manager leaves open some event handling problems that cause the behaviour reported by John Morrison below. In general the new view manager fixes rendering but not event handling. But I do know how to fix it... Stealing, hope that's OK evaughan :-)

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

I tried the new view manager with the user_pref given by John Morrison. The scrollbar did, at least, appear above the fixed element. The positioning of the fixed element was, unfortunately, still computed incorrectly. The right edge of the viewport appears to be the right edge of the scrollbar, whereas it should be the left edge of the scrollbar (if any). Does this bug just refer to the z-index of the widget, or is it also for the incorrect calculation of the right edge?

I think we should open a separate bug for the problem that the right margin of the viewport is the right edge of its scrollbar.

No, actually we should continue to let this bug refer to the incorrect calculation of the right edge, since other bugs have been marked as duplicates of this one on those grounds.

Changing summary.

I've been playing with this one. The new view manager seems to be positioning the right hand edges correctly now. However, the rectangle that describes the active mouse region (for selecting text, say) seems to still have the incorrect right edge. John Morrison (2001-02-28 21:07) noticed this, but didn't describe it exactly. Take one of the test cases attached to this bug and try to grab the scrollbar at a place with the same vertical coordinates as some fixed position element with right: 0 -- the scrollbar won't "hear" the mouse event, but often the fixed element does, and the contained text is selected. I hope I'm making sense...I'm very tired at the moment.

The right hand edge problem is still there. This testcase shows it clearly: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8501 You are seeing event targeting problems that are also assigned to me, but under another bug.

I have a fix, CC'ing my layout buddies. I just have one question --- are we still supporting native scrollbars, and if so, how do I test with them turned on?

My understanding is that we do *not* support native scrollbars. I think the support was dropped more than 6 months ago actually.

I spoke with evaughan about this, and we don't support native scrollbars in a xul-based window. But embedders may have native windows and scrollbars. Unfortunately, I don't know how|where to test that. winEmbed and mfcEmbed are actually xul scrollbars.

The patch tries to fix nsScrollBar native scrollbars, but I don't know how to test that. Marc, Waterson, what thinkest thou?

Scrollbars are deep magic to me. I think evaughan or hyatt would know best...

Chris has the right idea, seek the wisdom of the scrollbar high-priests.

Chaps, I wonder if we could get this reviewed for Mozilla 0.9. This bug screws up the layout of a lot of fixed-position elements.

Robert, did you ask evaughan for a review? It looks OK to me, but I'm not a scrollframe expert. I thought, though, that the nsScrollFrame stuff was obsoleted by the GfxScrollFrame code - I see that it is still being built, but is is being used? I guess updating that code is not a bad idea anyway, in case we ever do decide to resurrect native scrollbars (hopefully). Please get a review from Eric before I can sr - thanks.

Evaughn is cc'ed on this bug but I will email him directly as well.

We do support native scrollbars even in mozilla. A few of the forms controls still use them. Like list boxes, comboboxes. As I remember native ones don't have this problem. Because native scrollbars just always place themsselves on top of everything. I'll take a look at the patch as well.

The remaining problems addressed in this bug are with the layout of fixed-position frames. To test the patch with native scrollbars, I'd need to have native scrollbars on the viewport. Is there any way to turn that on?

to test with native try making the method HasGfxScrollbars() in nsCSSFrameConstructor return PR_FALSE But don't try to run mozilla in this mode. Trees will all crash. But winembed should work. If it works for native. -r=evaughan

If I add 'scrollbar {border:2px solid red;}' to xul.css for an winEmbed build, the browser scrollbars have red borders. I'm ass-u-ming that that means those scrollbars are not native, right?

OK, I got it working for native scrollbars, but I had to modify the patch a tiny bit ... GFX scrollbars report a preferred size of 0 for non-visible scrollbars, but native scrollbars report the actual size that the scrollbar will be. So I had to have nsViewportFrame::CalculateFixedContainingBlockSize check scrollbar visibility and take that into account. New patch coming up; appreciate reviews from Eric and Marc. Thanks!

Looks fine to me: r=attinasi

Actually Marc, I think I need sr= from you. And I think I need evaughan to put his r= stamp on the new version of the patch. Thanks!

no problem Robert - sr=attinasi

r=evaughan

Fix checked in. Thanks guys, we've made the world safe for "position: fixed"!

Marking FIXED.

Well done, THANKS!

There are some minor visual glitches where positioned elements overlap, but the bug is fixed. VERIFIED.