Closed Bug 928441 Opened 6 years ago Closed 6 years ago
content view truncated in landscape
In today's nightly on may websites the content view stops four fifths of the way across the screen. the page can be dragged into view if zoomed but isn't otherwise visible. Doesn't occur with every site. mozilla.org seems fine; bugzilla.mozilla.org shows the problem. Rotating to portrait it looks ok.
> In today's nightly... Yesterday's build works? Which tablet? I'm unable to reproduce on my Nexus 7 (2013).
2013-10-18 build on Samsung Galaxy 10, GT-P7510, Samsung android 4.0.4.
previous nightly was ok, but I don't remember if I updatwd ywsterday or the day before
If this is a recent regression I'd like to get an inbound regression range. This may be the same as bug 928824 which might have more reliable STR.
Mihai, you seem to be able to reproduce in your filed bug, can you find a regression-window?
Inbound regression window: 1382046795 - good 1382047566 - bad http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=999ed39dc0e7&tochange=2668b492d852 It seems that bug Bug 916125. Clip scroll layer items to the scroll port so the resulting layers have the proper clip introduced this regression.
Was there some specific info you wanted from me? Or just a fix?
My question would be should bug 916125 be backed out or should we take a forward fix. I would rather not ship this issue on Aurora when this gets uplifted next week.
Tracking for firefox27 and passing this on to Timothy as its a fallout from 916125. what are the next steps here ?
I hope to put a little time into looking into this before backing out, unless it's deemed serious enough for immediate back out.
I ran a bisect today which confirms bug 916125 as the origin of the clipping issue. https://github.com/mozilla/mozilla-central/commit/75d860d22497c243c22f9c7c5742d52d2132af3e The scroll port or outer display port must have incorrectly calculated bounds? It's a pretty serious usability regression, so if you can't solve it in a day I think you should back it out. We're close to uplift.
Is there a reason we think 26 is unaffected? Bug 916125 was uplifted to aurora already, so 26 should be affected.
Confirming Aurora is affected (Samsung Galaxy Tab 3 10", Android 4.1) - Aurora (10/23).
Confirmed Aurora 26.0a (2013-10-23) is affected (Samsung Galaxy Tab 10.1, Android 4.0.4).
Here's the fix tn and I came up with. It fixes the bug on my Galaxy Tab and doesn't regress bug 916125 on B2G. Pushed to try at https://tbpl.mozilla.org/?tree=Try&rev=ad125f18b5aa
Comment on attachment 821695 [details] [diff] [review] Patch Discussing a bit more with tn to make the comments better.
Updated commit message and code comment.
Attachment #821713 - Flags: review?(tnikkel) → review+
Attachment #821713 - Flags: review?(roc) → review+
Comment on attachment 821713 [details] [diff] [review] Patch [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 916125 User impact if declined: very noticeable content clipping issues on tablets in fennec Testing completed (on m-c, etc.): locally Risk to taking this patch (and alternatives if risky): low risk, i think. i tested it reasonably well to ensure there weren't other obvious regressions. String or IDL/UUID changes made by this patch: none (Note: bug 916125 was uplifted to 26, which is currently on aurora. If this uplift request isn't approved before the upcoming merge then 26 will be on beta and this will be a beta uplift request)
Attachment #821713 - Flags: approval-mozilla-aurora?
6 years ago
I would rather get this fixed in Aurora rather then relnoting. Just need this uplifted by Wednesday.
Verified as fixed on Nightly 27.0a1 (2013-10-27) on Samsung Galaxy Tab(Android 4.0.4).
Attachment #821713 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.