Closed
Bug 1171761
Opened 10 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)
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.
Reporter | ||
Comment 1•10 years ago
|
||
I'm using an Xperia Z3C (aries) device, w/ up-to-date Firefox 3.0 from dogfood channel.
Reporter | ||
Comment 2•10 years ago
|
||
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.
Reporter | ||
Comment 3•10 years ago
|
||
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
Reporter | ||
Updated•10 years ago
|
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
Reporter | ||
Comment 4•10 years ago
|
||
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.
Reporter | ||
Comment 5•10 years ago
|
||
Build ID: 20150604004619
Reporter | ||
Comment 6•10 years ago
|
||
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]
Updated•10 years ago
|
blocking-b2g: spark? → ---
Component: Gaia::Browser → Gaia::System::Window Mgmt
Comment 9•10 years ago
|
||
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)
Comment 10•10 years ago
|
||
It looks bad but there is no functional impact for the user. We have plenty of functional regressions to fix.
Comment 11•10 years ago
|
||
That's a good point. We'll consider this during the triage, but on the surface, I agree with you.
Comment 12•10 years ago
|
||
I'll assign this to myself while I do some digging.
Assignee: nobody → sfoster
Flags: needinfo?(sfoster)
Comment 13•10 years ago
|
||
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.
Comment 14•10 years ago
|
||
Milan, can you take a look at this one.
blocking-b2g: spark? → -
Flags: needinfo?(milan)
Updated•10 years ago
|
Blocks: Foxfood-papercuts
Comment 15•10 years ago
|
||
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)
Comment 16•10 years ago
|
||
We did just get this device.
Reporter | ||
Comment 17•10 years ago
|
||
(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.)
Reporter | ||
Comment 18•10 years ago
|
||
(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.)
Comment 19•10 years ago
|
||
(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)
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(sotaro.ikeda.g)
Comment 22•10 years ago
|
||
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
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Comment 23•9 years ago
|
||
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.
Assignee | ||
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 25•9 years ago
|
||
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)
Assignee | ||
Comment 26•9 years ago
|
||
(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)
Assignee | ||
Comment 27•9 years ago
|
||
(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)
Comment 28•9 years ago
|
||
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.
Description
•