qqfile input requires double click on IE

[yairEO]

I have verified that the default behavior in IE10 for input (type=file) is double click on the input itself and single-click on the input's button, which opens up the browse window. This isn't desirable, because the qqfile hidden element is actually divided into left area and right area (where the button is), therefor clicking the right side once will open the browse (as I said before) and left right requires double click. This can be "fixed" in an ugly way, by giving the input a ridiculously high font-size value (1000px +) and width:100%, so the button will take almost all the input's width, and on the far left there will be an tiny area which required double click, but it's much better than now anyway.

Sorry I didn't have time to prepare a test page, but this is viewable (on IE10) (you can use compatibility mode as well) on our website :

http://gurushots.com/challenge/pulse/passionate-about-animals

(sorry that you must sign-up to see it, but signing up with Facebook is very quick)

I have worked very hard to integrate this fine fineuploader into our website and am very pleased with it so far.

My fix:

qq(input).css({
        position: "absolute",
        // in Opera only 'browse' button
        // is clickable and it is located at
        // the right side of the input
        right: 0,
        top: 0,
        fontFamily: "Arial",
        // 4 persons reported this, the max values that worked for them were 243, 236, 236, 118
        fontSize: "1000px",
        width:'100%',
        margin: 0,
        padding: 0,
        cursor: "pointer",
        opacity: 0
    });

[rnicholus]

Are you able to reproduce this issue on our demos page? For the most part, I'm not seeing the issue there. Is this specific to your site or your use of the styled file chooser button? I'm not able to sign into your site in a Windows VM today, but I'll take a look next week.

[yairEO]

your demos aren't big enough to show the problem. you need a container big enough that the default font-size you gave it won't be sufficient, thus the input field's button won't take all the space, like it should. I will try to prepare a demo page soon

[rnicholus]

I was able to reproduce this on your site by reverting the font-size on the opaque <input type="file"> to 118px. Very interesting. I don't think this has come up before. The only solution that I'm aware of would be to change the font-size to a very large value, as you suggested. If there aren't any regressions associated with that change, it's looking like that will be the fix for this, kludgey as it is.

[rnicholus]

@yairEO Will you be interested in giving a pre-release with a fix for this issue and #1152 a spin?

[rnicholus]

Caught an fixed an issue with IE8 caused by this fix. It turns out that setting the font-size to a value that is "too large" causes the file input to become visible in IE8.

[yairEO]

Better to set the font-size using feature-detection so the right value will go to the right browser

[rnicholus]

This issue seems to affect all versions of IE, so feature detection won’t be of any use.

On Wed, Sep 10, 2014 at 9:04 AM, vsync notifications@github.com wrote:

Better to set the font-size using feature-detection so the right value will go to the right browser

Reply to this email directly or view it on GitHub: https://github.com/Widen/fine-uploader/issues/1277#issuecomment-55119346

[yairEO]

I now see that that large font-size has a side effect in Chrome, where the hidden button doesn't get cursor:pointer so the pointer is actually the default. I think because the button itself is being bushed outside the area of "interest". This problem can be seen in large uploader areas like in my website. I can work around it by giving some parent of the hidden file input a cursor:pointer CSS value, but it's a very specific solution to the problem. doesn't work, the input file is above in the z-index obviously so it would be clickable...

[rnicholus]

It may be best to simply limit this arbitrarily large font-size to all versions of IE. This requires user agent string parsing, but that is acceptable to work around peculiarities such as this one.

[rnicholus]

Reading over your comment again, it's not clear what issue you are describing. The cursor in Chrome seems to render the same with or without a large font-size.

[yairEO]

not on my website (mentioned on the first post of this issue), the cursor in Chrome is normal default even though it's been set to pointer, that's because of the large font-size and the way Chrome defaults work (always worse than expected). I verified it. Chrome cannot show pointer cursor currently in certain setups like my own

[rnicholus]

Ok. We don't plan on rendering buttons of various sizes as part of our testing. So, the safest bet is to limit this "fix" to IE.

[yairEO]

But still, on Chrome (this is actually a new issue) the cursor cannot be pointer no matter what font-size is set to the file-input. the area is too large and quirks happen..so only a part actually gets the right cursor. I wonder if there's a way to simulate a click on input, without actually using it, since it's behavior is so unexpected cross-browser.

[rnicholus]

Programmatically clicking on a file input will cause IE9 and older to reject the eventual programmatic form submit used to upload each file. Other browsers have, at one time or another, prevented/ignored programmatic clicks on file inputs as well.

It's a moving target, and it's unlikely that these types of small quirks can (or should) be resolved.

[rnicholus]

Looks like the issue you discovered had nothing to do with font-size. It was caused by the addition of a width: 100% style to the underlying <input type="file">. I'll remove this as it is probably unnecessary.

[rnicholus]

Should be fixed in the 5.0.5-6 pre-release.

[rnicholus]

ugh, it just occurred to me that the width: 100% may be needed in IE to complement the large font-size.

[yairEO]

http://imgur.com/Q3cUg29

seems there is no escape from sniffing browsers

[rnicholus]

I just created a huge chooser button, and it seems to be clickable w/ one click in IE8+ without the width: 100% after all.

[rnicholus]

I will be reverting this change for IE8 due to a regression found in #1306. If you really want a large upload button in IE8, you'll need to fiddle with the font-size via your own CSS rules, based on the size of your upload button. You can target the opaque file input via a INPUT[name='qqfile'] CSS selector.

IE7 support for a large button is blocked by a (IE) bug that makes most of the visible button unclickable when the height of the opaque file input is set to 100%. If you plan on supporting IE8 and older, you should consider sticking with a normal-sized upload button for those browsers.