Closed Bug 501627 Opened 16 years ago Closed 16 years ago

background image problems when page is zoomed (background disappears, zoom level)

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Version:
1.9.1 Branch
Platform:
x86
Windows Vista
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
status1.9.2 --- beta4-fixed
status1.9.1 --- ?

People

(Reporter: wolf, Assigned: roc)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(7 files, 2 obsolete files)

page in IE8 just after loading
492.77 KB, image/png
Details
IE8 after scrolling a bit
133.52 KB, image/png
Details
page freshly loaded in FF 3.5
637.68 KB, image/png
Details
again in FF 3.5, now I scrolled a bit
179.29 KB, image/png
Details
partial backout of bug 467283 that fixes this [not for checkin]
3.61 KB, patch
Details | Diff | Splinter Review
simplified testcase
279 bytes, text/html; charset=UTF-8
Details
adding test
2.81 KB, patch
jrmuizel
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729) While the page loads the tiled blue background image is visible. When loading is finished the background is missing in the left part of the page where my fixed width table now seems to block the background although the table itself has no background image or color (at least not in the upper part). The background is now still visible in the right part of the screen but when you scroll down the portions which become visible don't show the background at all. If you scroll back up it's missing there, too, then. All looked as expected during the last years until I switched from the lates 3.0x to 3.5 yesterday. The image is loaded through <BODY BACKGROUND="..."> and the code is trivial (and valid) HTML 4.01 Transitional. Reproducible: Always Steps to Reproduce: 1. load http://www.NassRasur.com/katalog.html 2. look how the screen looks while it loads and how it looks when loading is finished 3. scroll down and back up Actual Results: Step 2: background in the left part of the screen disappears after loading Step 3: background also disappears in the right part of the screen when scrolled Expected Results: The background should be visible everywhere. This is clearly a nasty regression and I consider it MAJOR as it will possibly make people lose trust in the rendering machine.
Summary: background image disappears after table loaded and when scrolling → background image partially disappears after page loaded and misses completely after scrolling
Summary: background image partially disappears after page loaded and misses completely after scrolling → background image partially disappears after page loads and misses completely after scrolling
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1pre) Gecko/20090630 Shiretoko/3.5.1pre I compared the layout with IE8 and see no difference at first glance. Can you provide a screenshot and indicate the problem or a minimal testcase?
Version: unspecified → 3.5 Branch
Here you see the page in IE8, background blue everywhere
Here I scrolled down a bit in IE8 and you still see blue background in the whole screenshot. View in a image viewer, not in your browser, as you might not see where the image ends -- any white region below the image ist just YOUR browser.
Here I loaded the page with Firefox 3.5 and while the blue background was visible while the page loaded, the part covered (but normally not blocked!) by the table in the left lost its background. The right part is still okay until I scroll (see next attachment)...
Here I scrolled down a bit in Firefox 3.5 and then up again. The part that scrolls in from below has no background and the part that scrolls back in from above now also lost it. View in an image viewer, not in your browser, as you might not see where the image ends and where your browser window begins.
Maybe limited to Windows or even Vista-only? Did not see the effect on other pages yet, only this (simple but long) one which is my own.
Well, I can reassure you, it looks fine with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1pre) Gecko/20090630 Shiretoko/3.5.1pre
Ria, thanks for the suggestion, creating a new profile provided valuable information: when I startet FF with the new profile the page loaded correctly! But since I view it somewhat enlarged normally, it was shown smaller in the new profile. So I zoomed it and "hey!" -- at a certain zoom level the effect becomes visible. If I call the smallest view #1 then the zoom levels #1 up to #7 are okay and #8 or larger lose the background! So this must be some regression in the zooming, was there a change regarding background images? Can you reproduce the effect now with my page when you zoom?
Yes indeed, when I press ctrl+ twice, the background disappears.
Status: UNCONFIRMED → NEW
Component: General → Layout: View Rendering
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout.view-rendering
Version: 3.5 Branch → 1.9.1 Branch
Is indeed a regression from Firefox 3.0.
Keywords: regression
I have adjusted the summary to reflect the real symptoms, was that okay?
Component: Layout: View Rendering → General
Product: Core → Firefox
Summary: background image partially disappears after page loads and misses completely after scrolling → background image problems when page is zoomed (background disappears, zoom level)
Version: 1.9.1 Branch → 3.5 Branch
Yes, thanks. Regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=49a032846a3a&tochange=31e5958cb97a In trunk builds the background appears black here.
Component: General → Layout
Product: Firefox → Core
QA Contact: layout.view-rendering → layout
Version: 3.5 Branch → 1.9.1 Branch
(In reply to comment #13) > In trunk builds the background appears black here. Regression range black background: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9213aa676ae6&tochange=c82f707141cd
The change from black background to not repainting (is that what you're saying happened) would probably be due to bug 482689, but that would be expected; the initial regression of failing to paint the tiled image would still be the real problem.
I checked that that initial regression is not bug 458898 (it was easy to back out), so my guess would be that it's most likely bug 467283, but that looks a good bit harder to back out.
I confirmed that this is a regression from http://hg.mozilla.org/mozilla-central/rev/992000e45526 Here's the patch that I used which backs out the nsLayoutUtils.cpp parts of that changeset; it makes this bug go away.
Attachment #386312 - Attachment description: partial backout of bug 467283 that fixes this → partial backout of bug 467283 that fixes this [not for checkin]
Attached file simplified testcase —
Steps to reproduce: 1. load this testcase 2. zoom in once 3. do anything to cause a repaint (scroll, switch windows) Actual results: repaints lead to garbage or what was there before
Flags: blocking1.9.1.1? → wanted1.9.1.x?
Assignee: nobody → roc
Attached patch fix (obsolete) — — Splinter Review
I don't know what this check is actually protecting against. It seems to me that checking the size of the tiled area is pointless. If there's error handling to do here, cairo can do it.
Attachment #386655 - Flags: review?
Attachment #386655 - Flags: review? → review?(joe)
Comment on attachment 386655 [details] [diff] [review] fix We use fill unmodified in a call to gfxContext::Fill(). If that doesn't cause a problem with > 32k, then that's fine. (Checking with Jeff to be sure.) Also you forgot to hg add the test.
Attachment #386655 - Flags: review?(joe)
Attachment #386655 - Flags: review?(jmuizelaar)
Attachment #386655 - Flags: review+
Whiteboard: [needs review]
Whiteboard: [needs review] → [needs landing]
Comment on attachment 386655 [details] [diff] [review] fix This code came from bug 367740. I'm not convinced that the check is no longer needed, though Joe claims that the test case from that bug no longer crashes. I think the situation warrants at least a little more investigation.
Attachment #386655 - Flags: review?(jmuizelaar) → review-
The patch in bug 367740 introduced 3 checks: 1) a check on the source image size when drawing a single tile 2) a check on the destination size when drawing a single tile (i.e., a check on the image size after scaling) 3) a check on the source image size when tiling The check I'm removing here is closest to #2, but we're checking the destination size after scaling *and* tiling (which obviously makes it easier for the check to fail...) I could change the code to just check the size of a single destination tile, but then again, we don't know whether the underlying Quartz bug triggers based on the size of a single tile or the size of the destination after tiling. https://bugzilla.mozilla.org/show_bug.cgi?id=328258#c84 indicates that the underlying Quartz bug was fixed in 10.5.2. Are are we still supporting 10.4 in Gecko 1.9.2? If so, can we tell if the underlying Quartz bug has been fixed in a 10.4 update?
(In reply to comment #22) > The check I'm removing here is closest to #2, but we're checking the > destination size after scaling *and* tiling (which obviously makes it easier > for the check to fail...) I could change the code to just check the size of a > single destination tile, but then again, we don't know whether the underlying > Quartz bug triggers based on the size of a single tile or the size of the > destination after tiling. I guess since we've never had a check for the post-tiling destination size, we should assume that it's not a problem. Anyone got 10.4 around so we can run John's test program?
Whiteboard: [needs landing]
I have a PPC mac running 10.4; I could give you access or you could let me know what to run.
I think you'd need to follow the instructions in https://bugzilla.mozilla.org/show_bug.cgi?id=328258#c40. Thanks!
The test in question includes <i386/ucontext.h>; it looks like it expects to be build on x86.
Surely the test doesn't rely on x86; jdaggett, can you help dbaron out so we can put this bug to bed, thanks?
status1.9.1: --- → ?
Flags: wanted1.9.1.x?
This program here doesn't depend on x86: https://bugzilla.mozilla.org/show_bug.cgi?id=328258#c38 Can we get someone to try it on 10.4?
Keywords: qawanted
I can reproduce the crash on 10.4.11 (which is the latest 10.4) by following the steps from bug 328258 comment 38.
Thanks Markus! If you apply the patch in this bug and then try the testcase in https://bugzilla.mozilla.org/show_bug.cgi?id=367740#c1, does it crash in 10.4?
Attached patch merged to trunk (obsolete) — — Splinter Review
It doesn't crash, yay! This is the patch that I used; nsThebesImage.cpp doesn't exist anymore.
Attachment #386655 - Attachment is obsolete: true
Attached patch adding test — — Splinter Review
See comment #22, comment #23, and comment #31.
Attachment #411139 - Attachment is obsolete: true
Attachment #411146 - Flags: review?(jmuizelaar)
Whiteboard: [needs review]
Attachment #411146 - Flags: review?(jmuizelaar) → review+
Alright. So the fact that bug 328258 comment 38 still crashes in 10.4 shows that the bug still exists in Quartz, but for some reason Gecko doesn't expose that crash (any more?). So was that AllowedImageSize check purely vestigal, or did we have a change somewhere else (Cairo, Thebes, imagelib, etc) that also avoids this Quartz bug?
See comment #22. Three checks were added, and it appears one of them (the one we care about here) is not needed. It probably never was needed.
http://hg.mozilla.org/mozilla-central/rev/54adec75b3ef
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [needs review] → [needs 192 landing]
Issue is Resolved - removing QA-Wanted Keywords - QA-Wanted query clean-up task
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: