The default bug view has changed. See this FAQ.

Page background goes black after panning

RESOLVED FIXED in Firefox 14

Status

()

Core
Layout
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: Mark Funk, Assigned: jrmuizel)

Tracking

({regression, reproducible, testcase})

Trunk
mozilla15
ARM
Android
regression, reproducible, testcase
Points:
---

Firefox Tracking Flags

(firefox14 fixed, firefox15 fixed, blocking-fennec1.0 +)

Details

(Whiteboard: [layout], URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1
Build ID: 20120507171005

Steps to reproduce:

1. Loaded http://www.reddit.com/r/Android/comments/ta97g/what_dont_you_like_about_android/ via a hyperlink on reddit.com/r/Android
2. Scrolled about half way down the page


Actual results:

The page's background was replaced with a solid black color making everything unreadable.


Expected results:

The page's background stays the same
(Reporter)

Comment 1

5 years ago
This happens on my Samsung Galaxy S2 Skyrocket which has an Adreno 220 GPU
OS: Windows 7 → Android
Hardware: x86_64 → ARM
I was able to reproduce this issue using the latest Nightly (2012-05-08) on 
Samsung Galaxy SII (2.3.4) and HTC Desire (2.2)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reproduced, and quite unpleasant.

--
Tested via: Nightly (05/08)
* Galaxy Nexus (Android 4.0.4), Sony Ericsson Xperia Play (Android 2.3.4)
blocking-fennec1.0: --- → ?
Keywords: regression, regressionwindow-wanted, reproducible

Updated

5 years ago
Summary: Page background goes black after panning far enough → Page background goes black after panning

Updated

5 years ago
status-firefox14: --- → affected
status-firefox15: --- → affected
Unfortunately this has been a long-standing issue for a while now :(
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 671302
I guess something made it easier to reproduce now; I haven't seen this before at all.
It should only happen on really long pages with a background, I think. If you feel like there is a regression here that makes this more apparent or obvious then we should bisect to find out when it happened.
Status: RESOLVED → REOPENED
Component: General → Graphics
Product: Fennec Native → Core
QA Contact: general → thebes
Resolution: DUPLICATE → ---
Version: Firefox 14 → Trunk
This issue doesn't occur on:
Maple 13.0a1 (2012-03-12)
http://hg.mozilla.org/projects/maple/rev/e88141f7f64c

but it occurs on:
Maple 13.0a1 (2012-03-13)
http://hg.mozilla.org/projects/maple/rev/16e04eaadc14

Possible range:
http://hg.mozilla.org/projects/maple/pushloghtml?fromchange=e88141f7f64c&tochange=16e04eaadc14
Keywords: regressionwindow-wanted
Let's see if this is something we can make better (not use a black background), even if we can't fix the real bug.
Assignee: nobody → joe
blocking-fennec1.0: ? → +
Well, it doesn't make much sense, but...

The first bad revision is:
changeset:   89088:a5980ce21d40
user:        Kartikaya Gupta <kgupta@mozilla.com>
date:        Mon Mar 12 12:03:38 2012 -0400
summary:     Bug 732564 - Distinguish between changes where we should sync-update the Java viewport and where the compositor has to update Java. r=Cwiiis
Blocks: 732564
qawanted for two reasons: one is for a reduced testcase; alternately, a different example of this on the internet, as I can't reproduce it reliably on Reddit any more :(
Keywords: qawanted
I can, however, reliably reproduce this on Aurora, strangely enough.
Ah, but I can reproduce this on Nightly on http://nomnompaleo.com
testcase wanted, but we need to reliable reproduce this first.
Keywords: testcase-wanted
Created attachment 625814 [details]
testcase

Tap on the link (or just scroll down a while) to get the black background.
The background that is used in the testcase is pointing to http://static.tumblr.com/fftf9xi/27ll9xup0/texture_main.jpg which is a rather large image.

Updated

5 years ago
Keywords: qawanted, testcase-wanted → testcase

Updated

5 years ago
Whiteboard: [gfx]
pixman's analyze_extent is returning FALSE here, which means that we're just trying to draw beyond the range pixman supports. This will need a fix in layout. The coordinates need to not be too big.

I can reproduce very similar problems on GDI (i.e., bug 671302) due to the same underlying limitation in pixman.
Assignee: joe → jet
Component: Graphics → Layout
QA Contact: thebes → layout
Whiteboard: [gfx] → [layout]

Comment 16

5 years ago
I'm not sure how we'd fix this in Layout as there isn't a single bottleneck to check for extents prior to a paint. I think our best bet here is to implement comment 8 and paint the default HTML background color and not black when we overflow the extents.
(Assignee)

Comment 17

5 years ago
I'll try something.
Assignee: jet → jmuizelaar
(Assignee)

Comment 18

5 years ago
Created attachment 627348 [details] [diff] [review]
This seems to do the trick
Comment on attachment 627348 [details] [diff] [review]
This seems to do the trick

Review of attachment 627348 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/thebes/gfxUtils.cpp
@@ +513,5 @@
>  
> +    gfxMatrix m = aUserSpaceToImageSpace;
> +    if (doTile) {
> +        m.y0 = fmod(m.y0, aImageRect.height);
> +        m.x0 = fmod(m.x0, aImageRect.height);

Should this one be aImageRect.width?
(Assignee)

Comment 20

5 years ago
Created attachment 627355 [details] [diff] [review]
Better
Attachment #627348 - Attachment is obsolete: true
(Assignee)

Comment 21

5 years ago
Created attachment 627605 [details] [diff] [review]
Move the translation within pixman's range
Attachment #627355 - Attachment is obsolete: true
Attachment #627605 - Flags: review?(roc)
Comment on attachment 627605 [details] [diff] [review]
Move the translation within pixman's range

Review of attachment 627605 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/thebes/gfxUtils.cpp
@@ +518,1 @@
>  #endif

Use #ifdef MOZ_OPTIMIZE_MOBILE ... #else ... #endif instead of #ifndef
Attachment #627605 - Flags: review?(roc) → review+
(Assignee)

Comment 23

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/b82ef4adc4d8
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/b82ef4adc4d8
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED

Updated

5 years ago
status-firefox15: affected → ---
(Assignee)

Comment 25

5 years ago
Comment on attachment 627605 [details] [diff] [review]
Move the translation within pixman's range

[Approval Request Comment]
Bug caused by (feature/regressing bug #): pixman coordinate limits
User impact if declined: black backgrounds instead of images on some pages
Testing completed (on m-c, etc.): been on m-c for quite a while
Risk to taking this patch (and alternatives if risky): mobile only, perhaps some image drawing wrongness.
String or UUID changes made by this patch: None
Attachment #627605 - Flags: approval-mozilla-beta?
Attachment #627605 - Flags: approval-mozilla-aurora?
Comment on attachment 627605 [details] [diff] [review]
Move the translation within pixman's range

This is already on Aurora. Please land on beta ASAP.
Attachment #627605 - Flags: approval-mozilla-beta?
Attachment #627605 - Flags: approval-mozilla-beta+
Attachment #627605 - Flags: approval-mozilla-aurora?
http://hg.mozilla.org/releases/mozilla-beta/rev/23daca1b1aa7
status-firefox14: affected → fixed
status-firefox15: --- → fixed
See Also: → bug 995129
See Also: bug 995129
You need to log in before you can comment on or make changes to this bug.