Long pages have missing tiles and generally messed-up rendering

VERIFIED FIXED in Firefox 34

Status

()

Firefox for Android
Toolbar
VERIFIED FIXED
4 years ago
2 years ago

People

(Reporter: kats, Assigned: mattwoodrow)

Tracking

({regression, reproducible})

34 Branch
Firefox 34
Other
Android
regression, reproducible
Points:
---

Firefox Tracking Flags

(fennec34+)

Details

Attachments

(4 attachments)

Created attachment 8470522 [details]
View at top of page

On a nexus 4 running today's nightly, load https://bugzilla.mozilla.org/show_bug.cgi?id=708765. Tiles are missing st the top of the page. If you scroll down to the bottom there are more tiles missing. Zooming in and out at this point makes the rendering even more screwy. See attached screenshots.

This doesn't seem to happen on Aurora so it's probably a recent regression.
Created attachment 8470523 [details]
Screwy rendering
tracking-fennec: --- → ?
Keywords: regression, regressionwindow-wanted
I don't see this at all on my Nexus 5 with today (08/10)'s Nightly.
Inbound bisection range:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=326c91338df0&tochange=06b540d3667a

Let me know if you want me to do local builds to bisect further and/or have patches you want me to try.
Blocks: 1042423
Flags: needinfo?(matt.woodrow)
Keywords: regressionwindow-wanted
(Assignee)

Comment 5

4 years ago
Unfortunately I can't reproduce this on my android device (galaxy s2).

It could be something to do with pixman's 16bit integers, and scrolling beyond that range, we've had similar bugs to that before.

If you could narrow it down to an individual changeset then I can try figure out what changed.
Flags: needinfo?(matt.woodrow)
(In reply to Matt Woodrow (:mattwoodrow) from comment #5)
> If you could narrow it down to an individual changeset then I can try figure
> out what changed.

The bug doesn't manifest with part 3, but at part 4 it starts happening. It really looks like tiles are just getting misplaced somehow. I suppose it might be related to pixman's 16bit integers but I'm not sure how the two would be connected.

(In reply to Aaron Train [:aaronmt] from comment #2)
> I don't see this at all on my Nexus 5 with today (08/10)'s Nightly.

One thing I noticed while bisecting on inbound is that this didn't happen on the new default bugzilla skin ("Mozilla") but it did happen on the Dusk skin that I'm using. i.e. I had to log in to bugzilla for my skin to be applied and the bug to manifest. Perhaps with the default skin the page is shorter and it doesn't run into this problem.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #6)
> (In reply to Matt Woodrow (:mattwoodrow) from comment #5)
> > If you could narrow it down to an individual changeset then I can try figure
> > out what changed.
> 
> The bug doesn't manifest with part 3, but at part 4 it starts happening. It
> really looks like tiles are just getting misplaced somehow. I suppose it
> might be related to pixman's 16bit integers but I'm not sure how the two
> would be connected.
> 
> (In reply to Aaron Train [:aaronmt] from comment #2)
> > I don't see this at all on my Nexus 5 with today (08/10)'s Nightly.
> 
> One thing I noticed while bisecting on inbound is that this didn't happen on
> the new default bugzilla skin ("Mozilla") but it did happen on the Dusk skin
> that I'm using. i.e. I had to log in to bugzilla for my skin to be applied
> and the bug to manifest. Perhaps with the default skin the page is shorter
> and it doesn't run into this problem.

Aha. Thanks. I see this now on my GSGS5 (Nightly 08/11).
Keywords: reproducible
(Assignee)

Comment 8

4 years ago
Cool, reproduces for me too now.
(Assignee)

Comment 9

4 years ago
Android debug builds are not a pleasant experience.

This is a repeat of bug 1034593.

Cairo allocates a temporary mask surface internally when doing rounded rect clipping (which your theme uses).

My patch changed the clipping slightly and cairo ended up trying to allocate a surface the size of the entire document. This fails, and cairo goes into error state preventing anything else from happening during that update. The end result is we don't actually update tiles when this happens, so we end up with blank or stale content displayed (possibly from an unrelated spot due to tile recycling).

Nical, is there any reason why DrawTargetCairo can't just clip itself during the constructor? That avoids an invasive cairo change, but also stops us from being bitten by this again.
(Assignee)

Updated

4 years ago
Assignee: nobody → matt.woodrow
Flags: needinfo?(nical.bugzilla)
(Assignee)

Comment 10

4 years ago
Created attachment 8471356 [details] [diff] [review]
Clip to the surface extents
Attachment #8471356 - Flags: review?(jmuizelaar)
tracking-fennec: ? → 34+
https://hg.mozilla.org/mozilla-central/rev/c031275796fc
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
(In reply to Matt Woodrow (:mattwoodrow) from comment #9)
> Nical, is there any reason why DrawTargetCairo can't just clip itself during
> the constructor? That avoids an invasive cairo change, but also stops us
> from being bitten by this again.

Late answer, sorry. Yeah sounds good (and already landed anyway :) ).
Flags: needinfo?(nical.bugzilla)
\o/
Status: RESOLVED → VERIFIED
Created attachment 8474102 [details]
Screenshot of github/git on aurora

Oh! I just ran into this issue on another page in the latest Aurora build. See attached screenshot. It also occurs in current release Fennec, but not the latest nightly which includes this fix. I'm not sure if it was this fix that fixed it but that seems the most likely explanation. Given that, should this fix be uplifted? The page on which i saw it was https://github.com/git/git?files=1
Flags: needinfo?(matt.woodrow)
(Assignee)

Comment 18

4 years ago
I'm not entirely sure. The symptoms look the same, which suggests some sort of cairo error.

My patch would at least log the cairo error to logcat, and fix it if it happens to be the same one.
Flags: needinfo?(matt.woodrow)
Keywords: regressionwindow-wanted
I did a try build [1] with the patch from this bug on aurora and it did fix the problem. I think we should uplift this patch at least to aurora if not beta.

Kevin, not sure why you flagged regressionwindow-wanted here but it may not be necessary.

[1] https://tbpl.mozilla.org/?tree=Try&rev=b55f08b56738

Updated

4 years ago
Keywords: regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.