we have an issue where a disabled form element (input, textarea, ...) does not react to a right-click action (oncontextmenu attribute). Everything works fine when the form element is enabled. Please consider the following pseudo-code:
<div id="test" oncontextmenu="someFunction()">
<input id="textbox" type="text" disabled="disabled">
SOME_PADDING
<input id="calendar" type="image" disabled="disabled">
</div>
The real catch is it does not work in Chrome and Firefox, but it does work in IE8 and Opera.
When we right-click on the textbox or calendar elements in Chrome or Firefox, nothing happens. If we click in between the elements (SOME_PADDING) then the right-click menu does appear.
Hence it seems as if a right-click action on a disabled form does not work in Chrome and Firefox. Has anyone experienced a similar behaviour before?
Thanks in advance!
Stijn
EDIT: As mentioned by Pekka, a disabled form element not reacting to a right-click does make sense. The real issue seems to be the oncontextmenu attribute of the div around it not reacting properly when clicking on a disabled form element in Firefox / Chrome.
EDIT2: Online example can be found here: http://jsbin.com/isite4/6 - This works in all but IE8. Any proposed work-arounds to force IE to behave normally?
Hmmmm, interesting. Never seen this before. It could be argued that it is not entirely wrong to hide the context menu, though. The W3C has the following to say about disabled controls:
Disabled controls do not receive focus.
Disabled controls are skipped in tabbing navigation.
Disabled controls cannot be successful.
and about receiving focus:
In an HTML document, an element must receive focus from the user in order to become active and perform its tasks.
So the behaviour shown by Chrome and FF kind of makes sense IMO.
Ideas for how to work around it:
Put a transparent element on top of the input element, and catch the event there (yuck)
Use z-index: -1 to put the disabled element behind the container - not sure whether this works across browsers though
Do not work with the disabled attribute, but use CSS styling and a jQuery workaround to prevent those controls' values from being submitted
The latter would be the best suggestion, I think.
We opted for a work-around, as their doesn't seem to be a straight-forward approach.
We decided to add an image over the disabled form element, that responds to a normal left-click.
There is a simpler way that I have used and that was to readonly the element instead of disabling it. If the 'look' might confuse your users, just match the "disabled" colours with css on the element. I know it is not relevant to the original poster but anyone else who comes looking might benefit.
Related
This really has me scratching my head.
The OPTION text is cleared using this code in a Snippet:
document.querySelector('option').textContent = '';
<select>
<option>Ipso</option>
</select>
It also works in a CodePen, plus it works on my website.
However, in JSFiddle it fails – but only in Chrome.
If I set textContent to anything prior to clearing it, it then works.
This issue doesn't seem to occur with any other type of element.
If I use innerText or innerHTML instead of textContent, I get the same behavior – but again, only in Chrome. jQuery's text() method also gives the same behavior.
Is this a Chrome bug or a JSFiddle bug?
I don't know the reason for the bug, but try setting the load type (click the cog in the top right corner of the JavaScript frame) and select no wrap - in <body>.
It works on the Chrome browser on my phone (whilst your fiddle didn't), and could possibly explain what's gone wrong.
I'm having trouble with HTML5 validation on <select> element styled with Uniform.js. With unstyled <select>, in Chrome for example, I would get small popup saying "Please select and item in the list" if I try to submit the form without selecting something first. Unfortunately, when Uniform is applied this popup is gone and I get no validation message.
How we could fix this issue? Thanks.
JSFiddle with one unstyled and one styled <select> element for testing can be found here: http://jsfiddle.net/Klikerko/hqUr8/
EDIT: After more testing it turns out that validation message doesn't show in Chrome on Mac (version 25). This issue might be fixed in newer Chrome, but I have to use this older version because of some problems with CodeKit and latest Chrome.
How can I trigger a select file dialog on iOS 6 for an input element in the DOM programatically? (i.e. using Javascript)
<input type="file" id="foo">
Notes:
Mobile Safari and Safari seems to behave differently. I've got it working using document.querySelector("input[type=file]").click() in safari.
If it's within a native clickhandler, i.e. initiated by the user, it seems to work, but I'd like to trigger the dialog on will.
After some more research it seems like this isn't possible. Least I haven't found a method that works.
I decided to solve this using an <input type='file'> positioned on top of the button, with opacity 0.01 to make the button visible.
I've build a form with Zend Form, and would like the focus to be on a text area inside the form on page load. I tried with JS, sometimes it shows the focus for half a second, but it removes the focus before one can actually type anything.
I thought Zend Form may prevents the focus, so i looked it up, and found the autofocus attrib-option, but that won't help either.
Any idea what the matter may be?
Thanks
autofocus seems to work fine, however it is not supported in IE. So you're likely stuck with javascript for now.
I tested autofocus in firefox and IE using:
$element->setAttrib('autofocus', 'autofucus');
it work well in firefox with 2 doctypes. HTML5 and XHTML1.0
I haven't tried it in this context but putting the HTML5 shim in your header seems to make IE behave much better.
<!--[if IE]><script type="text/javascript" src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
If you have used dojo getFocusOnLoad() might help to set the focus when the a page loads..
Please follow these links:
http://framework.zend.com/manual/en/zend.dojo.form.html
http://framework.zend.com/manual/en/zend.view.helpers.html
This is basically and simplified what I have now:
<style>
form.noshow { height: 0; overflow: hidden; }
</style>
<form class=noshow target="SomeIframeThatExists">
<input type=file id=uf>
</form>
<a id=uflink href="/user/photo">Upload photo</a>
<script>
$('uf').addEvent('change', function(e) {
// alert('oele'); // this would work fine
this.form.submit(); // auch in IE > "Access denied" exception
});
$('uflink').addEvent('click', function(e) {
$('uf').click(); // opens file dialog in all browsers inc IE
return false;
});
</script>
What it does (perfectly) in Chrome 11 and FF 4:
The form is hidden.
You click the link
Choose file dialog opens
You select a file
Dialog closes
Form is submitted
Script in iframe is executed and photo is replaced
Very hightechlike and sweet.
In IE, all of that works, except [6]. The form isn't submitted. Javascript error: "Access denied". Doesn't matter how the form is invisible, as long as the dialog was opened with input.click() the form can't be submitted on change. (The onchange function is executed fine. The error only occurs when form.submit() is called.)
Now all of this I can accept. IE sucks. I live with it.
My solution so far was to check the navigator for "MSIE" and then when clicking the link instead of opening the dialog, showing the form (with the file input). Then the user has to click the actual, ugly file input and then everything works fine. But ugly.
The question is twofold:
Is there a way to do this in IE as cool as it is in Chrome? WITHOUT nasty flash/java crap. Only html elements andjavascript.
If not: is there a way to check for form.submit() support after opening the dialog from a link (besides !navigator.contains("MSIE"))?
[2] could be catching the "Access denied" exception thrown in IE, but then it's too late: the user has already opened the dialog and browsed to the photo. You don't wanna make him do that again. (Even IE users don't deserve that.)
PS. I'm only interested in Chrome 10+, Firefox 3.6+ and IE8+.
PS. Might be important: the file input element can't be anywhere near the link, because the link is inside a form and that form is (must be) separate from the file upload form.
UPDATE
Second best: detect support for this high-techlike behaviour that only doesn't work in IE. I don't wanna use navigator.appName.contains('MSIE') because that's not flexible and not necessarily true.
#Rudie, up here - Thanks for that code! It works great in IE and Chrome, but not in FireFox.
I managed to take my old code (That works in FF and Chrome) and combined your code for MSIE.
Check it out here:
FIX FOR IE, CHROME AND FIREFOX
https://gist.github.com/4337047
PROBLEM:
When an file-input is opened via a scripted, forced click() event, IE won't let you submit the form.
If you click the file-input via your own mouse (what we don't want), IE will let you submit the form.
Please note that IE11, as of now, is allowing the form to submit if a file input field has changed via a scripted 'click' event.
Solution
(partly thanks to Rudie # Stackoverflow, https://stackoverflow.com/users/247372/rudie , http://hotblocks.nl/):
Make a label for the input in IE. If you click it, it will force a click on the input field - and IE will accept that (dumbass IE thinks user clicked the input field, hah)
So in that label we'll put our own styled DIV.
Next problem was, this doesn't work in FF. So we made a simple (possible nasty) browser check, and based on the browser we'll show a different button.
Solution is right here. Tested in:
Win 7 x64
FireFox 13.01
Chrome 23.0.1271.97 m
IE9 in regular IE9 mode
More tests / additions to code are MORE than welcome!
EDIT:
To quote Roy McKenzie
IE11 is now allowing the form to submit if a file input field has changed via a scripted 'click' event.
I did it!!
http://jsfiddle.net/rudiedirkx/8hzjP/show/
<label for="picture">Upload picture</label>
<input type="file" id="picture" style="position: absolute; visibility: hidden" />
IE8 works. I don't care about others.
So easy =)
Strange indeed, IE8 block the submission only if there's enctype="multipart/form-data" in the form.
One workaround that worked for me locally is adding "real" submit button e.g.
<input type="submit" id="btnSubmit" value="Submit" />
Then have such code to submit:
$('btnSubmit').click();
If this works you can probably hide the button with CSS to make it transparent to the user.
Well, this is the EXACT same problem I'm having right now. And only (disgusting) hack that did solve is to make the input[type=file] quite big with CSS, make it alpha=0 and put it on top of your intended UI element.
In short, you're making the user click the ugly "browse" button without him/her realizing.
Try adding the tag enctype="multipart/form-data" to your form element.