Closed Bug 4209 Opened 21 years ago Closed 19 years ago

Fixed scrolling positioned elements have no background defined. [BG] [FIX POS]

Categories

(Core Graveyard :: GFX, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9

People

(Reporter: ian, Assigned: roc)

References

()

Details

(Keywords: css2, testcase)

Attachments

(1 file)

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.
Component: Layout → Compositor
Assignee: troy → michaelp
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.
is this still a problem with current builds?
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".)
Assignee: michaelp → kmcclusk
divvying up michaelp's old bugs.
Status: NEW → ASSIGNED
Target Milestone: M8
Assignee: kmcclusk → beard
Status: ASSIGNED → NEW
Patrick, reassigning to you because it is related to compositing a view with a
transparent background which is related to other bugs you have.
Status: NEW → ASSIGNED
This problem is occuring in the July 01 Build (Mac, Windows, Linux).
Whiteboard: [TESTCASE]
See also bug 8489, which is the same bug but reported from the point of view
of widgets causing the problems.
moving to m9. beard's on vacation
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.
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.
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.
*** Bug 12065 has been marked as a duplicate of this bug. ***
*** Bug 13715 has been marked as a duplicate of this bug. ***
QA Contact: petersen → chrisd
*** Bug 15413 has been marked as a duplicate of this bug. ***
Summary: Fixed scrolling positioned elements have no background defined. → {css2} Fixed scrolling positioned elements have no background defined.
[Hmm. How did this escape my last round of radar installations??? :-) ]
*** Bug 16056 has been marked as a duplicate of this bug. ***
*** Bug 16056 has been marked as a duplicate of this bug. ***
*** Bug 13193 has been marked as a duplicate of this bug. ***
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).
Target Milestone: M13 → M14
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...
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Summary: {css2} Fixed scrolling positioned elements have no background defined. → Fixed scrolling positioned elements have no background defined.
Whiteboard: [TESTCASE]
Target Milestone: M14 → M15
*** Bug 26584 has been marked as a duplicate of this bug. ***
Reassigning all view bugs to kevin.
Assignee: beard → kmcclusk
Status: ASSIGNED → NEW
QA Contact: chrisd → petersen
*** Bug 27967 has been marked as a duplicate of this bug. ***
I'm going to attach a simpler testcase extracted from bug 27967.
Attached file testcase
Moving to M16
Target Milestone: M15 → M16
Moving to M17
Status: NEW → ASSIGNED
Target Milestone: M16 → M17
*** Bug 36298 has been marked as a duplicate of this bug. ***
Moving to M18
Target Milestone: M17 → M18
Keywords: mostfreq
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
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
As per meeting with ChrisD today, taking QA.
QA Contact: petersen → py8ieh=bugzilla
Whiteboard: [nsbeta3-]
Added Relnote keyword
Keywords: relnote
Marking nsbeta3-
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...
Keywords: patch
OS: Windows 98 → All
Whiteboard: [nsbeta3-]
Robert, will your fix for bug 14691 truly fix this bug as Ian believes?
Marking nsbeta3- but if there is a safe external patch we will be willing to 
accept it as a mozilla contribution.
Whiteboard: [nsbeta3-]
I'm pleased to report that my patch fixes this bug; all the testcase attached 
here work nicely.
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 :-).
Reassigning to Robert, who has a fix pending review in bug 39621.
Assignee: kmcclusk → roc+moz
Status: ASSIGNED → NEW
Depends on: 39621
Keywords: relnotereview
Hardware: PC → All
Target Milestone: Future → M18
*** Bug 47596 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Summary: Fixed scrolling positioned elements have no background defined. → Fixed scrolling positioned elements have no background defined. [BG]
Blocks: 55104
Summary: Fixed scrolling positioned elements have no background defined. [BG] → Fixed scrolling positioned elements have no background defined. [BG] [FIX POS]
Replacing nsbeta3 nomination with mozilla0.9.

/be
Keywords: nsbeta3mozilla0.9
*** Bug 60686 has been marked as a duplicate of this bug. ***
*** Bug 60686 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Whiteboard: [nsbeta3-]
Unsetting target milestone - M18 is long past.

Gerv
Target Milestone: M18 → ---
Target Milestone: --- → mozilla0.9
Hixie: The testcase still looks really ugly with ViewManager2, but I suspect
that's intentional... is this bug fixed?

Gerv
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...
This bug is fixed. nsViewManager2 is the old view manager and it is now 
irrelevant.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
works great!
Status: RESOLVED → VERIFIED
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!
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.