Trigger file upload click event from javascript

[panore]

hello Friends

I have to trigger a click event of file upload control from
javascript.

The file upload click events works nice in IE (from javascript) but
creates problem in Firefox.

So friends is there any way to do it ?

Pls help.

Regards
sunil Panore

 

[Sean Kinsey]

hello Friends

I have to trigger a click event of file upload control from
javascript.

The file upload click events works nice in IE (from javascript) but
creates problem  in Firefox.

So friends is there any way to do it ?

Pls help.

As far as I know its not possible.
Most libraries that display a custom button for selecting files
actually places the input field (which have a builtin click listener)
on top of the button and sets its opacity to 0.

 

[Evertjan.]

panore wrote on 20 apr 2010 in comp.lang.javascript:

hello Friends

I have to trigger a click event of file upload control from
javascript.

You are never required to do the impossible.

It would be a very bad thing if it were,
since it would be a security breach,
as you could upload files from my pc without my authorisation.

So better not be trigger-happy.

 

[Sean Kinsey]

panore wrote on 20 apr 2010 in comp.lang.javascript:



You are never required to do the impossible.

It would be a very bad thing if it were,
since it would be a security breach,
as you could upload files from my pc without my authorisation.

That is not correct as there are other precautions in place for this.
As an example, I believe you cannot set the value property of a file
input, and in newer browsers you cannot read the _real_ path after it
is set either.

 

[Jorge]

It would be a very bad thing if it were,
since it would be a security breach,
as you could upload files from my pc without my authorisation.

No, you'd just be presented with a dialog box to select a file, istm.

 

[VK]

Out of modern non-mobile UAs that currently worth commercial
attention, from top to bottom:

inputFile.click() supported:

yes Internet Explorer
no Mozilla Firefox
yes Apple Safari
yes Google Chrome
no Opera

With Opera's importance for commercial projects being more theoretical
than practical (yet still presented), the real stopping obstacle are
Gecko clones. Either click() or artificial events over createEvent are
equally ignored, as years ago. I see little sense in it by now, after
the styling workaround trick from QuirksMode became a de facto
standard development tool ( http://www.quirksmode.org/dom/inputfile.html
)

If Mozilla & Opera are really concerned about security, they should
lock CSS opacity changing for input[file] - and a longest time ago.
Right now i) either user is proposed to click something that doesn't
resemble input[file] at all with any proprietary label on it or ii)
gets FileChooser window without clicking - I don't see how the 2nd
would be more potentially harmful than the 1st.

Looks like another "our principle to stay on" syndrome that Mozilla
periodically gets

 

[David Mark]

On Apr 20, 8:06 pm, Jorge <[email protected]> wrote:

I take it that you, in fact, wrote the following and are quoting Jorge
as saying nothing. Is that right?

Out of modern non-mobile UAs that currently worth commercial
attention, from top to bottom:

I see you are still crazier than a shit-house rat. Mobile UA's are
still off your radar screen?!

inputFile.click() supported:

yes Internet Explorer
no Mozilla Firefox
yes Apple Safari
yes Google Chrome
no Opera

That's like a graph with no units.

With Opera's importance for commercial projects being more theoretical
than practical (yet still presented), the real stopping obstacle are
Gecko clones.

As usual, you have no idea what you are talking about. Do you support
Europe at all? Or is that a continent you don't care about?

Either click() or artificial events over createEvent are
equally ignored, as years ago. I see little sense in it by now, after
the styling workaround trick from QuirksMode became a de facto
standard development tool ( http://www.quirksmode.org/dom/inputfile.html
)

Pfft. Perhaps an el stupido standard.

If Mozilla & Opera are really concerned about security, they should
lock CSS opacity changing for input[file] - and a longest time ago.

That was almost lucid.

Right now i) either user is proposed to click something that doesn't
resemble input[file] at all with any proprietary label on it or ii)
gets FileChooser window without clicking - I don't see how the 2nd
would be more potentially harmful than the 1st.

Looks like another "our principle to stay on" syndrome that Mozilla
periodically gets

Ah, the world is back as it should be.

 

