127.35 KB, image/png
196.94 KB, image/png
66.32 KB, application/rar
1.14 MB, image/png
1.11 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release) Build ID: 20130703181823 Steps to reproduce: This seems to happen most often when I click on a link in another Android app (usually Plume) and the link opens in Firefox. This happens when I have the device in landscape orientation. This is on a Nexus 7 tablet. Actual results: When the page loads, the right half of the screen is blank, cutting off the content. If I rotate the device into portrait orientation and then back to landscape mode, the problem corrects itself and the page displays correctly. Expected results: The content should be able to fill the entire width of the screen the first time.
Screenshot of the problem. See how the text and everything is cut off on the right.
Screenshot from after I rotate the device to portrait mode and back to landscape mode. This is how I expect the site to appear the first time.
What device? What version of Android? Is this an issue on nightly, you can install it from http://nightly.mozilla.org/ ?
The device is a Nexus 7 running Cyanogenmod 10.1 (Android 4.2.2). I just installed the nightly. I'll try it for a day or so and let you know if the problem continues.
Yes, this is still an issue on nightly.
From the dupe "The device in question is a tablet, not a phone (used in landscape). I am using up-to-date FF Beta from Google Play. FWIW, this also happened on nightly a while back. This is using CM10 (=Android 4.1 Jellybean) on an HP TouchPad. Also happens on a new profile."
I've seen this behaviour too on my Galaxy Q in landscape. I haven't gotten reliable STR yet, I suspect it is a race condition that sometimes results in the window resize message to get dropped. I remember that code being a bit iffy, I should do a proper audit of it.
Assignee: nobody → bugmail.mozilla
I am also seeing this frequently in Aurora 23 on my Motorola Xoom. If it helps for regression-window hunting, this was first reported on the nightly channel on 2013-04-24 in bug 865508.
I am seeing this behavior on 3 different devices: Nexus 7 (stock Android 4.2.2) CPU: ARM Cortex-A9 Nvidia Tegra 3 T30L GPU: Nvidia GeForce ULP (Tegra 3) Nexus 10 (stock Android 4.2.2) CPU: Samsung Exynos 5250 GPU: Mali T604 LG Spectrum II (stock Android 4.1.2) CPU: Snapdragon S4 GPU: Adreno 225
Any particular site? Does it happen all the time initially loading with the device in landscape orientation 100% of the time?
(In reply to Aaron Train [:aaronmt] from comment #12) > Any particular site? Does it happen all the time initially loading with the > device in landscape orientation 100% of the time? Every website I've tested does it 100% of the time in landscape orientation. If I flip it to portrait and back to landscape, it fixes itself. I've never seen it happen in portrait orientation, so if I load it in portrait and switch to landscape, it's fine.
Similar behaviour for me as well. It happens on most sites that I try and visit, and I need to rotate to portrait and back to landscape to have it use the full width.
6 years ago
Duplicate of this bug: 897335
I can reproduce this on the HTC One (4.2.2.) loading http://cnn.com. I'll look for a regression range.
QA Contact: aaron.train
This seems very intermittent for me making it difficult to find a range actually.
Environment: Device: Samsung Galaxy Tab(Android 4.0.4) Build: Firefox for Android 25.0a1(2013-07-24) I've spent some time trying to reproduce this issue and tried to find some steps to reproduce but without any luck. Overall, the action performed we're: changing the orientation of the device, and opening other pages in the same tab. There we're several issues, all regarding the painting of the screen(blank page, stretched image, page cut off). I've taken screenshots, and saved logs. I don't know how useful the logs are since logcat was running all the time while trying to reproduce the issue.
I ran into this again yesterday and spent some time observing the behaviour and then trying to reproduce. I couldn't get consistent STR but I made the following observations which I'm noting here for when I get around to actually debugging this: - The visible content width is the same as the screen height in landscape, indicating it is a rotation/resize event that gets dropped somewhere - The page can still be dragged using the blank space on the right side of the screen, so the LayerView itself is the right size and is getting touch events properly - The shadow at the top and bottom edges of the page visible in overscroll are also truncated. This indicates the LayerRenderer code is passing around the wrong viewport size. - When pinching out as far as I can go, the page still behaves as if it has the full screen width. That is, it goes into pinch-overscroll based on the screen width rather than the painted width. This means the PZC has a different (correct) notion of the viewport size compared to the LayerRenderer.
I have a device that reproduces this 100% now. This seems reproducible for me on my Galaxy S4 (4.3) starting Nightly (from a cold-start state) in landscape and heading to CNN.com in a first session.
this is a big user annoyance that is 100% reproducible on nexus 7 and nexus 4 using aaron's steps from comment 22. luckily there is a workaround, but it would REALLY nice :-) if we could somehow slip this into 23 to prevent a surge of negative feedback
The regression window is: mozilla-central: the commit that introduced the bug good build: 18.04.2013 bad build: 19.04.2013 -pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3ada6a2fd0c6&tochange=64d6d002e888
Urgh. Patch coming shortly.
[Approval Request Comment] Bug caused by (feature/regressing bug #): bug 860613 User impact if declined: sometimes on startup the page is cut off. rotating the device fixes the issue, but it's still pretty ugly Testing completed (on m-c, etc.): locally Risk to taking this patch (and alternatives if risky): very low risk, mobile-only String or IDL/UUID changes made by this patch: none
Comment on attachment 782675 [details] [diff] [review] Patch Review of attachment 782675 [details] [diff] [review]: ----------------------------------------------------------------- heh, whoops :)
Attachment #782675 - Flags: review?(chrislord.net) → review+
For the record, the STR to reproduce this reliably are: 1. Hold device in landscape mode 2. Start Fennec 3. AS SOON AS Fennec starts, click on the URL bar. 4. Type in cnn.com 5. Wait a few seconds, long enough for Gecko to come up 6. Hit enter
6 years ago
Comment on attachment 782675 [details] [diff] [review] Patch Typo fix, low risk, please land to branches asap for final beta go to build.
I built version 24.0a2 from source (including your patch) and I am not seeing this problem anymore.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 25
You need to log in before you can comment on or make changes to this bug.