Closed
Bug 1212960
Opened 9 years ago
Closed 9 years ago
User can see homescreen background behind SHB when watching full screen videos in browser on youtube or other sources
Categories
(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect, P3)
Tracking
(blocking-b2g:2.5+, b2g-master affected)
People
(Reporter: AdamA, Assigned: mikehenrty)
References
Details
(Keywords: regression, Whiteboard: [2.5-Daily-Testing][Spark][Systemsfe])
Attachments
(4 files)
Summary (title) Field:
User can see homescreen background behind SHB when watching full screen videos in browser
Description:
when users are watching a video on youtube or any other site in the browser and the video is made fullscreen they can see the homescreen background. This occurs on landscape and portrait mode. this appears to happen with all videos on the browser that are full screen
Repro Steps:
1) Update a Aries to 20151008143352
2) Open browser and navigate to a video on youtube
3) Make video fullscreen
4) Observe bottom of screen behind SHB
Actual:
The homescreen background is seen behind the SHB
Expected:
It is expected that the fullscreen video expands to take up the area behind the SHB
Environmental Variables:
Device: Aries 2.5 [Full Flash]
Build ID: 20151008143352
Gaia: 4973f57cd8f9a62a95f783a24eac32da2bde99fc
Gecko: 1f4cf75c894862cf3634d6014d8de9c807a054a7
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Repro frequency: 10/10
See attached: screenshot, logcat
Reporter | ||
Comment 1•9 years ago
|
||
I am unable to check this issue on flame devices because we do not have flame builds made after this issue was introduced,
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.2:
unaffected → ---
Flags: needinfo?(ktucker)
Whiteboard: [2.5-Daily-Testing][Spark]
Reporter | ||
Comment 2•9 years ago
|
||
Reporter | ||
Comment 3•9 years ago
|
||
Reporter | ||
Comment 4•9 years ago
|
||
This issue DOES NOT occur on a previous Aries 2.5 build
Environmental Variables:
Device: Aries 2.5
Build ID: 20151007110945
Gaia: 0195b1842ffd794b0f9ed46530d69fbfc4d779db
Gecko: 5f0050425ae2f3908c715fa44b992b25474c0eed
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Result:
The full screen video is behind SHB.
Keywords: regression
Reporter | ||
Updated•9 years ago
|
Summary: User can see homescreen background behind SHB when watching full screen videos in browser → User can see homescreen background behind SHB when watching full screen videos in browser on youtube or other sources
Updated•9 years ago
|
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage+]
Reporter | ||
Comment 5•9 years ago
|
||
This issue is occurring on the latest Flame 2.5 Engineering build.
Environmental Variables:
Device: Flame 2.5
BuildID: 20151008062742
Gaia: 4973f57cd8f9a62a95f783a24eac32da2bde99fc
Gecko: 1f4cf75c894862cf3634d6014d8de9c807a054a7
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 44.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.
Result:
The homescreen background is seen behind the SHB
Whiteboard: [2.5-Daily-Testing][Spark] → [2.5-Daily-Testing][Spark][Systemsfe]
Updated•9 years ago
|
Assignee: nobody → sleedavid
Updated•9 years ago
|
Assignee: sleedavid → nobody
QA Contact: sleedavid
Updated•9 years ago
|
blocking-b2g: 2.5? → 2.5+
Updated•9 years ago
|
Priority: -- → P3
Updated•9 years ago
|
Assignee: nobody → rakhavan
Comment 6•9 years ago
|
||
Mozilla Inbound:
Last Working:
Environmental Variables:
Device: Flame 2.5
BuildID: 20151006200636
Gaia: 0019347fbaedc9d54f2f3436fff17aeb22968174
Gecko: b45bd6bd7d574f633a67b3fdf0256e6ae7b57d36
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
RESULT:
When viewing a youtube video in fullscreen mode in portrait or landscape, the Software Home Button appears normal.
First Broken:
Environmental Variables:
Device: Flame 2.5
BuildID: 20151006184733
Gaia: 0019347fbaedc9d54f2f3436fff17aeb22968174
Gecko: 28503debfad483d648693afa8f20ffdb477a386e
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
RESULT:
When viewing a youtube video in fullscreen mode in portrait or landscape, the Software Home Button appears as a negative banner showing the movie behind the SHB and negative banner.
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=28503debfad483d648693afa8f20ffdb477a386e&tochange=b45bd6bd7d574f633a67b3fdf0256e6ae7b57d36
This issue may be caused by changes made by Bug 1126230
Also Repro in build:
REPRO:
Environmental Variables:
Device: Aries 2.5
BuildID: 20151012110146
Gaia: 87f5c9d55ab6a77dcfa48a3f3a8b4f5016f3c657
Gecko: 0b69d304f861d0038fb78f1d52b0f5d13ef7c6fe
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
RESULT:
When viewing a youtube video in fullscreen mode in portrait or landscape, the Software Home Button appears as a negative banner showing the movie behind the SHB and negative banner.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(mshuman)
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Updated•9 years ago
|
Flags: needinfo?(mshuman)
Comment 7•9 years ago
|
||
Since this looks like a regression in gecko I'll bounce off this bug. If changes are needed in gaia, just ping me, I'm happy to help.
Assignee: rakhavan → nobody
Comment 8•9 years ago
|
||
Xidorn, can you take a look at this please? This might have been caused by the work done for bug 1126230.
Blocks: top-layer
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(quanxunzhen)
Comment 9•9 years ago
|
||
I'm not sure what exactly happens there, but I can describe what bug 1126230 does.
Bug 1126230 changes how we display fullscreen element. Before that change, we just make fullscreen element a fixed element with the screen size and topmost z-index, and we use a stylesheet to override some properties of all its ancestors to cancel anything which may catch its position or affect its display, which include z-index, opacity, mask, clip-path, filter, clip, transform, will-change.
After that change, we start using top-layer for fullscreen element, which put the fullscreen element on the topmost of all things directly, so we no longer need that stylesheet override.
However, this is not true for <iframe mozbrowser>, because putting this element in the top-layer would make fullscreen element cover the fullscreen notification, and cause test failure on Gaia (see bug 1126230 comment 125 and https://dxr.mozilla.org/mozilla-central/rev/0b69d304f861d0038fb78f1d52b0f5d13ef7c6fe/layout/style/ua.css#285).
But we already removed that override anyway, so now if any ancestor of <iframe mozbrowser> has any property I listed above, it may catch the fullscreen browser element and stop it from being completely fullscreen.
It seems we have two ways to fix it:
A. add a mechanism in Gecko to make it possible to put something on top of the top-layer (bug 1210628), so that we can change the notification to be displayed on top, and remove the special case for <iframe mozbrowser>
B. add some code in Gaia stylesheet to remove properties on ancestor of <iframe mozbrowser> which catches it
I prefer B, because A requires conjunction work between Gecko and Gaia, but I don't think it is easy to land them together to avoid test failure because of an intermediate state. Also I'm actually not keen to push that mechanism before we are really clear about how we should handle that in the general web.
So I think this is something should be fixed in Gaia. You could probably add an attribute or class to the root of the system view when the content enters fullscreen, which you can catch via listening to the "mozfullscreenchange" event. This is also how we currently do in the XUL browser, because <xul:browser> cannot be in the top-layer by nature. An additional note that, please do not use :-moz-full-screen-ancestor pesudo class to do that, because we are going to remove it in the near future.
Flags: needinfo?(quanxunzhen)
Assignee | ||
Comment 10•9 years ago
|
||
(In reply to Xidorn Quan [:xidorn] (UTC+10, no dst) from comment #9)
> An additional note that,
> please do not use :-moz-full-screen-ancestor pesudo class to do that,
> because we are going to remove it in the near future.
Is there an alternative to this pseudo-selector? We use it in the system app in several places [1].
1.) https://github.com/mozilla-b2g/gaia/search?utf8=%E2%9C%93&q=%3A-moz-full-screen-ancestor&type=Code
Flags: needinfo?(quanxunzhen)
Comment 11•9 years ago
|
||
(In reply to Michael Henretty [:mhenretty] from comment #10)
> (In reply to Xidorn Quan [:xidorn] (UTC+10, no dst) from comment #9)
> > An additional note that,
> > please do not use :-moz-full-screen-ancestor pesudo class to do that,
> > because we are going to remove it in the near future.
>
> Is there an alternative to this pseudo-selector? We use it in the system app
> in several places [1].
No. This pseudo-selector is almost useless for web content, because it is simply impossible to put anything on top of fullscreen element there now, and thus nothing is visible outside the fullscreen element in general. <iframe mozbrowser> is the only exception for HTML document.
In addition, this selector would become hard to maintain efficiently when we are going to implement the latest Fullscreen API spec because of removal of the hierarchy restriction.
On the other hand, it seems to me that it shouldn't be too hard to replace this selector with an event handler and a class or attribute, especially given that the code you listed only uses :-moz-full-screen-ancestor with #screen element.
Given that this selector is becoming hard to maintain, and it only makes sense for our specific cases, and it is not hard to polyfill it in JS, I'm not going to introduce any alternative to it in Gecko.
Please correct me if there is anything I missed.
Flags: needinfo?(quanxunzhen)
Comment 12•9 years ago
|
||
Although I said "near future", it wouldn't be too near, so I guess you should have enough time to do the replacement. I don't actually have a definite plan for removing that yet.
Assignee | ||
Comment 13•9 years ago
|
||
Ok, thanks for the info. I'll take a look here.
Assignee: nobody → mhenretty
Comment 14•9 years ago
|
||
Assignee | ||
Comment 15•9 years ago
|
||
Comment on attachment 8673098 [details] [review]
[gaia] mikehenrty:bug-1212960-fullscreen-video-shb > mozilla-b2g:master
I'm working on a test now, but Etienne can you give me a sanity check on this approach?
Attachment #8673098 -
Flags: feedback?(etienne)
Comment 16•9 years ago
|
||
Comment on attachment 8673098 [details] [review]
[gaia] mikehenrty:bug-1212960-fullscreen-video-shb > mozilla-b2g:master
Left a few comments on github, not sure I fully understand what's happening yet.
Also I wasn't able to reproduce the bug on master so it's not helping :)
Attachment #8673098 -
Flags: feedback?(etienne)
Assignee | ||
Comment 17•9 years ago
|
||
Comment on attachment 8673098 [details] [review]
[gaia] mikehenrty:bug-1212960-fullscreen-video-shb > mozilla-b2g:master
Ok, I added a test. The problem is that this bug does not reproduce on Mulet for whatever reason. But I figured I'd add a test (which tests in two different ways) to at least have some sort of future proofing. Etienne, will you take a look?
Attachment #8673098 -
Flags: review?(etienne)
Comment 18•9 years ago
|
||
Comment on attachment 8673098 [details] [review]
[gaia] mikehenrty:bug-1212960-fullscreen-video-shb > mozilla-b2g:master
Kudos on the testing effort! It's definitely useful coverage.
Attachment #8673098 -
Flags: review?(etienne) → review+
Assignee | ||
Comment 19•9 years ago
|
||
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 20•9 years ago
|
||
This issue is verified fixed on the latest Flame and Aries 2.5 builds.
The SHB displays properly in full screen browser videos, and the homescreen wallpaper is not visible behind it.
Environmental Variables:
Device: Aries 2.5
BuildID: 20151019104907
Gaia: f75bd584aca0a751a5bed115800250faa8412927
Gecko: d3e87bb40753327550143ba8ac8ee27b300cd4a9
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Environmental Variables:
Device: Flame 2.5
BuildID: 20151019030208
Gaia: f75bd584aca0a751a5bed115800250faa8412927
Gecko: 1a157155a4fe0074b3d03b54fe9e466472c2cd56
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•