Closed Bug 1543439 Opened 2 years ago Closed 2 years ago

requestFullscreen denied from select onchange handler

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P2)

65 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla69
Tracking Status
firefox69 --- verified

People

(Reporter: graham, Assigned: edgar)

Details

Attachments

(4 files)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Attempting to go full screen from a pulldown like this:

<select onchange="document.body.requestFullscreen()">
<option value="none">Do nothing</option>
<option value="full">Full screen</option>
</select>

Actual results:

This message appears in the console:

Request for fullscreen was denied because Element.requestFullscreen() was not called from inside a short running user-generated event handler.

The browser does not go full screen.

Expected results:

The browser should have gone full screen. The request WAS "called from inside a short running user-generated event handler".

This works in Chromium (71.0.3578.98).

Putting requestFullscreen in the option's click handler is also denied with the same message.

Putting the request in a button's click handler works correctly.

This bug might help locate the part of the code to fix: https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=966493 . It refers to the same problem but with touch events.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

Johann, could this be related to the recent user interaction API blocking changes?

Flags: needinfo?(jhofmann)

Unlikely that this is related to our work. We did not change (and definitely not remove) places where user interaction is initiated. Maybe the onchange event is just separately dispatched and thus doesn't get the same user input stack? Smaug, can you take a look at this?

Considering that we want to use user interaction more extensively we should probably try to match Chrome's behavior here.

Graham, is this a regression (does it work in older release of Firefox, e.g. with https://mozilla.github.io/mozregression/)? Also, does this work if you try a handling a different event type on the select element?

Thanks!

Flags: needinfo?(jhofmann)
Flags: needinfo?(graham)
Flags: needinfo?(bugs)

is this a regression

I don't know, I don't have access to an older Firefox. I do know that it doesn't work in Edge 38 or Safari either.

does this work if you try a handling a different event type on the select element?

No. <select onclick="document.body.requestFullscreen()"> is also denied with the same message.

This smells like an issue with e10s select. I don't recall where we set the flag in that case that we're dealing with user input.

Flags: needinfo?(bugs) → needinfo?(mconley)
Priority: -- → P2

We allow open popup with e10s select, the popup state was pushed in https://searchfox.org/mozilla-central/rev/f4c39907e0b527dc4b9356a1eeb8c6e6c62d383a/dom/events/EventListenerManager.cpp#1149-1150.
Perhaps we need to handle IsHandlingUesrInput flag here as well?

We have a similar issue on the input date, like

<input type="date" onchange="document.body.requestFullscreen()">

Assignee: nobody → echen
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

PresShell::EventHandler::HandleEventWithCurrentEventInfo is the only possible
place will do such handling; other places pass either a nullptr or a
non-MouseDown/Up event.

Attachment #9066441 - Attachment description: Bug 1543439 - Part 1: Move is-user-interaction checks out of PresShell::EventHandler::PrepareToDispatchEvent; → Bug 1543439 - Part 2: Move is-user-interaction checks out of PresShell::EventHandler::PrepareToDispatchEvent;
Attachment #9066442 - Attachment description: Bug 1543439 - Part 2: change and click event fired from browser UI should be considered as an user interaction event; → Bug 1543439 - Part 3: change and click event fired from browser UI should be considered as an user interaction event;
Attachment #9067578 - Attachment description: Bug 1543439 - Add tests; → Bug 1543439 - Part 4: Add tests;
Component: DOM: Core & HTML → User events and focus handling
Pushed by echen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/750e3e013c4c
Part 1: Move special handling for MouseDown/Up event out of AutoHandlingUserInputStatePusher; r=masayuki
https://hg.mozilla.org/integration/autoland/rev/ffc50cffcf1e
Part 2: Move is-user-interaction checks out of PresShell::EventHandler::PrepareToDispatchEvent; r=masayuki
https://hg.mozilla.org/integration/autoland/rev/febbc0b025c5
Part 3: change and click event fired from browser UI should be considered as an user interaction event; r=masayuki
https://hg.mozilla.org/integration/autoland/rev/81792a8b6423
Part 4: Add tests; r=mconley

Fedora has Firefox 69 now, and I can confirm this is fixed. Thanks!

Flags: needinfo?(graham)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.