Using incorrect right edge of container for fixed-position elements

VERIFIED FIXED in mozilla0.9

Status

P2
normal
VERIFIED FIXED
20 years ago
10 years ago

People

(Reporter: dbaron, Assigned: roc)

Tracking

({css2, polish})

Trunk
mozilla0.9
x86
All
css2, polish
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: (py8ieh: check for bugs relating to overlap of positioned elements), URL)

Attachments

(7 attachments)

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.

Updated

20 years ago
Assignee: michaelp → beard

Comment 1

20 years ago
-> M6
Target Milestone: M6

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
Target Milestone: M6 → M7

Updated

20 years ago
Target Milestone: M7 → M9

Updated

20 years ago
Target Milestone: M9 → M11

Comment 2

20 years ago
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.
Created attachment 1207 [details]
Windows 95 screenshot before using scrollbar
Created attachment 1208 [details]
Windows 95 screenshot after using scrollbar
Summary: Fixed positioned elements drawing overtop of scrollbars → {css2} Fixed positioned elements drawing overtop of scrollbars

Comment 7

19 years ago
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.

Updated

19 years ago
QA Contact: petersen → chrisd

Updated

19 years ago
Target Milestone: M11 → M12

Comment 8

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

Updated

19 years ago
Target Milestone: M12 → M13
Keywords: css2
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...

Updated

19 years ago
Assignee: beard → evaughan
Status: ASSIGNED → NEW
Target Milestone: M13 → M14

Comment 10

19 years ago
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

19 years ago
putting on beta1 radar

Updated

19 years ago
Summary: {css2} Fixed positioned elements drawing overtop of scrollbars → Fixed positioned elements drawing overtop of scrollbars
*** Bug 26851 has been marked as a duplicate of this bug. ***

Comment 13

19 years ago
targeting
Status: NEW → ASSIGNED
Target Milestone: M14 → M15

Comment 14

19 years ago
Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16

Comment 15

19 years ago
nominating for nsbeta2. Should fix this so HTML fixed pos elements show up 
correctly.
Keywords: nsbeta2

Updated

19 years ago
QA Contact: chrisd → petersen

Comment 16

19 years ago
[nsbeta2+] 6/1
Whiteboard: [nsbeta2+] 6/1

Comment 17

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

Comment 18

19 years ago
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.

Updated

19 years ago
Blocks: 38639

Updated

19 years ago
Blocks: 40158

Comment 19

19 years ago
Mass-moving all dated nsbeta2+ bugs to M19
Target Milestone: M16 → M19

Comment 20

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

Comment 21

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

Comment 22

19 years ago
Created attachment 9522 [details]
testcase based on bug 41295

Comment 23

19 years ago
Updating from [6/1] to [6/15]
Whiteboard: [nsbeta2+] 6/1 → [nsbeta2+][6/15]

Comment 24

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

Comment 25

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

Folks are too doomed to handle this for beta2
Whiteboard: [nsbeta2+][6/15] → [nsbeta2-]
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).
Keywords: nsbeta3, polish
QA Contact: petersen → py8ieh=bugzilla

Comment 27

19 years ago
nsbeta3-, no time for this, have to get in 6.0.1
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Target Milestone: M19 → Future
Summary: Fixed positioned elements drawing overtop of scrollbars → Fixed positioned elements drawing overtop of scrollbars [FIX POS]

Comment 28

18 years ago
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

18 years ago
Created attachment 13999 [details]
Fixed pos. testcase

Updated

18 years ago
Target Milestone: Future → mozilla0.9

Comment 30

18 years ago
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

18 years ago
Seeing this on Linux too. OS->All.
OS: Windows 95 → All
Keywords: nsbeta2, nsbeta3 → mozilla1.0
Whiteboard: [nsbeta2-][nsbeta3-]

Comment 32

18 years ago
->moz1.0
Target Milestone: mozilla0.9 → mozilla1.0

Comment 33

18 years ago
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 :-)
Assignee: evaughan → roc+moz
Status: ASSIGNED → NEW
Depends on: 39621
*** Bug 72059 has been marked as a duplicate of this bug. ***

Comment 36

18 years ago
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.
Status: NEW → ASSIGNED
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.
Summary: Fixed positioned elements drawing overtop of scrollbars [FIX POS] → Using incorrect right edge of container for fixed-position elements

Comment 40

18 years ago
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?

Comment 43

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

Comment 44

18 years ago
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?
Priority: P3 → P2

Comment 47

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

Comment 48

18 years ago
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.
Target Milestone: mozilla1.0 → mozilla0.9

Comment 50

18 years ago
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.

Comment 52

18 years ago
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?

Comment 54

18 years ago
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

18 years ago
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!

Comment 58

18 years ago
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!

Comment 60

18 years ago
no problem Robert - sr=attinasi

Comment 61

18 years ago
r=evaughan
Fix checked in. Thanks guys, we've made the world safe for "position: fixed"!
Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 64

18 years ago
Well done, THANKS!
There are some minor visual glitches where positioned elements overlap, but the 
bug is fixed. VERIFIED.
Status: RESOLVED → VERIFIED
Whiteboard: (py8ieh: check for bugs relating to overlap of positioned elements)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.