Closed
Bug 752799
Opened 12 years ago
Closed 12 years ago
Page background goes black after panning
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
mozilla15
People
(Reporter: cmf1292, Assigned: jrmuizel)
References
()
Details
(Keywords: regression, reproducible, testcase, Whiteboard: [layout])
Attachments
(2 files, 2 obsolete files)
346 bytes,
text/html
|
Details | |
1.93 KB,
patch
|
roc
:
review+
joe
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
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
This happens on my Samsung Galaxy S2 Skyrocket which has an Adreno 220 GPU
OS: Windows 7 → Android
Hardware: x86_64 → ARM
Comment 2•12 years ago
|
||
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
Comment 3•12 years ago
|
||
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: --- → ?
Updated•12 years ago
|
Summary: Page background goes black after panning far enough → Page background goes black after panning
Updated•12 years ago
|
status-firefox14:
--- → affected
status-firefox15:
--- → affected
Comment 4•12 years ago
|
||
Unfortunately this has been a long-standing issue for a while now :(
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Comment 5•12 years ago
|
||
I guess something made it easier to reproduce now; I haven't seen this before at all.
Comment 6•12 years ago
|
||
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.
Updated•12 years ago
|
Status: RESOLVED → REOPENED
Component: General → Graphics
Product: Fennec Native → Core
QA Contact: general → thebes
Resolution: DUPLICATE → ---
Version: Firefox 14 → Trunk
Comment 7•12 years ago
|
||
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
Comment 8•12 years ago
|
||
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: ? → +
Comment 9•12 years ago
|
||
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
Comment 10•12 years ago
|
||
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
Comment 11•12 years ago
|
||
I can, however, reliably reproduce this on Aurora, strangely enough.
Comment 12•12 years ago
|
||
Ah, but I can reproduce this on Nightly on http://nomnompaleo.com
Comment 13•12 years ago
|
||
testcase wanted, but we need to reliable reproduce this first.
Keywords: testcase-wanted
Comment 14•12 years ago
|
||
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•12 years ago
|
Updated•12 years ago
|
Whiteboard: [gfx]
Comment 15•12 years ago
|
||
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•12 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 18•12 years ago
|
||
Comment 19•12 years ago
|
||
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•12 years ago
|
||
Attachment #627348 -
Attachment is obsolete: true
Assignee | ||
Comment 21•12 years ago
|
||
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•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/b82ef4adc4d8
Target Milestone: --- → mozilla15
Comment 24•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b82ef4adc4d8
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
status-firefox15:
affected → ---
Assignee | ||
Comment 25•12 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 26•12 years ago
|
||
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?
Comment 27•12 years ago
|
||
http://hg.mozilla.org/releases/mozilla-beta/rev/23daca1b1aa7
status-firefox15:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•