|Sending a "click" event to a form button|
Follow-up to Need to "Open Dialog" but don't know how
| 1:06 am on Jan 29, 2008 (gmt 0)|
Hello All -
That was depressing.
However, continued musings over this challenge gave rise to the possibility that "perhaps" one could write a script that would enable one button to control another button. If this is a possibility, then I've got my solution.
So, the theoretical scenario would be:
1. You've got an <input type=file> element that's been hidden via CSS (display: none).
1a. The id of the file input is set to "fileUpload" (input type="file" id="fileUpload")
2. You've got a visible button within the same form that, when clicked, sends a "click" event to input id "fileUpload".
3. When the file input (id="fileUpload") receives the event, the usual functionality of the file input is triggered (even though this input is hidden) ... e.g. an open dialog appears where the user may select a document to upload.
So... do those of you here in this forum think this ***could*** work? And, if so, could someone guide me on how to write such a script?
Interested in all possibilities, and great appreciation to all in advance!
| 3:14 pm on Jan 30, 2008 (gmt 0)|
it's worth a try... I'll put it into code and see if it works (perhaps this afternoon, if I get some play time).
Or if someone else beats me to it, please post the results here. This is a technique I'd be keen to know.
| 6:06 pm on Jan 30, 2008 (gmt 0)|
works in IE7, but not in FF. go figure.
<input type="file" id="receiver" />
<input type="button" onclick="$('receiver').click();" value="sender" />
| 6:15 pm on Jan 30, 2008 (gmt 0)|
according to microsoft [technet.microsoft.com], the click() method applies to <input type=file>.
Mozilla and Opera haven't added this method to file upload fields. Mozilla has a bug ticket [bugzilla.mozilla.org] open for it with comments going back 7 years
| 12:09 am on Jan 31, 2008 (gmt 0)|
When I first read this I was thinking it is likely not an option. Security issue. Modern browsers are still broken when it comes to this. Perhaps that is why there are issues?
Note: I'm not stating that it is or is not a security issue, just that perhaps that is why Fx has not fixed the bug report and also why there is so much difficulty cross-browser. onfocus() is the issue as laid out in the referenced thread.
| 1:12 am on Jan 31, 2008 (gmt 0)|
Thank you SO MUCH for giving this a shot! I am sort of disappointed that it won't work cross-browser but atleast you proved that the theory does work.
I did find another way of doing this by laying a regular button atop the file input (via css positioning) and then changing the opacity of the file input to zero, but I don't really like that option.
Anyway, I really, really appreciate your efforts!
Thanks also to Coopster for weighing in!
| 2:09 am on Jan 31, 2008 (gmt 0)|
oh- are you trying to STYLE a file browse button?! That's a major pain in the glute for everyone, though there are some wacky CSS tricks to do it, as you discovered.
I thought you were going to try triggering a browse dialog via some other process, like an AJAX or a mouseover
What is the security risk with triggering the Browse dialog? Is there a scenario in which that would compromise someone's privacy?
I thought the security danger scenario was allowing JS to populate the field. For instance if I can populate that box with "C:\WINDOWS\SYSTEM32\DRIVERS\etc\HOSTS", then submit()... that would upload the file, wouldn't it? invisibly?
| 3:25 am on Jan 31, 2008 (gmt 0)|
Hi Coopster -
|I thought you were going to try triggering a browse dialog via some other process, like an AJAX or a mouseover |
Yes, this was the purpose of the exercise: since it's so difficult to "style" a <input/file> button I'm just trying to "control" it's functionality by other means as per my client's request. He doesn't want to see the input text field (that shows the chosen file path) at all... he just wants a button which, when clicked, would trigger the Browse dialog.
|What is the security risk with triggering the Browse dialog? Is there a scenario in which that would compromise someone's privacy? |
Regarding security risk, I can't answer this question - no doubt, someone else probably could. However, I don't see that doing the same thing that the <input/file> element already does (albiet in a different way), could cause a security concern... but I really don't know.
|I thought the security danger scenario was allowing JS to populate the field. For instance if I can populate that box with "C:\WINDOWS\SYSTEM32\DRIVERS\etc\HOSTS", then submit()... that would upload the file, wouldn't it? invisibly? |
Yes, I've read a lot about this - auto-populating the value of the "path text input" - and due to that possibility, I CAN see where that would be a concern.
But, if JS is just opening a Browse dialog and capturing the TRUE path name of the file selected - which would then be sent to the $_FILES array in PHP - then I don't see that this would be a concern either UNLESS someone wold be able to somehow tweak the JS in order to feed their own path name (as you suggest) instead of the actual one from the chosen document.
This seems to be the reason why you cannot pre-populate the value of the <input/file> element which is another reason why that (I think) it would be really terrific to just hide the input/file element via CSS while still be able USE it via another button... in all major browsers.
But, alas, this seems like a (currently) impossible dream - until atleast FF and Opera change their handling of certain JS functions/features/calls.
Thanks for you comments!