411212 - privileged code cannot prevent file-picker from showing on <INPUT TYPE=FILE>

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect, P5)

Description

[Pooya Karimian]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008010704 Minefield/3.0b3pre

There is no way for an extension to prevent the file-picker from showing without disabling the input element. This is now needed after |bug 258875| landed which disabled direct input into file element. A click anywhere on the file input will now open the file picker (Firefox 3.0).

Reproducible: Always

Steps to Reproduce:
1. Create an HTML file element <input type="file">
2. Click anywhere in the field and the file picker will show up
3. There is no way for the privileged code to prevent file-picker from showing without disabling the element (see additional information)
4. Disabling the element disables capturing the events too



Two possible solutions to this problem:
1. Implementing the read-only attribute on file input as requested in |bug 7258|.
2. Not showing the file-picker when the click event on the input element is canceled.

Comment 1

[Pooya Karimian]

This fix is needed to make the image fill feature of Sxipper extension to work.

See:
https://www.sxipper.com/splash/1.2
https://www.sxipper.com/

Comment 2

[Pooya Karimian]

Just for comparison, on Safari readOnly doesn't work but calling the preventDefault on the click event cancels showing the file picker.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We could do both I guess.

Comment 4

[Boris Zbarsky [:bzbarsky]]

We could do the preventDefault thing, if we registered the listeners in the system event group (which is not what we do right now).  Sadly, there's no API to register the listener in that event group by IID.  Do we really need to register this listener by IID?  I guess that buys us the separate methods instead of just HandleEvent...

Comment 5

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

Would it be bad to just call .stopPropagation() during capture phase in
chrome?

Comment 6

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

(In reply to comment #4)
>Do we really need to register this listener by IID?  
No.

Comment 7

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

IE and Safari (but not Opera) seem to prevent opening file dialog if the default
handling is prevented (by returning false in onclick handler or calling
.preventDefault()).
Patch coming to make us work similarly.

Comment 8

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

Attachment: testcase

Comment 9

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

Attachment: possible patch

Roc, asking review from you because you fixed bug 258875.
Note, because the listener implements nsIDOMMouseListener, 
MouseClick will be called, not HandleEvent, when a real mouse event 'click' is
dispatched.
(That is how the event listeners have worked for a long time and when
 cleaning up ELM I didn't change the behavior.)

Comment 10

[Pooya Karimian]

Attachment: test case 2

Great. thanks for the patch. I think there is something wrong with handling double click in the file input too (not to be mistaken with |bug 212489|). It shows two file pickers and that can be blocked with a click handler but not a dbl click handler.

Added a new test case including dblclick. Does it need a new bug filed or is it fine?

Comment 11

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

(In reply to comment #10)
> shows two file pickers and that can be blocked with a click handler but not a
> dbl click handler.
On which platform do you see 2 file pickers? Can't reproduce that on linux/fedora7 nor on WindowsXP.
Anyway, different bug.

Comment 12

[Boris Zbarsky [:bzbarsky]]

I see two file pickers on Mac, for what it's worth.  MouseClick is firing twice when I double-click.  The first time, detail is 1, the second time it's 2.  We should probably just bail out if detail is not 1.

Comment 13

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

ok, I'll update the patch and if someone can then check whether if fixes the problem...

Comment 14

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

Attachment: possible patch to prevent double click handling

testing clickCount > 1 so that pressing 'enter' does still work.
Could someone test this on mac?

Comment 15

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

er, wrong patch

Comment 16

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

(In reply to comment #15)
> er, wrong patch
oops, no. it is just right. :)

Comment 17

[Boris Zbarsky [:bzbarsky]]

Yeah, that seems to work.

Comment 18

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

Comment on attachment 296193 [details] [diff] [review]
possible patch to prevent double click handling

Feel free to review the clickCount part (the last few lines in the patch) ;)

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 296193 [details] [diff] [review]
possible patch to prevent double click handling

Looks good.

Comment 20

[Pooya Karimian - Sxip (:pooya)]

Works on mac as you described. But is there anyway to not have the click events on a double click? For example now it is not possible to let the file picker show on click but prevent it on double clicks.

Comment 21

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

Well, double click doesn't seem to work on other platforms anyway, so 
to make things consistent is, IMO, good thing here. And also to keep things
simple, handling only single click is better.

How do the other browsers (Safari/Opera) work on mac in this case?
Do they do something special when double clicking?

Comment 22

[Pooya Karimian - Sxip (:pooya)]

Same on Safari. I guess this is in general a problem with double click on other elements as well. We always get a single click first. I have to think of another way to solve it on my side. Thanks.

Comment 23

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

Attachment: with test