HTML5 input type=file has issues with triggered click. #605

stevemayhew opened this Issue Aug 9, 2012 · 6 comments

3 participants


The crux of this issue is you cannot have the HTML5 upload button in a jQuery dialog, even if you make it contained by body (common offsetParent) and call plupload.refresh() to position it invisible 'overlaying' the dialog button.

Here is a fiddle that shows the issue, it works on Gecko (FF), but not on Safari 5.1 or Chrome 12 (WebKit).


Here is a fix, stevemayhew@29126ae

Maybe not the best (as it does require you to call plupload.refresh() when the dialog opens to position the button. Note this (refresh()) is required anyway for FlashPlayer as it will not script or position until it is in a visible container.


Ah, of course the issue is obvious when you think about it. The WebKit folks do not want you to accidentally click on a input type=file (as now with HTML5 DataTransfer these present security challenges). As such if WebKit is convinced the actual element is un-clickable, it does not allow the direct trigger of click() either.

A simple fix is to either:
1. Make the dialog non-modal (not the best option)
2. Move the 'hidden' button up above the glasspane (demostrated by this fiddle:

A fix pull request will be forthcoming... Stay tuned.

Moxiecode member

As soon as I've set some positive z-index-es it started to work. Maybe we should get rid of that negative logic.


hi guys,

I'm facing the exact same thing: trying to put the upload queue widget in a jquery UI modal dialog.

It seems that there are three issues here:

1- for some browsers, is not triggered (one of them due to web security concerns, like @stevemayhew has highlighted).
The workaround is simply to put the input=file element right underneath the browseButton.
plupload already has code to do this, except for one small problem.
This brings us to the next issue: (position of input=file)

2 - The [input=file]'s position (or rather, its parent form's) is at (0,0) because the browse button position is undefined when plupload first initialized. So when the user press "Add files", is not fired and there is no input=file underneath it as a workaround.
This is easily resolved by calling refresh() on the modal dialog "open" event.

3 - The third issue is with the input=file z-index being lower than the modal overlay.
Because of that, regardless whether input=file is triggered through onClick event or through a physical mouse-click,
the browse dialog will not show up.

Upon creation of the input=file element, the code puts it one index lower than the browseButton.
The issue here is that browseButton has a z-index of 0 (rather, its not defined).
This puts the input=file elem at z-index '-1';

The fix is simply to set the input=file elem at something higher than the modal dialog.
The implementation is entirely up to you, there are more than one way to do this.

  • hard code the z-index for input=file elements created by plupload
  • use jquery to set it
  • use a non-modal dialog
  • etc

I've chosen to fork all of this and allow plupload to accept an optional parameter "browse_button_z_index",
to which the caller decides an acceptable value for the browsebutton (and indirectly, input=file).
(+1 in plupload.js, +7 in plupload.html4.js, +7 in plupload.html5.js)



Sigh. Please ignore my last commits till I get the line ending issues sorted out, git seems to insist on changing the un*x default /n line endings making my simple diff look huge.

@stevemayhew stevemayhew added a commit to stevemayhew/plupload that referenced this issue Aug 20, 2012
@stevemayhew stevemayhew Fix for HTML5 input z-index (issue #605)
To work properly in qTip's and jQuery modal dialogs in WebKit browsers
the input container must be 1 z-index below the button but not below
any other prior elements (like another qTip or a modal dialog's model
glasspane (the ui-widget-overlay).

This issue (#605) was caused because the existing code does not
consider the "current stacking context" when attempting to determine
the z-index of the browse button.

Here is a jsFiddle
( that fixes
the bug. With this verison of plupload and the snipit from the HTML5
change.  And lastly, here is the jsFiddle that demonstrates the bug:
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment