Closed
Bug 782008
Opened 12 years ago
Closed 4 years ago
Page body behind full screen HTML5 video is interactive with long press
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(firefox17 affected)
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
firefox17 | --- | affected |
People
(Reporter: mcomella, Unassigned)
References
Details
Attachments
(2 files)
(deleted),
patch
|
wesj
:
review-
|
Details | Diff | Splinter Review |
(deleted),
text/plain
|
Details |
1) Open Firefox
2) Go to http://carmendesign.com/code/video_for_everybody/test.html
3) Once the video is partially loaded, long press the video and select "Full screen" on the resulting context menu.
4) Long press the space around the video (it may be easier if you hold it in portrait mode).
Expected: Nothing happens (or the "Exit Full Screen" context menu appears)
Actual: Sometimes a context menu will pop up for various links and images on the page where this video came from.
Tested Galaxy Nexus, Android 4.0.4.
Reporter | ||
Comment 1•12 years ago
|
||
Sorry, bad link: http://camendesign.com/code/video_for_everybody/test.html
Updated•12 years ago
|
Assignee: nobody → margaret.leibovic
Comment 3•12 years ago
|
||
I logged rootElement in _sendToContent, and when I'm running into this bug, the problem is that rootElement isn't the video element. It seems like the real bug here is that we're not getting back the video element from elementFromPoint, but since that sounds tricky to investiagte, this patch is a simple fix to avoid showing a context menu when we're in full screen mode.
My one concern with this is that we'll need to change our approach if we ever want to show a context menu on full screen video, or if we add support for HTML5 context menus, since a webpage may want to add its own video context menu.
Attachment #653597 -
Flags: review?(wjohnston)
Comment 4•12 years ago
|
||
Wes, review ping?
Comment 5•12 years ago
|
||
Comment on attachment 653597 [details] [diff] [review]
quick fix
Review of attachment 653597 [details] [diff] [review]:
-----------------------------------------------------------------
I... don't like doing this. Lets try to get someone to figure out why DOMWindowUtils.elementFromPoint isn't working in fullscreen. Maybe even clone this bug and file something in layout.
Attachment #653597 -
Flags: review?(wjohnston) → review-
Updated•12 years ago
|
Assignee: margaret.leibovic → nobody
Comment 6•12 years ago
|
||
I agree with wesj here, this seems like us patching around a bug that we'll likely run into in other frontends too (metro, b2g, etc). I think we should either fix this in nsDOMWindowUtils, nsDocument::ElementFromPointHelper(), or in layout. Cc:ing cpearce and roc for further clarification as to where a fix would make most sense here.
Comment 7•12 years ago
|
||
This looks like bug 790850 but on fennec instead of b2g. Anthony Jones is currently looking at fixing this bug on B2G, the same fix would hopefully fix things on fennec too...
I don't think he's had time to look at it on B2G ... I suggest you take this bug and try to fix it first, perhaps fixing the B2G bug (though I'm doubtful this is the same bug as that).
The nsDisplayBackground of the fullscreen video element should be covering the entire screen and catching all events here, so elementFromPoint should always be returning the video element. It would be pretty easy to instrument a build to dump the display list built indirectly by elementFromPoint.
Assignee: nobody → cpearce
Wild stab in the dark --- Jonathan, could you look into this B2G bug? Someone who understands display lists and event handling would have a head start :-)
Assignee: cpearce → jwatt
Er, this is a Firefox for Android bug, not a B2G bug.
Comment 11•12 years ago
|
||
I've started looking at this, but between having to download a new Android SDK and long, dodgy builds I haven't got much further than reading the appropriate bits of code.
jwatt - if you haven't started looking at this yet I'll take it.
Comment 12•12 years ago
|
||
Feel free. I've only just this morning got past the build errors I was encountering and successfully got a fennec build.
Updated•12 years ago
|
Assignee: jwatt → ncameron
Comment 13•12 years ago
|
||
This is the display list dump from nsLayoutUtils::GetFrameForArea (called by nsDocument::ElementFromPoint). I'm not sure why there are 5 calls, but this is really only from the long touch, I couldn't narrow it down any further. I suppose we might call GetFrameForArea from other places and/or we could test at the beginning, end, and possibly middle of the touch. Nothing jumps out at me yet.
Comment 15•12 years ago
|
||
Handing off - I don't have much in the way of leads here, that display list used for hit detection looks fine to me, and the top element is getting picked as expected. I was going to start looking into the JS side of things:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1452
http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1490
http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#4171
But I suspect the problem is in C++ and I just can't see it.
Assignee: ncameron → nobody
Comment 16•4 years ago
|
||
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•