1058700 - mozRequestFullScreen does nothing on mobile (FxAndroid and FxOS

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P5)

Description

[ashley]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36

Steps to reproduce:

Visit: http://www.scirra.com/demos/c2/sbperftest/

Touch the yellow triangular exclamation sign in the bottom left. This requests fullscreen on a div that wraps the game canvas.


Actual results:

On Firefox Nightly (34), it correctly enters fullscreen mode. On Chrome for Android 36 it also works.

On Firefox for Android beta (32), it does nothing. As far as I can tell neither the mozfullscreenerror or fullscreenerror events fire either. (Tested on a Nexus 5 running Android 4.4.4.)

This also reproduces on Firefox OS 1.3, tested on a ZTE Open C; however by repeatedly tapping the sign I could get it to eventually go in to fullscreen. But it should go in to fullscreen mode the first time it's pressed.


Expected results:

The mobile browser should support the fullscreen API in a compatible way to the desktop browser. For some reason the mobile version of Firefox is not entering fullscreen where the desktop version can.

If there is something about the environment that prevents fullscreen being allowed, then it should fire the fullscreen error event, which it does not appear to do.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

Using an older Android device (Motorola Razr running 4.0) the behavior is largely the same between versions when the game is running with lots of sprites moving about the button does not respond to tapping. Eventually the request fullscreen fires after a minute or so of tapping on it. This is the same across all channels of Firefox 31 - 34.

Comment 2

[Aaron Train [:aaronmt]]

Perhaps it's the URL test-case in question here?

Using: http://people.mozilla.org/~khuey/tests/fullscreen.html

On my Samsung Galaxy S5 (Android 4.4.4), Nightly (08/26) & Firefox Beta (32.0b10) that works fine for me.

On the example game demo, I see

E/GeckoConsole(32641): [JavaScript Warning: "Request for full-screen was denied because Element.mozRequestFullScreen() was not called from inside a short running user-generated event handler." {file: "http://www.scirra.com/demos/c2/sbperftest/c2runtime.js" line: 255}]

See: https://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html#security-and-privacy-considerations

Comment 3

[ashley]

Can you define "short running"? It definitely makes the call in a touchstart event. However by nature of being a large framework there is a fair amount of code it runs before that call is made. If it only runs once per input event then the JIT may elect not to optimise it, making it even slower. This could also explain why pressing it repeatedly eventually gets it to work. I don't think the availability of the feature should depend on the JIT optimisation status of the event handler code.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

mconley: is this a regression from bug 961362?

Comment 5

[Mike Conley (:mconley) (:⚙️)]

(In reply to Chris Pearce (:cpearce) from comment #4)
> mconley: is this a regression from bug 961362?

If the bustage is in FxOS 1.3 and / or Fennec Beta, then my patch (which is still only on Nightly), is not likely the cause.

I'm willing to bet that the JS isn't executing in time for us to return true from EventStateManager::IsHandlingUserInput[1], which is called from nsContentUtils::IsRequestFullscreenAllowed[2].

[1]: http://hg.mozilla.org/mozilla-central/file/4f6affdf52b6/dom/events/EventStateManager.cpp#l3565
[2]: http://hg.mozilla.org/mozilla-central/file/4f6affdf52b6/content/base/src/nsContentUtils.cpp#l6531

Comment 6

[Mike Conley (:mconley) (:⚙️)]

It looks like the timeout of 1 second is hardcoded into nsContentUtils: http://hg.mozilla.org/mozilla-central/file/4f6affdf52b6/content/base/src/nsContentUtils.cpp#l241. We could confirm this is the cause by giving ashley a Fennec build with that value boosted.

Comment 7

[ashley]

There is no way the handler takes 1 second. The demo is also a performance test that happens to measure jank, and it shows the maximum time between frames is usually well under 50ms. Not to mention the whole thing would visibly lock up if anything took that long. Are you sure the timer counts from the firing of a touchstart event?

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

Fullscreen doesn't work from touchstart events: bug 966493.

It does however work in today's Nightly in Fennec on my HTC One in onclick handlers.

So this is not a regression.

Comment 9

[ashley]

If fullscreen doesn't work from touchstart events, why does it work eventually on some devices?

If it's not allowed in touch events then that should definitely be fixed - frameworks like ours dispense of mouse events entirely by preventing default on all touch events, and use exclusively touch events for input, otherwise you run in to all sorts of difficult issues with double-firing events. It would seem to be an odd limitation to impose on a mobile browser if certain features only work through mouse events on a device without a mouse.

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

Smaug - Wes mentioned that we might need to add "user generated" to the touch events. Is that the case?

Comment 11

[Wesley Johnston (:wesj)]

Based on https://bugzilla.mozilla.org/show_bug.cgi?id=966493#c5 I think this is probably just a bug in our touchevents code. Looks like a simple fix.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Wesj, you have access to Android devices. Want to make touchstart/end user generated?

Comment 13

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]

Comment 14

[ashley]

Still reproduces on Firefox 33, did anyone take a look at this? We are still getting reports about it and apparently it's a "simple fix".

Comment 15

[Kevin Brosnan [Ex-Mozilla]]

WesJ comment 14?

Comment 16

[Wesley Johnston (:wesj)]

The fix for this landed in bug 966493. It should work in Aurora and Nightly builds now. Can you test there?

I nommed it for potential uplift to 34.

Comment 17

[ashley]

Oh, cool stuff if it's fixed. I'd test but Firefox beta on Android is v34, do I have to wait for uplift or v35 to verify or is there another way to test now?

Comment 18

[Kevin Brosnan [Ex-Mozilla]]

https://aurora.mozilla.org will have the code from 966493 we are still early in the release process so the chances of successful uplift of the fix into 34 are good