[Browser][YouTube] User is not able to select the buttons in the YouTube Full Screen permission prompt.

VERIFIED FIXED in 2.2 S13 (29may)

Status

()

VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: Marty, Assigned: tnikkel)

Tracking

({regression, smoketest})

unspecified
2.2 S13 (29may)
ARM
Gonk (Firefox OS)
regression, smoketest
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master verified)

Details

(Whiteboard: [3.0-Daily-Testing], URL)

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 8607591 [details]
logcat-youtube-full-screen.txt

Description:
When the user tries to launch a YouTube video in full screen, they are given a permission prompt.  The user is not able to select the "Allow" and "Don't Allow" buttons.

The user can only press the Home button to dismiss the prompt.

Repro Steps:
1) Update a Flame to 20150519010201
2) Open the Browser and navigate to YouTube.com
3) Select a video and begin playback.
4) Select the Full Screen option and select either "Allow" or "Don't Allow" to dismiss the permission prompt.

Actual:
Tapping the buttons has no affect, the user cannot select the buttons to dismiss the prompt.

Expected:
Both buttons are selectable and function properly.

Environmental Variables:
Device: Flame 3.0 (Full Flash)
Build ID: 20150519010201
Gaia: 762cbd16712484f93f485e89f5363686540a3db7
Gecko: f65cc0022a0e
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Note: This issue occurs with both 319MB and 512MB memory.

Repro frequency: 8/8
See attached: Logcat, Video (URL)
(Reporter)

Comment 1

4 years ago
This issue does NOT occur on yesterday's Flame 3.0, or today's Flame 2.2 builds.
Both buttons are selectable and function properly.

Environmental Variables:
Device: Flame 3.0 (Full Flash)
Build ID: 20150518010206
Gaia: afea16de7a76c3b6d15c35fb4c37bac71c8ddc6a
Gecko: 35918b0441b4
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Environmental Variables:
Device: Flame 2.2 (Full Flash)
Build ID: 20150519002500
Gaia: 732acec6f37d13ccea6b0ddc48904a53a2970894
Gecko: 1389e6b8c065
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]:
Functional regression failing smoke tests.

Requesting a window.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qaurgent, regressionwindow-wanted
It might actually be a much much worse regression. Starting with today's build, I have been unable to interact (i.e. tap, focus, etc.) with several apps (Messages, Email) after those STR:
 - focus into a text field
 - press power, press again power
QA Contact: bzumwalt
Mozilla-Inbound Regression Window:

Last working Mozilla-Inbound build:
Device: Flame 3.0
Build ID: 20150518000944
Gaia: afea16de7a76c3b6d15c35fb4c37bac71c8ddc6a
Gecko: 6dd7de1d3027
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

First broken Mozilla-Inbound build:
Device: Flame 3.0
Build ID: 20150518005844
Gaia: afea16de7a76c3b6d15c35fb4c37bac71c8ddc6a
Gecko: b769ef24faed
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0


Working Gaia with Broken Gecko issue DOES reproduce:
Gaia: afea16de7a76c3b6d15c35fb4c37bac71c8ddc6a
Gecko: b769ef24faed

Working Gecko with Broken Gaia issue does NOT reproduce:
Gaia: afea16de7a76c3b6d15c35fb4c37bac71c8ddc6a
Gecko: 6dd7de1d3027


Mozilla-Inbound Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6dd7de1d3027&tochange=b769ef24faed


Issue appears to occur due to changes made in bug 1153589
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qaurgent, regressionwindow-wanted
Kartikaya, can you take a look at this please? This might have been caused by the landing for bug 1153589. We may need that backed out since this is a smoke test blocker.
Blocks: 1153589
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
(In reply to KTucker [:KTucker] from comment #5)
> Kartikaya, can you take a look at this please? This might have been caused
> by the landing for bug 1153589. We may need that backed out since this is a
> smoke test blocker.

I do confirm also that a local revert of bug 1153589 fixes the issue on my Z3 Compact
(Assignee)

Comment 7

4 years ago
I backed out bug 1153589 in

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

The sheriff assured me it would make the next nightly.
Based on back out in comment 7.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Smoketest blocker
blocking-b2g: 3.0? → 3.0+
We'll need to figure out what happened here before we can re-land bug 1153589.
Assignee: nobody → tnikkel
(Reporter)

Comment 11

4 years ago
This issue is verified fixed on the latest Flame 3.0 build.
YouTube Fullscreen buttons are both selectable and functional.

Environmental Variables:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150521010203
Gaia: 5a7f87b1505ba89b586372cbbbe9507d1016c40c
Gecko: b9424d63fe35
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Status: RESOLVED → VERIFIED
status-b2g-master: affected → verified
Flags: needinfo?(pbylenga)
(Assignee)

Comment 12

4 years ago
The layer trees (containerless vs containerful) are pretty much exactly at I expect. The metrics are moved from the root container layer to it's children.

There is one other change, the scrollparent for some subframes is set properly with containerless, and not set at all for containerful (because it set the scroll parent to null in nsLayoutUtils::PaintFrame even though we have a displayport). But I fixed the bug so that the scroll parents were set properly for containerful and this bug didn't show up. I also made the scrollparents not be set for containerless and it didn't fix this bug. So this doesn't appear to be related.
Created attachment 8609299 [details]
log

I can repro this problem and it looks like the dialog is in a PaintedLayer that is a child of the root (layer 0xb04a9800 in the attached dump). Neither that layer nor the root get metrics and so there's no APZC covering the dialog. The hit test returns a null APZC and so there's nothing to handle the tap.
(Assignee)

Comment 14

4 years ago
I debugged this with Botond's help last night and we came up with a plan to fix it. If there is no apzc then return the root apzc with the same layers id.
Hm. I guess we can try it. I hope that doesn't result in scrolling things behind other things and such.
Flags: needinfo?(pbylenga)
(Assignee)

Updated

4 years ago
Depends on: 1168629
(Assignee)

Updated

4 years ago
Depends on: 1168630
(Assignee)

Comment 16

4 years ago
I put the patches that fix this bug in bug 1168629 and bug 1168630 (for when bug 1153589 lands again).
status-b2g-v2.5: --- → verified
Target Milestone: --- → 2.2 S13 (29may)
status-b2g-v2.5: verified → ---
Moving the bug to the component where the regression came from.
Component: Gaia::Browser → Layout
Product: Firefox OS → Core
You need to log in before you can comment on or make changes to this bug.