1136914 - Subframe rendered incomplete when zoomed

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Botond Ballo [:botond]]

STR:
  1. Load http://people.mozilla.org/~bballo/iframe.html in the B2G browser.
  2. Zoom in.
  3. Scroll down to the bottom.

Expected results:
  The visible portion of the subframe is rendered completely.

Actual results:
  Part of the visible portion of the subframe remains blank.

Comment 1

[Botond Ballo [:botond]]

The problem goes away if low-precision painting is disabled in the developer settings.

Comment 2

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

The blankness goes away, but the jankiness of scrolling and the fact that the frame scrolls faster than your finger still remains. I suspect these are all related, as we've had issues like this in the past.

Comment 3

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

I bisected this down and got a result that didn't make much sense to me, but here it is:

build at https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-central-flame-kk-eng/2014/11/2014-11-24-10-01-36/ is good
build at https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-central-flame-kk-eng/2014/11/2014-11-24-16-02-09/ is bad

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=be4ba3d5ca9a&tochange=5c4d07e2199e

Comment 4

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

I strongly suspect the sources.xml for https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-central-flame-kk-eng/2014/11/2014-11-24-10-01-36/ is lying, because it points to cset be4ba3d5ca9a which is smack in the middle of a merge to m-c. Maybe the build was running concurrently with the hg -> git conversion, and so it got some garbage cset with unknown state? It looks like it was a manually triggered nightly build too since the timestamp is 10am instead of the usual 4am/4pm.

Assuming this is the case, it widens the regression range to this:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8c02f3280d0c&tochange=5c4d07e2199e which includes bug 1099298 as a very possible culprit.

Comment 5

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

So yeah, cset be4ba3d5ca9a does *not* include the changes from bug 1099298, which is why it showed up as a "good" build. The pushlog link in comment 3 is invalid because it assumes both changes are m-c revisions which they are not.

Going to tag this as a regression from bug 1099298 although I didn't narrow down the range to that specific change but it's the most obvious.

Comment 6

[Botond Ballo [:botond]]

I will investigate.

Comment 7

[Botond Ballo [:botond]]

Confirmed that backing out bug 1099298 locally solves the problem.

I'm somewhat surprised we didn't notice this regression until now, given that bug 1099298 landed Nov 21.

Comment 8

[Botond Ballo [:botond]]

Attachment: Don't lose scale from parent document when descending into subdocument

The problem was that I misunderstood the semantics of the 'ContainerLayerParameters(xScale, yScale, incomingParameters)' constructor. It doesn't *add* (by which I mean multiply) the given scales into the incoming scales, it *replaces* them, whereas that wasn't my intention.

Comment 9

[Botond Ballo [:botond]]

This regression affects APZ platforms since Gecko 36 - so, effectively, B2G 2.2 onwards.

Requesting blocking as this is a pretty serious rendering issue: scrollable iframes on a zoomed page can be drawn incompletely, drawn partially in low-res, scroll jankily, scroll faster than the finger movement, and exhibit other misbehaviours as a result.

Comment 10

[Botond Ballo [:botond]]

This isn't the first time we've regressed the behaviour of subframes on zoomed page (see e.g. bug 913659, bug 915734, bug 946833, bug 956802). No-Jun, do you think we could add this page (http://people.mozilla.org/~bballo/iframe.html) to MozTrap?

Comment 11

[No-Jun Park [:njpark]]

(In reply to Botond Ballo [:botond] from comment #10)
> This isn't the first time we've regressed the behaviour of subframes on
> zoomed page (see e.g. bug 913659, bug 915734, bug 946833, bug 956802).
> No-Jun, do you think we could add this page
> (http://people.mozilla.org/~bballo/iframe.html) to MozTrap?

Actually, I just realized that I can add this to my 3x a week graphics sanity test that I do.  Just added, and will let you know if it regresses.  Thanks!

Comment 12

[Botond Ballo [:botond]]

(In reply to No-Jun Park [:njpark] from comment #11)
> Actually, I just realized that I can add this to my 3x a week graphics
> sanity test that I do.  Just added, and will let you know if it regresses.

Great - thanks, No-Jun!

Comment 13

[Botond Ballo [:botond]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0b080a60b195

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0b080a60b195

Comment 15

[Botond Ballo [:botond]]

Comment on attachment 8570668 [details] [diff] [review]
Don't lose scale from parent document when descending into subdocument

I'm going ahead and requesting uplift as I'm not sure if anyone looks at '2.2?' requests regularly at this point.

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
  Bug 1099298.

User impact if declined: 
  Scrollable iframes on a zoomed page can be drawn incompletely,
  drawn partially in low-res, scroll jankily, scroll faster than
  the finger movement, and exhibit other misbehaviours.

Testing completed: 
  - Tested locally.
  - Patch has been on m-c since 2015-03-03.
  - No-Jun added the test case to the graphics sanity test (see comment 11).

Risk to taking this patch (and alternatives if risky): 
  Low - it's a obvious one-liner fix.
  The only thing affected is scrollable iframes on a zoomed page on B2G.

String or UUID changes made by this patch:
  None.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/2df322a91b53