User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

1. Open a page with a file input form field (e.g. bug report attachment page on Bugzilla)
2. Drag a file from Windows Explorer and drop it onto the file input field

Actual results:

Firefox navigates to and tries to open the file.

Expected results:

The file input field should select the dropped file and Firefox should not attempt to navigate to the file.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Copy & Paste and Drag & Drop' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Bisection shows last good 8b23c085842706e86b165195141f926b4355450a, first bad b909a9f6f1eabe9c717cce6e5ee6f080b308a551.
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3c032ac87c31d76f60817bf618aeeb69a73f9835&tochange=b909a9f6f1eabe9c717cce6e5ee6f080b308a551

Alternative test page: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file

:sefeng, since you are the author of the regressor, bug 1817723, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Hmm, I can't reproduce this. I used the STR by dragging an HTML file to the bugzilla attachment page, and the file uploaded. This is build 20230808215502.

Can you try this again with a clean profile?

I tested with mozregession GUI which uses clean profiles. It is still reproducible on https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file.

(When I said Bugzilla I was actually referring to the KDE bugzilla instance which does not have the fancy JavaScript upload handling used on this instance, but a plain <input type="file"> field.)

I can reproduce this on Nightly118.0a1(20230809092330) Windows10 with clean profile.

STR:

1. Open data:text/html,<input type="file"/>
2. Drag&Drop a file(html,png etc) onto Browse... No file selected. from File Explorer.

Actual results:
The file is opened in the tab

Expected results:
File name should appear in the input field. It should not open in the tab.

[Tracking Requested - why for this release]: This seems like quite common/basic functionality.

Thanks, I can reproduce it now, looking

https://hg.mozilla.org/mozilla-central/rev/4e2628cace80

I confirm this is fixed with autoland build 20230810143626. Please uplift to 117.

The patch landed in nightly and beta is affected.
:sefeng, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox117 to wontfix.

For more information, please visit BugBot documentation.

Comment on attachment 9348249 [details]
Bug 1847363 - Add the missing UpdateDefaultPreventedOnContent call for nsFileControlFrame r=masayuki

Beta/Release Uplift Approval Request

• User impact if declined: Users can't drag file to <input type="file>
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1.Open data:text/html,<input type="file"/>
  2.Drag&Drop a file(html,png etc) onto Browse... No file selected. from File Explorer

The url bar shouldn't change. No page navigation occurs.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change itself is trivial.
• String changes made/needed:
• Is Android affected?: Unknown

Comment on attachment 9348249 [details]
Bug 1847363 - Add the missing UpdateDefaultPreventedOnContent call for nsFileControlFrame r=masayuki

Approved for 117.0b7

I have reproduced this issue on Nightly 118.0a1 (20230809213044) and verified the fix on MacOS 11 and Windows 10 using
Nightly 118.0a1 (20230813213352) and Beta 117.0b7 (20230813180142).