[VK]

I take it that you, in fact, wrote the following and are quoting Jorge
as saying nothing.  Is that right?

Just posting at the end of the thread w/o addressing anyone
personally. One line of Jorge's just escaped the deletion.

I see you are still crazier than a shit-house rat.

Wow... Life troubles? Depression? No one neither loves not understands
you?
http://www.hexmed.com/order-prozac-online.htm

Mobile UA's are
still off your radar screen?!

Surely they are - in the another department. Why?

That's like a graph with no units.

Does "modern" need to be explained? OK: IE 8.0 or higher, Fx 3.6 or
higher, Safari 4.0 or higher, Chrome 4.0 or higher, Opera 10.0 or
higher. Anything below is a separate solution on customer demand.
Non-commercial amateurs are definitely welcome to cover anything at
once, including Amaya, NN3-4, NN6, Safari 2.x, YetAnotherBestBrowser
0.2 beta and the like. There is nothing wrong in that: it brings some
pleasurable fun to otherwise boring practical discussions.

As usual, you have no idea what you are talking about.  Do you support
Europe at all?  Or is that a continent you don't care about?

Definitely I do care. This is why Opera despite being "blinking red"
is still in the list: with the US share below the crucial 1%, it still
holds 2%-3% in Europe.

<snip>

 

[David Mark]

Just posting at the end of the thread w/o addressing anyone
personally. One line of Jorge's just escaped the deletion.

It's a little late in the game to learn to post.

Wow... Life troubles? Depression? No one neither loves not understands
you?
http://www.hexmed.com/order-prozac-online.htm

Is that your regular supplier?

Surely they are - in the another department. Why?



Does "modern" need to be explained? OK: IE 8.0 or higher, Fx 3.6 or
higher, Safari 4.0 or higher, Chrome 4.0 or higher, Opera 10.0 or
higher.

That's a very odd definition of "modern". IE8 or higher? You do
realize that IE8 can be made to work almost exactly like IE7, which is
not too far removed from IE6. And Chrome 3, Safari 3, Opera 9, etc. are
antiquated in your book? This sounds like the typical excuse of an
incapable developer (see projects like jQuery, Dojo, YUI etc.) They
don't "care" about last year's browsers because it would shatter their
egos if they admitted the real problem (their own incompetence). Guess
what? The end-users don't talk to the developers, nor can they be
relied upon to upgrade browsers every time careless developers
"deprecate" them. So try dealing with reality as it is all that matters
to the users (your delusions are your own).

Anything below is a separate solution on customer demand.

I feel sorry for your customers.

Non-commercial amateurs are definitely welcome to cover anything at
once, including Amaya, NN3-4, NN6, Safari 2.x, YetAnotherBestBrowser
0.2 beta and the like. There is nothing wrong in that: it brings some
pleasurable fun to otherwise boring practical discussions.

Yes, it is always the competent developers who are being amateurish.
What the hell is wrong with competence (other than the fact that it has
eluded you for all these years?)

Definitely I do care. This is why Opera despite being "blinking red"
is still in the list: with the US share below the crucial 1%, it still
holds 2%-3% in Europe.

How many Web browsers are therer in the US? What's 1% of that? Does it
make good business sense to exclude that many people (in this country
alone) due to VK's incompetence? Furthermore, how many corporate IE6/7
users do you figure for the US? They are unworthy of using VK's
"solutions" as well? Then there are those pesky "Gecko clones". Why
not just learn cross-browser scripting (finally) and stop trying to keep
track of who is using what browser.

 

[Thomas 'PointedEars' Lahn]

If Mozilla & Opera are really concerned about security, they should
lock CSS opacity changing for input[file] - and a longest time ago.

That was almost lucid.

Almost. Opacity would not make much of a difference without locking
`visibility' for those controls in all CSS-capable browsers as well. And
I don't subscribe at all to the opinion that such controls should not be
subject to styling, or as we are here, to animation (standards-compliant
blend-in/-out effects come to mind). And it's not a security issue at all
as the `value' attribute or property of the control cannot be set.


PointedEars