Closed
Bug 4209
Opened 26 years ago
Closed 24 years ago
Fixed scrolling positioned elements have no background defined. [BG] [FIX POS]
Categories
(Core Graveyard :: GFX, defect, P3)
Core Graveyard
GFX
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: ian, Assigned: roc)
References
()
Details
(Keywords: css2, testcase)
Attachments
(1 file)
(deleted),
text/html
|
Details |
See uri for distilled test page.
Basically, boxes that have been positioned using position:fixed and that
have overflow:scroll do not have a background, unless you explicitly give
them one with the 'background' properties. That is, NGL forgets to draw the
backing of the element.
The default background should be transparent (its the initial value as per CSS).
This means that the background of whatever is positioned should shine through.
This is what happens when overflow:hidden.
Yes, this is a known restriction currently caused by the fact that the fixed
elements have a native widget associated with them, and we don't currently
composite when there are native widgets involved.
Michael, I may have already given you a bug about this in which case this is a
DUP.
Comment 4•26 years ago
|
||
It's still a problem. Things are less of a mess than they once were, though.
However, they're still not transparent, and switching between windows and back
to viewer also causes other text to appear in the window. See:
http://www.fas.harvard.edu/~dbaron/csstest/sec090301
(The box begninning "This is an element (nine) with position fixed".)
Updated•26 years ago
|
Assignee: michaelp → kmcclusk
Comment 5•26 years ago
|
||
divvying up michaelp's old bugs.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M8
Updated•26 years ago
|
Assignee: kmcclusk → beard
Status: ASSIGNED → NEW
Comment 6•26 years ago
|
||
Patrick, reassigning to you because it is related to compositing a view with a
transparent background which is related to other bugs you have.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 7•26 years ago
|
||
This problem is occuring in the July 01 Build (Mac, Windows, Linux).
Reporter | ||
Updated•26 years ago
|
Whiteboard: [TESTCASE]
Reporter | ||
Comment 8•26 years ago
|
||
See also bug 8489, which is the same bug but reported from the point of view
of widgets causing the problems.
Comment 9•26 years ago
|
||
moving to m9. beard's on vacation
Comment 10•26 years ago
|
||
We could fix this by having the widget-based view inherit its super-view's
background, but making it truly transparent is much harder. One day, when we get
around to redesigning scrolling, we shouldn't have to use a native widget for
this case, and transparency will be easy.
Comment 11•26 years ago
|
||
We could fix this by having the widget-based view inherit its super-view's
background, but making it truly transparent is much harder. One day, when we get
around to redesigning scrolling, we shouldn't have to use a native widget for
this case, and transparency will be easy.
Comment 12•26 years ago
|
||
I almost filed this as a separate bug, but it's another case of this one. I'm
using apprunner Linux 1999-08-20-13-M10.
http://www.editions-eyrolles.com/livres/glazman/Tests/vfm/vfm9.htm has a
transparent fixed positioned element that covers (almost) the whole page. It
makes a mess.
TO REPRODUCE: Load the above URL. If that doesn't convince you, resize, switch
windows, hover over the toolbar, etc. It makes a huge mess. Two copies of the
toolbar in the middle of the browser window. Some other chrome stuff too.
Little bits of the web page here and there too. (Especially bad when I maximize
the window.)
EXPECTED RESULTS: One red sentence near the top that is fixed. Rest of page is
normal.
Reporter | ||
Comment 13•25 years ago
|
||
*** Bug 12065 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
*** Bug 13715 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
QA Contact: petersen → chrisd
Comment 15•25 years ago
|
||
*** Bug 15413 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•25 years ago
|
Summary: Fixed scrolling positioned elements have no background defined. → {css2} Fixed scrolling positioned elements have no background defined.
Reporter | ||
Comment 16•25 years ago
|
||
[Hmm. How did this escape my last round of radar installations??? :-) ]
Comment 17•25 years ago
|
||
*** Bug 16056 has been marked as a duplicate of this bug. ***
Comment 18•25 years ago
|
||
*** Bug 16056 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 19•25 years ago
|
||
*** Bug 13193 has been marked as a duplicate of this bug. ***
Comment 20•25 years ago
|
||
I almost reported this bug as new when I found it posted here.
I came across this by changing <layer>elements to <div>with position:fixed at
"KaiRo' Best Web Links" on http://start.at/kairo
In a simplified test case I made to see where this is happening I saw that at
reloading the page the (transparent) background is first showed up CORRECTLY but
after less than a second it's replaced by that scrambled background showing some
chrome &page content pieces. Also a border assigned to this element is disappearing.
Everything of this was seen using M11 (Win32).
Updated•25 years ago
|
Target Milestone: M13 → M14
Reporter | ||
Comment 21•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...
Comment 22•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Updated•25 years ago
|
Summary: {css2} Fixed scrolling positioned elements have no background defined. → Fixed scrolling positioned elements have no background defined.
Whiteboard: [TESTCASE]
Updated•25 years ago
|
Target Milestone: M14 → M15
Comment 23•25 years ago
|
||
*** Bug 26584 has been marked as a duplicate of this bug. ***
Comment 24•25 years ago
|
||
Reassigning all view bugs to kevin.
Assignee: beard → kmcclusk
Status: ASSIGNED → NEW
QA Contact: chrisd → petersen
Comment 25•25 years ago
|
||
*** Bug 27967 has been marked as a duplicate of this bug. ***
Comment 26•25 years ago
|
||
I'm going to attach a simpler testcase extracted from bug 27967.
Comment 27•25 years ago
|
||
Comment 30•25 years ago
|
||
*** Bug 36298 has been marked as a duplicate of this bug. ***
Comment 32•25 years ago
|
||
This bug has been marked "future" because the original netscape engineer working
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration.
Target Milestone: M18 → Future
Reporter | ||
Comment 33•25 years ago
|
||
We really do not want to ship with this! At the moment, we have basically made
absolute positioning useless for most purposes. At the moment, any transparent
block that is positioned gets a white backround (as far as I can tell).
nominating nsbeta3. cc'ing Eric Krock.
Keywords: correctness,
nsbeta3
Reporter | ||
Comment 34•25 years ago
|
||
As per meeting with ChrisD today, taking QA.
QA Contact: petersen → py8ieh=bugzilla
Updated•25 years ago
|
Whiteboard: [nsbeta3-]
Comment 36•25 years ago
|
||
Marking nsbeta3-
Reporter | ||
Comment 37•25 years ago
|
||
Clearing nsbeta3- to trigger reevaluation.
Kevin: There is a patch floating about (from Robert) which fixes this.
See bug 14691.
This is a serious standards compliance issue. If we do not fix this then we have
potentially _killed_ a high proportion of the uses for 'fixed positioning' --
and fixing it in the next release won't help since web authors will have the 6.0
release as a legacy to support. (Also, we need to fix this for nsbeta3 and not
as a last minute rtm fix since it affects the compositor and thus the display of
every web page -> higher risk than will be accepted for rtm fixes.)
The fact that this bug is marked 'mostfreq' is an indication of just how many
people have already hit this bug...
Comment 38•25 years ago
|
||
Robert, will your fix for bug 14691 truly fix this bug as Ian believes?
Comment 39•25 years ago
|
||
Marking nsbeta3- but if there is a safe external patch we will be willing to
accept it as a mozilla contribution.
Whiteboard: [nsbeta3-]
Assignee | ||
Comment 40•25 years ago
|
||
I'm pleased to report that my patch fixes this bug; all the testcase attached
here work nicely.
Assignee | ||
Comment 41•25 years ago
|
||
All the testcases in the duplicate bugs work nicely too.
BTW, my patch (and discussion) is attached to bug 39621. I think most of you are
already cc'ed on that bug so I'll spare repeating the details :-).
Reporter | ||
Comment 42•25 years ago
|
||
Reassigning to Robert, who has a fix pending review in bug 39621.
Reporter | ||
Comment 43•25 years ago
|
||
*** Bug 47596 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•24 years ago
|
Summary: Fixed scrolling positioned elements have no background defined. → Fixed scrolling positioned elements have no background defined. [BG]
Reporter | ||
Updated•24 years ago
|
Summary: Fixed scrolling positioned elements have no background defined. [BG] → Fixed scrolling positioned elements have no background defined. [BG] [FIX POS]
Comment 44•24 years ago
|
||
Replacing nsbeta3 nomination with mozilla0.9.
/be
Keywords: nsbeta3 → mozilla0.9
Comment 45•24 years ago
|
||
*** Bug 60686 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 46•24 years ago
|
||
*** Bug 60686 has been marked as a duplicate of this bug. ***
Comment 47•24 years ago
|
||
Unsetting target milestone - M18 is long past.
Gerv
Target Milestone: M18 → ---
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → mozilla0.9
Comment 48•24 years ago
|
||
Hixie: The testcase still looks really ugly with ViewManager2, but I suspect
that's intentional... is this bug fixed?
Gerv
Comment 49•24 years ago
|
||
It has been looking fixed on my page for a long time with new "scary"
ViewManager and does also look fixed now in default builds...
I only wanted a while to comment about this because of the last comment to 39621...
Assignee | ||
Comment 50•24 years ago
|
||
This bug is fixed. nsViewManager2 is the old view manager and it is now
irrelevant.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 52•24 years ago
|
||
I hate to clutter people's mailboxes unnecessarily, but my enthusiasm has gotten
the better of me. This really, truly is fixed (with 2001040120 on Windows
2000), and it is WAY cool to have it working! Y'all take a lot of crap, so when
I see a piece of work like this, it seems appropriate to stand up and cheer. I
wonder how many of Mozilla's detractors could make this work, in real time? (I
sure couldn't.)
Nice work!
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
•