891607 - content is initially cut off when viewing in landscape mode

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[chris]

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.

Comment 1

[chris]

Attachment: Before picture

Screenshot of the problem. See how the text and everything is cut off on the right.

Comment 2

[chris]

Attachment: 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.

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

What device? What version of Android? Is this an issue on nightly, you can install it from http://nightly.mozilla.org/ ?

Comment 4

[chris]

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.

Comment 5

[chris]

Yes, this is still an issue on nightly.

Comment 7

[Aaron Train [:aaronmt]]

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."

Comment 8

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 10

[Matt Brubeck (:mbrubeck)]

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.

Comment 11

[Brian Carpenter [:geeknik]]

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

Comment 12

[Aaron Train [:aaronmt]]

Any particular site? Does it happen all the time initially loading with the device in landscape orientation 100% of the time?

Comment 13

[Brian Carpenter [:geeknik]]

(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.

Comment 14

[Chris AtLee [:catlee]]

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.

Comment 16

[Aaron Train [:aaronmt]]

I can reproduce this on the HTC One (4.2.2.) loading http://cnn.com. I'll look for a regression range.

Comment 17

[Aaron Train [:aaronmt]]

This seems very intermittent for me making it difficult to find a range actually.

Comment 18

[u421692]

Attachment: Logs.rar

Comment 19

[u421692]

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.

Comment 20

[u421692]

Attachment: screenshots collage

Comment 21

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 22

[Aaron Train [:aaronmt]]

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.

Comment 23

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

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

Comment 24

[u421692]

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

Comment 25

[Kartikaya Gupta (email:[e-mail])]

Urgh. Patch coming shortly.

Comment 26

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch

[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 27

[Chris Lord [:cwiiis]]

Comment on attachment 782675 [details] [diff] [review]
Patch

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

heh, whoops :)

Comment 28

[Kartikaya Gupta (email:[e-mail])]

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

Comment 29

[Kartikaya Gupta (email:[e-mail])]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c45025e76586

Comment 30

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 782675 [details] [diff] [review]
Patch

Typo fix, low risk, please land to branches asap for final beta go to build.

Comment 31

[Kartikaya Gupta (email:[e-mail])]

https://hg.mozilla.org/releases/mozilla-aurora/rev/78d0bced73ab
https://hg.mozilla.org/releases/mozilla-beta/rev/c6834fe3d52d

Comment 32

[chris]

I built version 24.0a2 from source (including your patch) and I am not seeing this problem anymore.

Comment 33

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c45025e76586