Closed Bug 891607 Opened 10 years ago Closed 10 years ago

content is initially cut off when viewing in landscape mode


(Firefox for Android Graveyard :: Toolbar, defect)

23 Branch
Not set


(firefox23 verified, firefox24 verified, firefox25 verified, fennec23+)

Firefox 25
Tracking Status
firefox23 --- verified
firefox24 --- verified
firefox25 --- verified
fennec 23+ ---


(Reporter: chris, Assigned: kats)



(Keywords: regression)


(5 files)

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.
Attached image Before picture
Screenshot of the problem. See how the text and everything is cut off on the right.
Attached image After picture
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.
OS: Windows 7 → Android
Hardware: x86_64 → ARM
What device? What version of Android? Is this an issue on nightly, you can install it from ?
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.
tracking-fennec: --- → ?
Ever confirmed: true
Component: General → Graphics, Panning and Zooming
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.
tracking-fennec: ? → 23+
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.
I can reproduce this on the HTC One (4.2.2.) loading 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.
Attached file Logs.rar
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.
Attached image screenshots collage
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 in a first session.
Keywords: steps-wanted
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 
Urgh. Patch coming shortly.
Blocks: 860613
Attached patch PatchSplinter Review
[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
Attachment #782675 - Flags: review?(
Attachment #782675 - Flags: approval-mozilla-beta?
Attachment #782675 - Flags: approval-mozilla-aurora?
Comment on attachment 782675 [details] [diff] [review]

Review of attachment 782675 [details] [diff] [review]:

heh, whoops :)
Attachment #782675 - Flags: review?( → 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
5. Wait a few seconds, long enough for Gecko to come up
6. Hit enter
Comment on attachment 782675 [details] [diff] [review]

Typo fix, low risk, please land to branches asap for final beta go to build.
Attachment #782675 - Flags: approval-mozilla-beta?
Attachment #782675 - Flags: approval-mozilla-beta+
Attachment #782675 - Flags: approval-mozilla-aurora?
Attachment #782675 - Flags: approval-mozilla-aurora+
I built version 24.0a2 from source (including your patch) and I am not seeing this problem anymore.
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 25
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.