Closed
Bug 5195
Opened 25 years ago
Closed 23 years ago
Using incorrect right edge of container for fixed-position elements
Categories
(Core Graveyard :: GFX, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: dbaron, Assigned: roc)
References
()
Details
(Keywords: css2, polish, Whiteboard: (py8ieh: check for bugs relating to overlap of positioned elements))
Attachments
(7 files)
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•25 years ago
|
Assignee: michaelp → beard
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
Target Milestone: M6 → M7
Updated•25 years ago
|
Target Milestone: M7 → M9
Updated•25 years ago
|
Target Milestone: M9 → M11
Comment 2•25 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.
Reporter | ||
Comment 3•25 years ago
|
||
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.
Reporter | ||
Comment 4•25 years ago
|
||
Reporter | ||
Comment 5•25 years ago
|
||
Reporter | ||
Comment 6•25 years ago
|
||
Updated•25 years ago
|
Summary: Fixed positioned elements drawing overtop of scrollbars → {css2} Fixed positioned elements drawing overtop of scrollbars
Comment 7•25 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•25 years ago
|
QA Contact: petersen → chrisd
Updated•25 years ago
|
Target Milestone: M11 → M12
Comment 8•25 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•25 years ago
|
Target Milestone: M12 → M13
Comment 9•25 years ago
|
||
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•25 years ago
|
Assignee: beard → evaughan
Status: ASSIGNED → NEW
Target Milestone: M13 → M14
Comment 10•25 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•25 years ago
|
||
putting on beta1 radar
Updated•25 years ago
|
Summary: {css2} Fixed positioned elements drawing overtop of scrollbars → Fixed positioned elements drawing overtop of scrollbars
Reporter | ||
Comment 12•25 years ago
|
||
*** Bug 26851 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
nominating for nsbeta2. Should fix this so HTML fixed pos elements show up
correctly.
Keywords: nsbeta2
Updated•24 years ago
|
QA Contact: chrisd → petersen
Comment 17•24 years ago
|
||
*** Bug 38131 has been marked as a duplicate of this bug. ***
Comment 18•24 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.
Comment 20•24 years ago
|
||
*** Bug 40958 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
*** Bug 41295 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
Comment 23•24 years ago
|
||
Updating from [6/1] to [6/15]
Whiteboard: [nsbeta2+] 6/1 → [nsbeta2+][6/15]
Comment 24•24 years ago
|
||
*** Bug 42179 has been marked as a duplicate of this bug. ***
Comment 25•24 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-]
Comment 26•24 years ago
|
||
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•24 years ago
|
||
nsbeta3-, no time for this, have to get in 6.0.1
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Target Milestone: M19 → Future
Updated•24 years ago
|
Summary: Fixed positioned elements drawing overtop of scrollbars → Fixed positioned elements drawing overtop of scrollbars [FIX POS]
Comment 28•24 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•24 years ago
|
||
Updated•24 years ago
|
Target Milestone: Future → mozilla0.9
Comment 30•24 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"
Updated•24 years ago
|
Whiteboard: [nsbeta2-][nsbeta3-]
Comment 33•24 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.
Assignee | ||
Comment 34•24 years ago
|
||
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•24 years ago
|
||
*** Bug 72059 has been marked as a duplicate of this bug. ***
Comment 36•24 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?
Assignee | ||
Comment 37•24 years ago
|
||
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
Assignee | ||
Comment 38•24 years ago
|
||
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.
Assignee | ||
Comment 39•24 years ago
|
||
Changing summary.
Summary: Fixed positioned elements drawing overtop of scrollbars [FIX POS] → Using incorrect right edge of container for fixed-position elements
Comment 40•24 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.
Assignee | ||
Comment 41•24 years ago
|
||
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.
Assignee | ||
Comment 42•24 years ago
|
||
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•24 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•24 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.
Assignee | ||
Comment 45•24 years ago
|
||
Assignee | ||
Comment 46•24 years ago
|
||
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•24 years ago
|
||
Scrollbars are deep magic to me. I think evaughan or hyatt would know best...
Comment 48•24 years ago
|
||
Chris has the right idea, seek the wisdom of the scrollbar high-priests.
Assignee | ||
Comment 49•24 years ago
|
||
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•23 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.
Assignee | ||
Comment 51•23 years ago
|
||
Evaughn is cc'ed on this bug but I will email him directly as well.
Comment 52•23 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.
Assignee | ||
Comment 53•23 years ago
|
||
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•23 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•23 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?
Assignee | ||
Comment 56•23 years ago
|
||
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!
Assignee | ||
Comment 57•23 years ago
|
||
Comment 58•23 years ago
|
||
Looks fine to me: r=attinasi
Assignee | ||
Comment 59•23 years ago
|
||
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•23 years ago
|
||
no problem Robert - sr=attinasi
Comment 61•23 years ago
|
||
r=evaughan
Assignee | ||
Comment 62•23 years ago
|
||
Fix checked in. Thanks guys, we've made the world safe for "position: fixed"!
Assignee | ||
Comment 63•23 years ago
|
||
Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 64•23 years ago
|
||
Well done, THANKS!
Comment 65•23 years ago
|
||
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)
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•