I noticed on articles on the guardian website on android I can now pinch to zoom out "too far", at which point the entire screen goes blank. This was discovered on the 2015-12-03 Nightly, I assume it's due to the new APZ. This page will reproduce: http://www.theguardian.com/politics/2015/dec/04/labour-sweep-to-conclusive-victory-in-oldham-byelection. It seems any guardian article will, and BBC ones too. Not tested other sites. It's not always easy to reproduce: there seems to be some resistance to zooming out too far, but which fails under certain circumstances. I've attached a video showing this happening.
Attachment was too big to upload to bugzilla. Here it is instead: https://youtu.be/v0u-elClgP0
I'd like to see this in person at some point, it's a little hard to tell what's going on from the video. I'll try to find you this week.
Jamie showed this to me in person. It's definitely an APZ issue but it wasn't obvious to me what was causing it. First step to debug this is probably to repro with layers dumping enabled and see if anything stands out there.
I'm not sure if this is related or not, but it might be. I was on the page http://www.thesun.co.uk/sol/homepage/article6676614.ece?utm_campaign=160106_GNRSUNBALLOT&utm_source=emailCampaign&utm_medium=email&utm_content= and encountered this bug again. And then the browser crashed with: Assertion failure: aTransform.Is2D(), at /home/jamie/mozilla/gecko/master/gfx/layers/composite/AsyncCompositionManager.cpp:208 On my nexus 6. Easily reproducable on this page, but I can't hit this assertion on others pages where I encounter this bug.
(In reply to Jamie Nicol [:jnicol] from comment #4) > Assertion failure: aTransform.Is2D(), at > /home/jamie/mozilla/gecko/master/gfx/layers/composite/ > AsyncCompositionManager.cpp:208 The reason this assertion should hold is described in some detail in bug 1202050 comment 5. We should investigate and see which of the assumptions described there aren't holding, and why. That said, I doubt this is related to zooming out; it's more likely to be related to the structure of the page in question.
(In reply to Botond Ballo [:botond] from comment #7) > I tried reproducing the crash described in comment 4 using a recently > nightly (Friday's) but wasn't able to. I also couldn't reproduce the > original bug, on either of the pages mentioned in comment 0 and comment 4. Note that I wasn't testing with a Nexus 6 (I was testing with a Motorola Razr). I wonder if the problem requires a particular device scale to reproduce. Jamie, do you know what the device scale on the Nexus 6 is?
I have only been able to reproduce on my nexus 6 and galaxy s6. both are 1440x2560, with 4963pi and 577dpi respectively. I cannot reproduce on devices with smaller screens.
Forward-duping to the bug with the fix. snorp got logs and we figured out the problem was a coordinate mismatch.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1239385
Jamie, with the fix for bug 1239385 in place, do you still see the problem described in comment 4? If so, any chance you could get a layer dump from around the time it happens? Thanks!
(note that the fennec nightly channel doesn't seem to be updating, bug 1240021). You can download a new nightly manually from https://archive.mozilla.org/pub/mobile/nightly/2016/01/2016-01-15-05-53-28-mozilla-central-android-api-11/
I cannot hit that assertion any more with a debug build including that patch
(In reply to Jamie Nicol [:jnicol] from comment #13) > I cannot hit that assertion any more with a debug build including that patch Thanks for testing! I guess that assertion was a complication of the bug that was fixed, then.
You need to log in before you can comment on or make changes to this bug.