[B2G][Browser][Youtube]Viewing a video in portrait fullscreen and returning to homescreen causes youtube to display inappropriately

RESOLVED FIXED in Firefox 34

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: rkuhlman, Assigned: kats)

Tracking

({regression})

unspecified
mozilla34
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.0+, firefox32 wontfix, firefox33 wontfix, firefox34 fixed, b2g-v1.4 unaffected, b2g-v2.0 fixed, b2g-v2.1 fixed)

Details

(Whiteboard: [273MB-Flame-Support])

Attachments

(3 attachments)

Posted file YoutubeLog.txt
Youtube.com will not display correctly if the after user presses home button to return to homescreen while watching a video in fullscreen in portrait orientation, 

Youtube will display incorrectly in one of two ways:
1) Youtube content is is shrunken down and large sections of empty whitespace are displayed
2) The video still plays in fullscreen dimensions, resulting in only part of the screen being visible

Repro Steps:
1) Update a Flame to BuildID: 20140723040201
2) Launch Browser and navigate to www.youtube.com
3) Begin watching a video
4) Set the video to fullscreen, and hold device in portrait orientation
5) Press the home button twice to return to homescreen
6) Tap on browser app.

Actual:
Youtube page is displayed inappropriately. 

Expected:
Youtube page displays as expected

Master M/C Environmental Variables:
Device: Flame Master M/C MOZ
BuildID: 20140723040201
Gaia: 01d86c8cc615658694b114ca5711763efc4ef205
Gecko: d0f6259e8446
Version: 34.0a1
Firmware Version: v122


Notes:

Repro frequency: 75% 
See attached: logcat, screenshot
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QAWanted for branch checks.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Contact: jmercado
After working with the reporter I found that this issue requires a 273 mb configuration to reproduce on Flame.

This issue does occur on Flame 2.1 (273 mb), 2.0 Flame (273 mb), and 2.1 Buri.

Environmental Variables:
Device: Flame Master (273 mb)
BuildID: 20140723121905
Gaia: 15c84c943e41ad834640a45e1e1c2ac804168af7
Gecko: 30907d52c4c2
Version: 34.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0
BuildID: 20140723062208
Gaia: ed998af8528c8b1bbd3aee6975ee9a1bdec1d429
Gecko: c74478151c2f
Version: 32.0 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Buri Master
BuildID: 20140723121905
Gaia: 15c84c943e41ad834640a45e1e1c2ac804168af7
Gecko: 30907d52c4c2
Version: 34.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0



Issue does not occur on 2.1 Flame (512 mb), 2.0 Flame (512 mb), 1.4 Flame (512 mb), 1.4 Flame (273mb)

