Created attachment 622102 [details] resize testcase While looking at bug 750645, I noticed some other weird behaviour; I created a small testcase that shows lots of brokenness on Android. The testcase has a blue canvas that covers the entire body, with a 1px red outline on the outer pixel of the canvas (not a border, drawn in the canvas itself). It then has an absolute positioned div with a link in it that it keeps pushed up against the right side of the window, much like the FishIE benchmark. 1 - On a Galaxy Nexus in portrait mode, the page starts out as 980x1413. The right side of the canvas isn't visible, and neither is the div with the link. You can pinch to zoom out and see the rest of the canvas, but you can't ever pan there nor can you zoom out any further and have it stick. The box with the link isn't visible, even though it should be at left = 889.15 according to the displayed value. 2 - If you then zoom in at portrait mode, the dimensions don't change (good), but now you can pan to the right... and see a giant strip of white around the right and bottom of the canvas that shouldn't be there. 3 - Zoom all the way out and rotate to landscape. You can now zoom out even further, and you see all parts of the page, including the "Click Me" link. However, the white strips still remain. 4 - If you click "Click Me", it might work; in which case the page will get zoomed in so that the canvas fills the space 100% correctly. But after that, the Click Me won't work and you'll still be able to pan to the white space to the right... where if you click in the white space where the link would be if it was against the edge of the pannable area, you can trigger the link.
Created attachment 622103 [details] resize testcase Fixed a tiny thing in the testcase. (move box to left=0px before calling getBoundingClientRect)
Attachment #622102 - Attachment is obsolete: true
Jeff suspected that if the canvas was a simple <div> or wasn't there at all that the issues wouldn't happen -- I tested both, and whether it's a div or not there at all doesn't make any difference. The behaviour is the same. A version that uses a div is at http://conduit.bitops.com/~vladimir/misc/resize-div.html if that's helpful.
I took a look at what's happening on initial load. Content (the size reported in the canvas) thinks the page size is 980, but the layer compositor claims the css page size is 720.
It looks like the problem here is related to overflow:hidden. See bug 747493
Assignee: nobody → vladimir
blocking-fennec1.0: ? → +
Removing overflow:hidden fixes all the issues with this. Duping to 747493.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 747493
Verify that this bug is fixed on nightly (v15 - 18 May). The bug still affects beta (v14.0b2) Tested on sgs2 cyanogenmod 9 (ics) Tested url: http://ie.microsoft.com/testdrive/Performance/FishIETank/
You need to log in before you can comment on or make changes to this bug.