27180 - Bad paint on fixed positioning [FIX POS]

Status: VERIFIED FIXED

(Core Graveyard :: GFX, defect, P3)

Description

[Uriel]

* DESCRIPTION:
Elements with fixed positioning dont paint well if:
 1.- Dont't have set the "background-color" propertie.
 2.- Have "background-color" propertie, but the content overlaps his parent size
 3.- Have "background-color" propertie, but "opacity" is different than "100%"

* STEPS TO REPRODUCE:
Open the atached file

* RESULT:
Fixed positioned boxes with corrupted content and filled with parts of the
mozilla interface or other well painted fixed positioned items.

* EXPECTED RESULT
Fixed positioned boxes with his content.

* NOTES:
Tested in html pages and "pure xml"+CSS2 pages, nothing to do with div tag

* TESTED IN:
 - Win 2000(PR2): Milestone 13
 - Win 98:  Build ID: 2000020908
 - Linux: Recent build(not sure what)

Comment 1

[Uriel]

Attachment: HTML file with fixed positioned elements(various CSS2 styles)

Comment 2

[troy]

These are all known issues because of problems in the compositor...

Comment 3

[troy]

Re-assigning to Compositor component

Comment 4

[Patrick C. Beard]

Many of these seem to work with nsViewManager2. Would you please check this in 
your build? Go to Preferences dialog, Debug, check Use ViewManager2.

Comment 5

[Uriel]

Work Ok with nsViewManager2 in Build ID: 2000021014 OS: Win 2000

Comment 6

[troy]

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

Comment 7

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

If #27706 is a duplicate of this, then this bug is not fixed. I have enabled 
nsViewManager2, and the situation has improved, but the basic problem remains: 
starting with a wide window, and then making it narrow, the lines are not 
redrawn with new breaks until the window gets really narrow. I will bring my 
testcase from 27706 to here.

Comment 8

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

Attachment: A fixed position DIV with %age width and height whose children do not repaint properly

Comment 9

[Patrick C. Beard]

I don't see the reflow issues with the new test case. Everything looks fine to me 
on the Mac.

Comment 10

[Patrick C. Beard]

On the Mac, nsWindow::Resize() invalidates the entire widget area, if the 
aRepaint parameter is true. On Linux, and Windows, this invalidate isn't done. 
This may be a brute force fix, but at least the platforms will be consistent in 
behavior, and that was the intent of the aRepaint parameter. Here're patches to 
make this work on linux and windows:

Index: mozilla/widget/src/gtk/nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsWindow.cpp,v
retrieving revision 1.240
diff -c -2 -r1.240 nsWindow.cpp
*** nsWindow.cpp	2000/02/12 00:42:57	1.240
--- nsWindow.cpp	2000/02/15 04:57:32
***************
*** 2445,2448 ****
--- 2445,2451 ----
      Show(PR_TRUE);
  
+   if (aRepaint)
+     Invalidate(PR_FALSE);
+ 
    return NS_OK;
  }

Index: mozilla/widget/src/windows/nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/windows/nsWindow.cpp,v
retrieving revision 3.251
diff -c -2 -r3.251 nsWindow.cpp
*** nsWindow.cpp	2000/02/12 00:10:22	3.251
--- nsWindow.cpp	2000/02/15 04:59:36
***************
*** 1183,1186 ****
--- 1183,1190 ----
          NS_IF_RELEASE(par);
      }
+     
+     if (aRepaint)
+         Invalidate(PR_FALSE);
+     
      return NS_OK;
  }
***************
*** 1232,1235 ****
--- 1236,1243 ----
          NS_IF_RELEASE(par);
      }
+ 
+     if (aRepaint)
+         Invalidate(PR_FALSE);
+ 
      return NS_OK;
  }

Comment 11

[Patrick C. Beard]

Checked in changes for Windows & Linux.

Comment 12

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

Build: 2000021608 (Win32)
My testcase (attachment 5237 [details]) displays garbage when the window is small. More
precisely: If I make the window very small and then load the attachment URL,
then the page renders with some cruft from the Moz toolbar area at the back, the
red fixed frame drawn over the top of that, and then the text is drawn over the
top of all of it.

Comment 13

[Uriel]

Build: 2000021608 Win32(Same as you) with nsViewManager2 enabled

