Subframe rendered incomplete when zoomed

RESOLVED FIXED in Firefox 39

Status

()

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: botond, Assigned: botond)

Tracking

({regression})

Trunk
mozilla39
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-b2g:2.2+, firefox39 fixed, b2g-v2.1 unaffected, b2g-v2.2 fixed, b2g-master fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
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.
(Assignee)

Comment 1

4 years ago
The problem goes away if low-precision painting is disabled in the developer settings.
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.
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.
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.
Blocks: 1099298
(Assignee)

Comment 6

4 years ago
I will investigate.
Assignee: nobody → botond
(Assignee)

Comment 7

4 years ago
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.
(Assignee)

Comment 8

4 years ago
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.
Attachment #8570668 - Flags: review?(tnikkel)
(Assignee)

Comment 9

4 years ago
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.
blocking-b2g: --- → 2.2?
(Assignee)

Comment 10

4 years ago
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?
Flags: needinfo?(npark)
(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!
Flags: needinfo?(npark)
(Assignee)

Comment 12

4 years ago
(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!
Attachment #8570668 - Flags: review?(tnikkel) → review+
https://hg.mozilla.org/mozilla-central/rev/0b080a60b195
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
(Assignee)

Comment 15

4 years ago
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.
Attachment #8570668 - Flags: approval-mozilla-b2g37?
blocking-b2g: 2.2? → 2.2+
Attachment #8570668 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
You need to log in before you can comment on or make changes to this bug.