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

Categories

(Core :: DOM: Events, defect)

44 Branch
x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- fixed

People

(Reporter: m.stollner, Assigned: Gijs)

References

(Regression)

Details

(Keywords: regression, testcase, Whiteboard: btpp-followup-2016-03-18)

Attachments

(1 file)

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
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
(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.
Flags: needinfo?(kohei.yoshino)
I haven't confirmed the issue myself yet, so that the status is UNCONFIRMED.
Flags: needinfo?(kohei.yoshino)
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
Keywords: testcase
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?
Flags: needinfo?(bugs)
Whiteboard: btpp-followup-2016-03-18

Has this been fixed yet.
I'm still experiencing the same problem. I would like users to get notified when they accidentally close tab or window after dropping a file into the upload element.

Firefox should register the file drop as interaction with the page. Other browsers don't seem to have a problem with this.

I've become better at debugging gecko and understanding how we deal with events, so I could now fairly quickly figure out that the code in nsFileControlFrame adds system dragover and drop listeners, and calls stopPropagation as well as preventDefault from the drop handling code. The drop gets fired, but we don't explicitly listen for drag type events in the EventStateManager code that got added in bug 636905 - thinking that the base keyboard/mouse/pointer/touch events would suffice. Unfortunately, calling preventDefault on a drop event prevents dispatching a mouseup event.

The simplest fix is probably to add drop events to the list in EventStateManager explicitly.

Flags: needinfo?(bugs)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/63b8d34e13af
take drop events as indication of user activity, r=smaug
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
QA Whiteboard: [qa-71b-p2]
You need to log in before you can comment on or make changes to this bug.