Closed Bug 1171761 Opened 9 years ago Closed 9 years ago

[Aries] Volume adjustments trigger a "ghost" permissions dialog with no content, after I've entered full-screen video

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:-)

RESOLVED DUPLICATE of bug 1171201
blocking-b2g -

People

(Reporter: dholbert, Assigned: sotaro)

References

()

Details

(Whiteboard: [spark])

STR:
 1. Load a video file in the browser app, e.g. http://media.tinyvid.tv/3ufz3nboeyyr.ogg

 2. Tap the video to make controls show up, and tap fullscreen button.

 3. Tap "Allow" on the permissions prompt.

 4. Use volume buttons to adjust volume. OR: Take a screenshot. (Both of these trigger a dropdown-notification from the top of the screen)

ACTUAL RESULTS:
When the dropdown appears (for volume or screenshot) at the top of the screen, the rest of the screen changes back to rendering a blank permissions prompt.

EXPECTED RESULTS: The rest of the screen shouldn't change when the volume/screenshot dropdown appears.
I'm using an Xperia Z3C (aries) device, w/ up-to-date Firefox 3.0 from dogfood channel.
This looks like it might be related to the graphical corruption in bug 1169728. (The tutorial content that was missing in that bug was also video content.)

This is more reproducible, though.  I hit this 100% reliably following the steps in comment 0, including after rebooting my phone.
Video of bug in action: https://www.youtube.com/watch?v=CKH590l8hP4

The bug is triggered 7 seconds in. Link straight to that point:
https://www.youtube.com/watch?v=CKH590l8hP4#t=0m7s
See Also: → 1169728
Summary: Volume adjustments trigger a "ghost" permissions dialog with no content, after I've entered full-screen video → [Aries] Volume adjustments trigger a "ghost" permissions dialog with no content, after I've entered full-screen video
Note: Once I've been in full-screen video for a little while, I can't reproduce this anymore. But it seems to be easily reproducible for the first few seconds after I enter full-screen, at least.
Build ID: 20150604004619
nhirata says he can reproduce this on his Aries, too, FWIW.
Reproduced on this build:

Build ID               20150604143252
Gaia Revision          65369b217faac7d70c1a29100c4208c6d1db16e3
Gaia Date              2015-06-04 20:28:16
Gecko Revision         2b848889f879dd017906f0f41e8dc3e2f9f9a507
Gecko Version          41.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.naoki.20150603.173316
Firmware Date          Wed Jun  3 17:34:21 PDT 2015
Bootloader             s1

Note: going to landscape fixes the volume button during the session.

I could not reproduce this on mc flame or 2.2 flame from pvt builds.
Build ID               20150604010200
Gaia Revision          9e10483c5808f94f4a0a9f6afe30aae2c5b42b4c
Gaia Date              2015-06-03 19:22:33
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/98820360ab66
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150604.043446
Firmware Date          Thu Jun  4 04:34:57 EDT 2015
Bootloader             L1TC000118D0
[Blocking Requested - why for this release]:
blocking-b2g: --- → spark?
Whiteboard: [spark]
blocking-b2g: spark? → ---
Component: Gaia::Browser → Gaia::System::Window Mgmt
Sam, this looks like it may be related to bug 1169728 and bug 1171761. It would be greatly appreciated if you took a look into this, so that we have some idea of what's going wrong.

