1051592 - Long pages have missing tiles and generally messed-up rendering

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

Attachment: 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.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Attachment: Screwy rendering

Comment 2

[Aaron Train [:aaronmt]]

I don't see this at all on my Nexus 5 with today (08/10)'s Nightly.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I bisected nightlies. Jul 23 is good, Jul 24 is bad.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=82df3654cd80&tochange=a91ec42d6a9c

Comment 4

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 5

[Matt Woodrow (:mattwoodrow)]

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.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

(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.

Comment 7

[Aaron Train [:aaronmt]]

(In reply to Kartikaya Gupta (email:[e-mail]) 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).

Comment 8

[Matt Woodrow (:mattwoodrow)]

Cool, reproduces for me too now.

Comment 9

[Matt Woodrow (:mattwoodrow)]

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.

Comment 10

[Matt Woodrow (:mattwoodrow)]

Attachment: Clip to the surface extents

Comment 11

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/028c43cd12a5

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Backed out for Windows bustage.
https://hg.mozilla.org/integration/mozilla-inbound/rev/9443cda3374e

https://tbpl.mozilla.org/php/getParsedLog.php?id=45998219&tree=Mozilla-Inbound

Comment 13

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c031275796fc

Comment 14

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c031275796fc

Comment 15

[Nicolas Silva [:nical]]

(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 :) ).

Comment 16

[Kartikaya Gupta (email:[e-mail])]

\o/

Comment 17

[Kartikaya Gupta (email:[e-mail])]

Attachment: 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

Comment 18

[Matt Woodrow (:mattwoodrow)]

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.

Comment 19

[Kartikaya Gupta (email:[e-mail])]

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