In my testcase(attachment 5123 [details]) some problems remain:
1.- If the the backgroun-color is not set the problem remain
2.- If the content overlaps his parent seems to pain ok, but if you try to
select the text that is outside of the parent, the backgroun is corrupted.
3.- If the opacity isn't 100% are some problems:
           - The border isn't painted
           - The opacity is like 100%(the content isn't transparent)
roc+moz: I see the problems you describe in your testcase, but only if the
window is very little, if i load the test case and then meake the window little
the problem apear, but disapear making the window bigger again.

(Sorry for my bad english)

Comment 14

[Patrick C. Beard]

In the second case, it looks to me like when the text overflows the div, the 
background color of the view the text is in isn't being properly painted. I'd 
suspect layout rendering is the culprit. This may also explain the first 
attachment drawing artifacts. Handing back to somebody in layout to take a look.

Comment 15

[troy]

I can't tell which testcase you're referring to and exactly what the problem is 
but I doubt it's layout

If the fixed positioned element has text that overflows its bounds, then we mark 
the view as having transparent content and the part of the view that is opaque 
we paint with the background color, and the part that is transparent should 
display with whatever background is underneath

If you look at the view in question and see that it is marked as having 
transparent content, then layout is doing the correct thing

Comment 16

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

Attachment: Even simpler test case showing basic fixed-position bustage

Comment 17

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

Attachment 5411 [details] shows that a fixed-position DIV with no content gets trash 
drawn in its area. It doesn't seem to have anything to do with text overflowing. 
(If I put content in there, it just gets drawn on top of the trash.)

So it looks like these (all?) fixed-position elements are being incorrectly 
treated as opaque. Over to you people to figure out whether it's layout or the 
compositor :-).

Comment 18

[Andrew Thompson]

There's definately something up with Fixed positioning and overflow properties.

Quite often adding
overflow: hidden 
will result in the rendering being OK (or at least a lot better, until you
resize the window too small)
whereas adding
overflow: visible 
will give you a whole bunch of junk in the view,
bits of the previous page elements, bits of the toolbar etc. etc.

Since visible is the default many layout problems can be "cured" by adding 
overflow: hidden, but this is not a permenant solution

Comment 19

[Patrick C. Beard]

This requires that we correctly redraw every visible view that intersects each 
widget. The current display list creation code only considers views that lie 
along the path from the painted-widget's view up to the root view. We also need 
to consider widget-bearing views below the painted-widget's view in the tree. 
This is hard to explain in words. We need a good diagram to visualize this.

Comment 20

[Patrick C. Beard]

Reassigning all compositor bugs to kevin.

Comment 21

[Patrick C. Beard]

Reassigning all compositor bugs to kevin.

Comment 22

[Kevin McCluskey (gone)]

Moving to M16.

Comment 23

[Kevin McCluskey (gone)]

Moving to M18

Comment 24

[Kevin McCluskey (gone)]

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. 

Comment 25

[Uriel]

Attachment: the first testcase were invalid, this is a fixed version

Comment 26

[Uriel]

the original testcase was invalid, I attached a new version. The original bug 
seems fixed, but some problems remains: the opacity don't work well, and the 
text that overflows isn't transparent. I'll attach a new version of the 
testcase that shows better the actual problems. I think this shouldn't be 
marked as "future", IMHO we need to fix it before NS6 ships. Kevin, what 
milestone you think can we set?

Comment 27

[Uriel]

Attachment: new version of the testcase that show the problems with opacity and text overflow

Comment 28

[Hixie (not reading bugmail)]

As per meeting with ChrisD today, taking QA.

Comment 29

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

I have this working perfectly in my revamped nsViewManager2.

Comment 30

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

Attachment: Screenshot of patch in action

Comment 31

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

Attachment: Just showing off: screenshot with some lines wrapped in "z-index: 1"

Comment 32

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

Attachment: Ooops, here's the real image.

Comment 33

[Kevin McCluskey (gone)]

Robert: Looks great! 

Comment 34

[Hixie (not reading bugmail)]

Reassigning to Robert, who has a fix pending review in bug 39621.

Comment 35

[Hixie (not reading bugmail)]

Rubber stamping [nsbeta3-], since Robert's fix is slated for the next release
do to high risk considerations.

Comment 36

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

Attachment: Fixed the testcase to use -moz-opacity

Comment 37

[karnaze (gone)]

Can we resolve this one?

Comment 38

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

This should be fixed as of today, now that 39621 is fixed.

Comment 39

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

Looks fixed to me!

Comment 40

[Hixie (not reading bugmail)]

verified