Closed Bug 411212 Opened 14 years ago Closed 14 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: pooyakspam, Assigned: smaug)

Details

(Keywords: helpwanted)

Attachments

(5 files)

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.
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/
Flags: blocking1.9?
Just for comparison, on Safari readOnly doesn't work but calling the preventDefault on the click event cancels showing the file picker.
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...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
Would it be bad to just call .stopPropagation() during capture phase in
chrome?
(In reply to comment #4)
>Do we really need to register this listener by IID?  
No.

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.
Attached file testcase
Attached patch possible patchSplinter Review
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.)
Assignee: nobody → Olli.Pettay
Status: NEW → ASSIGNED
Attachment #295950 - Flags: review?(roc)
Flags: blocking1.9? → blocking1.9+
Priority: -- → P5
Attachment #295950 - Flags: approval1.9?
Attached file 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?
(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.
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.
ok, I'll update the patch and if someone can then check whether if fixes the problem...
testing clickCount > 1 so that pressing 'enter' does still work.
Could someone test this on mac?
er, wrong patch
(In reply to comment #15)
> er, wrong patch
oops, no. it is just right. :)
Yeah, that seems to work.
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) ;)
Attachment #296193 - Flags: superreview?(bzbarsky)
Attachment #296193 - Flags: review?(bzbarsky)
Comment on attachment 296193 [details] [diff] [review]
possible patch to prevent double click handling

Looks good.
Attachment #296193 - Flags: superreview?(bzbarsky)
Attachment #296193 - Flags: superreview+
Attachment #296193 - Flags: review?(bzbarsky)
Attachment #296193 - Flags: review+
Attachment #295950 - Flags: approval1.9?
Attachment #296193 - Flags: approval1.9?
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.
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?
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.
Attachment #296193 - Flags: approval1.9? → approval1.9+
Attached patch with testSplinter Review
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.