Gregor, any reason you dropped the 'spark?' nom? This seems to me like it could be a blocker.
blocking-b2g: --- → spark?
Flags: needinfo?(sfoster)
It looks bad but there is no functional impact for the user. We have plenty of functional regressions to fix.
That's a good point. We'll consider this during the triage, but on the surface, I agree with you.
I'll assign this to myself while I do some digging.
Assignee: nobody → sfoster
Flags: needinfo?(sfoster)
If we can't fix this problem, we can disable the tour for the Spark build. It would probably be easiest to piggyback on the "debug.performance_data.dogfooding" setting, which is "true" when dogfooding (effectively Spark) and "false" otherwise.
Milan, can you take a look at this one.
blocking-b2g: spark? → -
Flags: needinfo?(milan)
We think this is graphics?  Anyway, we don't have any Aries devices - if somebody can arrange some to be sent to Toronto, we can take a look.
Flags: needinfo?(milan)
We did just get this device.
(In reply to Doug Sherk (:drs) (use needinfo?) from comment #9)
> Sam, this looks like it may be related to bug 1169728 and bug 1171761.

(Second bug # there was a typo -- that's this bug here. Was there another bug you thought might be related?)

(In reply to Milan Sreckovic [:milan] from comment #15)
> We think this is graphics?

It seems like it may be graphics/layers-related -- specifically, video layers.  I've encountered this in 3 different contexts: (1) first-time usage screen (bug 1169728), (2) after accepting Camera app's first permissions prompt (noted in bug 1169728 comment 3), (3) this bug here.  In each case, there's a video that's being incorrectly stomped on by some stale/blank system dialog.  (I'm conceiving of the camera's live feed as being video-like.)
(So: it seems like this has to be either a bug in video-layers-ish code, or a bug in the system-prompt code. Given that this only reproducible on one device, it seems reasonable to initially suspect the code that's closer to the hardware.)
(In reply to Milan Sreckovic [:milan] from comment #15)
> We think this is graphics?  Anyway, we don't have any Aries devices - if
> somebody can arrange some to be sent to Toronto, we can take a look.

(In reply to Milan Sreckovic [:milan] from comment #16)
> We did just get this device.

Sotaro, could you take this as well?
Flags: needinfo?(sotaro.ikeda.g)
Okey, I take the bug.
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(sotaro.ikeda.g)
I started the Camera app and got the geolocation permissions dialog as expected. Poking around in the webIDE, I found that if you turn off the display property (so it is display:none) for the permissions-screen div:  

#permission-screen.visible {
    pointer-events: auto;
    display: inline-block; /* <-- toggle off the rule or set to none */
}

.. you'll see the dialog flash off then on again (but as an empty grey box). I hope that helps. Sotara, I'm handing this over to you as its clearly not a front-end window management issue, or even a content issue.
Assignee: sfoster → sotaro.ikeda.g
See Also: → 1171201
Flags: needinfo?(sotaro.ikeda.g)
I confirmed that this bug is dup of Bug 1171201. By applying attachment 8621274 [details] [diff] [review] in Bug 1171201, the problem was fixed on aries.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
I can't reproduce this in the latest Aries dogfood build (which I flashed last night).
Build ID               20150616235851
Gaia Revision          f36b1c0a4fad5d64c4c8e52ac2ac525632a8e673
Gaia Date              2015-06-16 21:53:30
Gecko Revision         3c3d7b9c02a81114bb27142eb1a4fc177709217b
Gecko Version          41.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150616.234403
Firmware Date          Tue Jun 16 23:44:13 UTC 2015
Bootloader             s1

Sotaro, does that make sense? (I see the dupe-target isn't marked as "fixed" yet.)
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Daniel Holbert [:dholbert] from comment #25)
> 
> Sotaro, does that make sense? (I see the dupe-target isn't marked as "fixed"
> yet.)

When I build almost everything from latest source code locally and flash everything, I still reproduce the problem.
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Daniel Holbert [:dholbert] from comment #25)
> I can't reproduce this in the latest Aries dogfood build (which I flashed
> last night).
> Build ID               20150616235851
> Gaia Revision          f36b1c0a4fad5d64c4c8e52ac2ac525632a8e673
> Gaia Date              2015-06-16 21:53:30
> Gecko Revision         3c3d7b9c02a81114bb27142eb1a4fc177709217b
> Gecko Version          41.0a1
> Device Name            aries
> Firmware(Release)      4.4.2
> Firmware(Incremental)  eng.worker.20150616.234403
> Firmware Date          Tue Jun 16 23:44:13 UTC 2015
> Bootloader             s1
> 
> Sotaro, does that make sense? (I see the dupe-target isn't marked as "fixed"
> yet.)

drs, dog food build already has fix for this bug locally?
Flags: needinfo?(drs)
We cherry-picked the patch in bug 1171201. The underlying issues still exists on public repos, so we should still land the fix.
Flags: needinfo?(drs)
You need to log in before you can comment on or make changes to this bug.