Environmental Variables:
Device: Flame Master (512 mb)
BuildID: 20140723121905
Gaia: 15c84c943e41ad834640a45e1e1c2ac804168af7
Gecko: 30907d52c4c2
Version: 34.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0 (512 mb)
BuildID: 20140723062208
Gaia: ed998af8528c8b1bbd3aee6975ee9a1bdec1d429
Gecko: c74478151c2f
Version: 32.0 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Environmental Variables:
Device: Flame 1.4
BuildID: 20140723075714
Gaia: 6e4eaa5befce9c1812e07bcc78b2138645bdbe7a
Gecko: 2d16ba0b45bc
Version: 30.0 (1.4) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Environmental Variables:
Device: Flame 1.4
BuildID: 20140723075714
Gaia: 6e4eaa5befce9c1812e07bcc78b2138645bdbe7a
Gecko: 2d16ba0b45bc
Version: 30.0 (1.4) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Whiteboard: [273MB-Flame-Support
Whiteboard: [273MB-Flame-Support → [273MB-Flame-Support]
[Blocking Requested - why for this release]:
Smoketest blocker, nominating for 2.0 as it's a 1.4 to 2.0 regression.
blocking-b2g: --- → 2.0?
Component: Gaia::Browser → Gaia::System::Window Mgmt
Josh - I think this needs to be checked on 319 MB & needs a window. Can you fix this?
Flags: needinfo?(jmitchell)
QA-wanted to test the affected builds in 319mb (first)
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Keywords: qaurgent
QA Contact: jmercado → pcheng
Original STR's step 4 should be to put the phone in Landscape, not portrait. And then at Step 6 go back to youtube in Portrait.

Issue still reproducible on 2.1 Flame master, 2.0 Flame, and 2.1 Buri. Comment 3 is still true. The repro rate overall is about 1/3 to 1/5.

Device: Flame (319MB mem)
Build ID: 20140725034810
Gaia: 3a06aa58245eaf848242d6d1497c1af536fffabd
Gecko: 6c0971104909
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame (319MB mem)
Build ID: 20140724190006
Gaia: 9b6d7357031f2412b18a2fb140d5c974842d4393
Gecko: fbb3b8be8f6c
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Buri
Build ID: 20140725034810
Gaia: 3a06aa58245eaf848242d6d1497c1af536fffabd
Gecko: 6c0971104909
Version: 34.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Not requesting regression-window based on extremely low repro rate
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: qaurgent
Component: Gaia::System::Window Mgmt → Graphics
Product: Firefox OS → Core
striking smoketest keyword based on new (lower) repro rate (below 50%)
Keywords: smoketest
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
(In reply to Joshua Mitchell [:Joshua_M] from comment #8)
> Not requesting regression-window based on extremely low repro rate

How long does it take to reproduce the bug on average?
Flags: needinfo?(jmitchell)
(In reply to Jason Smith [:jsmith] - At Work Week, Slow to Respond from comment #10)
> (In reply to Joshua Mitchell [:Joshua_M] from comment #8)
> > Not requesting regression-window based on extremely low repro rate
> 
> How long does it take to reproduce the bug on average?

3-5 minutes depending on how many times you have to retry to hit the 25% repro rate.
Flags: needinfo?(jmitchell)
Triage thinks this will likely block YT certification, so +
blocking-b2g: 2.0? → 2.0+
So, no chance of getting a regression window?  Also, given that it appears to be memory specific, can we request that this gets tested on QRD with 8x10 and 8926?
(In reply to Milan Sreckovic [:milan] from comment #13)
> So, no chance of getting a regression window?  Also, given that it appears
> to be memory specific, can we request that this gets tested on QRD with 8x10
> and 8926?

I don't think we can do that. QA does not have builds & QRD devices. We're also supposed to support the minimum Flame spec as well (319 MB Flame), so this bug does fall under the supported device configurations we need to support.

I'll flag regression window wanted here since it seems we're going to have to do this even if the repro rate is low.
QA Whiteboard: [QAnalyst-Triage+][lead-review+]
I meant "ask QC to test on QRD".  But, yes, thanks for trying for the regression window, that would be a lot of help.
Mozilla inbound regression window:

Last Working Environmental Variables:
Device: Buri
Build ID: 20140708144432
Gaia: 740faa5d0060fb218b407cf224330654ddf833a5
Gecko: 99c726eaa286
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken Environmental Variables:
Device: Buri
Build ID: 20140708150218
Gaia: 740faa5d0060fb218b407cf224330654ddf833a5
Gecko: a50ea7808d85
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=99c726eaa286&tochange=a50ea7808d85

There is only one bug in the pushlog, Bug 1027593.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
(In reply to Pi Wei Cheng [:piwei] from comment #16)
> Mozilla inbound regression window:

Awesome!  Thanks for a very quick turnaround on this.
Assignee: nobody → bugmail.mozilla
Blocks: 1027593
Component: Graphics → Panning and Zooming
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Posted patch PatchSplinter Review
I was able to reproduce this intermittently so I added some logging to figure out what was going on. It turns out that HandlePossibleViewportChange pulls the "old screen size" from mLastRootMetrics.mCompositionBounds when computing how much to adjust the zoom by on rotation. While this mostly works (because the mCompositionBounds is updated with the new screen size), it can potentially not work if we get a RecvUpdateFrame call with different composition bounds in the middle of a rotation. This is what was happening. The log indicated that:

- HandlePossibleViewportChanged was called with mInnerSize = 854x293
- This set mLastRootMetrics.mCompositionBounds to 854x293
- An "old" RecvUpdateFrame came in which set mLastRootMetrics.mCompositionBounds to 854x480
- HandlePossibleViewportChanged was called again with mInnerSize = 854x293
- On this second call, the oldScreenSize was taken as 854x480, and so the zoom was adjusted when it shouldn't have been.

The fix stops using mLastRootMetrics.mCompositionBounds as the source of the old screen size, because it is unreliable. Instead, it just has the callers pass in the old screen size. At the one callsite that the screen size actually changes, the caller saves the old screen size and passes it in. This fixes the problem as far as I can tell.
Attachment #8468532 - Flags: review?(botond)
Comment on attachment 8468532 [details] [diff] [review]
Patch

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

::: dom/ipc/TabChild.cpp
@@ +89,5 @@
>  #define BROWSER_ELEMENT_CHILD_SCRIPT \
>      NS_LITERAL_STRING("chrome://global/content/BrowserElementChild.js")
>  
> +#define TC_LOG(...)
> +// #define TC_LOG(...) printf_stderr("TC: " __VA_ARGS__)

Is "TC" sufficiently greppable? :)
Attachment #8468532 - Flags: review?(botond) → review+
It seemed to be in my case, but I changed it to "TABC" just to be safe.

Landed on b2g-inbound: https://hg.mozilla.org/integration/b2g-inbound/rev/a21244068b7f
https://hg.mozilla.org/mozilla-central/rev/a21244068b7f
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.