Closed Bug 1255318 Opened 4 years ago Closed 6 months ago
Drag&Drop image/file to input type="file" is not registered as a browser interaction; onbeforeunload event is not fired, when user leaves the page
47 bytes, text/x-phabricator-request
|Details | Review|
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20160210153822 Steps to reproduce: 1) Open new Browser window (data entry dialog). 2) Drag&Drop an image to an upload control (e. g. Kendo UI upload). 3) Close browser window via "X". Actual results: 4) The onbeforeunload event is not fired, the confirm box is not shown. Expected results: The onbeforeunload event has to be fired, the confirm box must be shown. Otherwise this can cause data loss, in a weg page where the user have to save data via save button
(In reply to Kohei Yoshino [:kohei] from comment #1) > This might be a regression from Bug 636905. > > https://www.fxsitecompat.com/en-CA/docs/2015/beforeunload-confirmation- > dialog-will-no-longer-be-displayed-unless-user-has-interacted-with-the-page/ Might? Is there a testcase to reproduce with and/or did you actually look for a regression window? The code from bug 636905 should trigger the 'has interacted with' state when a mouseup event happens, which sounds like it should be the case here, when the drop occurs.
I haven't confirmed the issue myself yet, so that the status is UNCONFIRMED.
http://output.jsbin.com/pojisixomi Dragging a file to the file input doesn't seem to trigger this, nor does dragging text into the input control. Not sure why yet.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Drag&Drop image/file to an upload control is not registered as a browser interaction; onbeforeunload event is not fired, when user leaves the page → Drag&Drop image/file to input type="file" is not registered as a browser interaction; onbeforeunload event is not fired, when user leaves the page
Olli, I've been trying to look at this, but it seems we never see an eMouseUp event in the EventStateManager - or in nsView::HandleEvent ... what's killing off this event, and should we just be listening for drop events as well or something?
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/63b8d34e13af take drop events as indication of user activity, r=smaug
You need to log in before you can comment on or make changes to this bug.