5195 - Using incorrect right edge of container for fixed-position elements

Status: VERIFIED FIXED

(Core Graveyard :: GFX, defect, P2)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 1

[Patrick C. Beard]

-> M6

Comment 2

[Patrick C. Beard]

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.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: new testcase

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: Windows 95 screenshot before using scrollbar

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: Windows 95 screenshot after using scrollbar

Comment 7

[Patrick C. Beard]

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.

Comment 8

[Patrick C. Beard]

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

Comment 9

[Hixie (not reading bugmail)]

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

Comment 10

[Patrick C. Beard]

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.

Comment 11

[Peter Trudelle]

putting on beta1 radar

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 13

[Eric Vaughan]

targeting

Comment 14

[Peter Trudelle]

Mass-moving most M15 bugs to M16

Comment 15

[Peter Trudelle]

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

Comment 16

[Peter Trudelle]

[nsbeta2+] 6/1

Comment 17

[Peter Trudelle]

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

Comment 18

[John Morrison]

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.

Comment 19

[Peter Trudelle]

Mass-moving all dated nsbeta2+ bugs to M19

Comment 20

[John Morrison]

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

Comment 21

[Pierre Saslawsky]

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

Comment 22

[Pierre Saslawsky]

Attachment: testcase based on bug 41295

Comment 23

[leger]

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

Comment 24

[R.K.Aa.]

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

Comment 25

[Jim Roskind]

Cleaning status whiteboard by marking beta2 minus (6/15 has passed)

Folks are too doomed to handle this for beta2

Comment 26

[Hixie (not reading bugmail)]

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

Comment 27

[Peter Trudelle]

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

Comment 28

[Val Sharp]

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

Comment 29

[Val Sharp]

Attachment: Fixed pos. testcase

Comment 30

[Michael Nahrath]

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"

Comment 31

[James Green]

Seeing this on Linux too. OS->All.

Comment 32

[Peter Trudelle]

->moz1.0

Comment 33

[John Morrison]

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.

Comment 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 35

[Boris Zbarsky [:bzbarsky]]

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

Comment 36

[pohl]

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?

Comment 37

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 38

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 39

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Changing summary.

Comment 40

[pohl]

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.

Comment 41

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 42

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 43

[Marc Attinasi]

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

Comment 44

[John Morrison]

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.

Comment 45

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Proposed patch

Comment 46

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 47

[Chris Waterson]

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

Comment 48

[Marc Attinasi]

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

Comment 49

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 50

[Marc Attinasi]

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.

Comment 51

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 52

[Eric Vaughan]

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.

Comment 53

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 54

[Eric Vaughan]

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

Comment 55

[John Morrison]

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?

Comment 56

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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!

Comment 57

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Patch v2

Comment 58

[Marc Attinasi]

Looks fine to me: r=attinasi

Comment 59

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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!

Comment 60

[Marc Attinasi]

no problem Robert - sr=attinasi

Comment 61

[Eric Vaughan]

r=evaughan

Comment 62

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 63

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Marking FIXED.

Comment 64

[Michael Nahrath]

Well done, THANKS!

Comment 65

[Hixie (not reading bugmail)]

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