Closed Bug 8489 Opened 21 years ago Closed 21 years ago

Undefined background when mixing widgets with background images

Categories

(Core :: Layout, defect, P2, major)

x86
Windows 95
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: ian, Assigned: dcone)

References

()

Details

(Whiteboard: [TESTCASE] - have fix)

See the URI quoted above. When a widget is on a page with an image for a
background, as below:

  <body style="background: url(any.gif)">
     <textarea>Help!</textarea>
  </body>

...then the background becomes undefined.

This happens with <textarea>, <input>, <select>, and probably all widgets.
It happens with both native and gfx widgets.
Blocks: 3061
Blocks: 1240
*** Bug 9084 has been marked as a duplicate of this bug. ***
No longer blocks: 1240
*** Bug 8844 has been marked as a duplicate of this bug. ***
Just noting a couple of things:
(1) The URL from bug #8844 is http://www.headsoftware.co.uk/taiu.html, and
  the testcase is http://bugzilla.mozilla.org/showattachment.cgi?attach_id=519
(2) attach_id=519 does *not* have a problem when using gfx widgets on win95
(3) however, Ian's test case (the URL for this report) looks especially funky
  when using gfx widgets
Whiteboard: [TESTCASE]
Target Milestone: M8
See also bug 4029, which shows identical behaviour but is caused by fixed
positioning. (Fixed positioning uses native widgets, so the root cause is
very likely the same).

I am marking this bug M8, since bug 4029 is M8.
Uh, Ian, bug #4029 is an i18n bug --- which bug did you really mean ;-)
I meant bug 4209. Much sorryness...
moving to m9. beard's on vacation
Assignee: beard → troy
Component: Compositor → Layout
This is an artifact of the image being corrupted or unavailable, right? Then the
code that does image tiling needs to check for this case and draw something.
Status: NEW → ASSIGNED
No, I don't think that's the issue. The image is fine, things are rendered
wrong.
Assignee: troy → beard
Status: ASSIGNED → NEW
Component: Layout → Compositor
This is behaving very strangely, and it must be a compositor problem involving
child views that have widgets. Take the simple example below and change
"url.gif" so it's a valid gif file.

Then display the URL and notice that the background of the page displays as
gargabe. If you obscure the window (with another window) and then bring it back
to the top, the newly exposed area displays okay _if_ you didn't cover up the
form element. If the form element is obscured, too, then garbage is displayed in
the newly exposed area
Assignee: beard → troy
Component: Compositor → Layout
Status: NEW → ASSIGNED
After thinking about it again, it can't be a compositor bug because it displays
fine if you use a solid background color instead of a background URL. I'm going
to have to check the CVS log and see if anyone's been mucking with the
background image rendering code
Assignee: troy → dcone
Status: ASSIGNED → NEW
Don, the problem appears to be in the PaintBackground() code where you recently
made a change to speed up tiling by creating bigger tiles.

It looks like you bitblt from one part of the screen to another. This won't work
(on Windows anyway), because the form element's widget is there and we end up
copying it as well

If we're going to expand the image and make a bigger tile, then we need to do
that off screen. I thought there was existing image library code that would do
this for us when building the image
Target Milestone: M9 → M8
Changing this to M8, because it is a common enough problem we are going to see a
lot of bug reports about this. For example, http://www.espn.com also has this
problem
Severity: normal → major
Priority: P3 → P2
Whiteboard: [TESTCASE] → [TESTCASE] - have fix
don has a fix. is going to post to the bug.  troy, can you review?
are there other goo reviewers?  lets get this checked into the
trunk when the tree opens for m9, and we can decide to pull the
diff on the branch on Wed. morning.
Status: NEW → ASSIGNED
Have fix: will test tonight, tommarow morning
Basically I push clipping state, set the clip to the entire region, did the
tile, and poped back the old clip state.  Kevin M reviewed code.  Also told
solution at Raptor all hands meeting and made sure this was the correct thing to
do.


The diff file:

Index: nsCSSRendering.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/style/src/nsCSSRendering.cpp,v
retrieving revision 3.55
diff -r3.55 nsCSSRendering.cpp
2018a2019
>
2019a2021,2024
>     // XXX pushing state to fix clipping problem, need to look into why the
clip is set here
>     aRenderingContext.PushState();
>     PRBool  clip;
>     aRenderingContext.SetClipRect(srcRect, nsClipCombine_kReplace, clip);
2032a2038,2039
>     // setting back the clip from the background clip push
>     aRenderingContext.PopState(clip);
Additinal fix.. Chris Yeh will put the following diff into m8
Tested on top 100, and ESPN.com and the sites listed here, all seems well.
Don Cone

DIFF

Index: nsCSSRendering.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/style/src/nsCSSRendering.cpp,v
retrieving revision 3.55
diff -r3.55 nsCSSRendering.cpp
2002a2003,2012
>     // create a bigger tile
>     // XXX pushing state to fix clipping problem, need to look into why the
clip is set here
>     aRenderingContext.PushState();
>     PRBool  clip;
>     nsRect  clipRect;
>     clipRect = srcRect;
>     clipRect.width = x1-x0;
>     clipRect.height = y1-y0;
>     aRenderingContext.SetClipRect(clipRect, nsClipCombine_kReplace, clip);
>
2019c2029
<     // create a bigger tile
---
>
2023c2033,2037
<     // use the tile to fill in the rest of the image
---
>      // setting back the clip from the background clip push
>     aRenderingContext.PopState(clip);
>
>
>    // use the tile to fill in the rest of the image
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Fixed in the July 14th (1999071417) build.
*** Bug 10079 has been marked as a duplicate of this bug. ***
*** Bug 10079 has been marked as a duplicate of this bug. ***
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Not fixed according to comments in bug 10079.
I dont see any problems, what exactly is the current bug.   www.espn looks good
as of the 7/20/99 build to me.
Target Milestone: M8 → M9
Moving from M8 to M9 whilst you'all resolve  M8 is out the door.
This will only happen if the double buffering is turned off.
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Based on the original description in the description, I believe this specific
problem has been fixed. On the Aug 6th build, the background is displayed.
You need to log in before you can comment on or make changes to this bug.