#1954 closed bug (fixed)
val() returns innerHTML for button elements in IE
Reported by: | dmuir | Owned by: | timmywil |
---|---|---|---|
Priority: | high | Milestone: | 1.6 |
Component: | manipulation | Version: | 1.4.4 |
Keywords: | IE button val() | Cc: | |
Blocked by: | Blocking: |
Description
val() returns the value of the value property in FF, but returns the value of innerHTML in IE.
jQuery 1.1.4 did not have this bug.
html: <button value="myValue">Click Me</button>
js: alert($('button').val());
IE: alerts "Click Me"
FF: alerts "myValue"
Attachments (1)
Change History (26)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
must have been seeing things... tested again with 1.1.4 and it doesn't work there either. The only solution I have is to retrieve the html for the button element and do a regex to extract the value attribute. IE's button dom element does not have a property storing the value (it is overwritten by the button's innerHTML).
comment:3 Changed 15 years ago by
Weird. I see the same thing you do. Using the debugger the "value" as assigned by the attribute just isn't stored anywhere and appears to be overwritten by the innerHTML. It's interesting if you overwrite the value it will then be correct like:
$("button").val("newValue"); alert($("button").val());
alerts "newValue" in both IE and FF. I hate to say it but there does not appear to be an easy cross-browser fix. :(
comment:4 Changed 15 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Doesn't look like this can be resolved, unfortunately.
comment:5 Changed 14 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
i've dug up a fairly dirty/ugly workaround (credit: http://odyniec.net/projects/iefixbuttons/):
var rawval = $("button").get(0).outerHTML.match(/value\s*=\s*['"](['"]*)['"]/);
var val = (rawval ? rawval[1] : );
to be combined with if($.browser.msie)
this will fail in cases like value="bla'bla'bla", which are perfectly valid in HTML
can someone with better JS regex skills than me figure out how to catch the opening character and match everything until it shows up again? I believe that would be a fairly robust (albeit ugly) fix, which could be implemented in jquery core?
comment:6 Changed 14 years ago by
Milestone: | 1.2.2 → 1.3 |
---|---|
need: | Review → Patch |
Owner: | set to flesler |
Status: | reopened → new |
aButton.attributes.value.nodeValue returns the value on IE.
I think this can be indeed worked around.
comment:7 Changed 14 years ago by
Status: | new → assigned |
---|
comment:8 Changed 14 years ago by
Cc: | dmuir added |
---|
comment:13 follow-up: 14 Changed 13 years ago by
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
This seems to be working now, tested in 1.4.2 and IE8.
comment:14 Changed 12 years ago by
Replying to dmethvin:
This seems to be working now, tested in 1.4.2 and IE8.
doesn't work in ie7 or wp7 (which is also ie7) comment 6 has the answer
comment:15 Changed 12 years ago by
As stated above this issue is not fixed yet for IE7 in jQuery 1.4.4. The workaround mentioned in comment:6 works for IE7 on WinXP and should be implemented for the val and attr functions.
Unfortunately, this issue tracker in use here doesn't permit to reopen the bug for whatever reason.
comment:16 Changed 12 years ago by
Cc: | dmuir removed |
---|---|
Component: | core → manipulation |
Milestone: | 1.3 → 1.6 |
Priority: | major → high |
Resolution: | worksforme |
Status: | closed → reopened |
Version: | 1.2.1 → 1.4.4 |
comment:17 Changed 12 years ago by
Status: | reopened → open |
---|
comment:19 Changed 12 years ago by
I have an updated patch against git that handles reading & setting button values via .val() & .attr('value') as well as .removeAttr('value'). I don't seem to be able to attach it to this ticket, though. Shouldn't there be an "Attach file" button somewhere?
comment:20 Changed 12 years ago by
can't see where to add an attachment either... but I'm curious to see what your solution is.
comment:21 Changed 12 years ago by
It's nothing especially clever, just some special-cases that use getAttributeNode, setAttributeNode & removeAttributeNode. The special-cases target only the value attribute on buttons in IE7 (and lower) to minimise the impact.
I've stuck it up here: https://gist.github.com/776092
comment:22 follow-up: 23 Changed 12 years ago by
Hi,
Please consider the following test case with IE7 : http://jsbin.com/ipitu4 Each button is written as
<button value="some value">some code</button>
.
We would expect IE7 to return the correct "value" attribute value when calling
$('button').attr('value'); // BUG
... It doesn't !
The solution is given by the third button
$('button').get(0).getAttributeNode('value').value; //CORRECT
Regards, Julien
comment:23 Changed 12 years ago by
Replying to [email protected]…:
Same test case with jsFiddle : http://jsfiddle.net/sKuHr/1/
comment:24 Changed 12 years ago by
Here's a new patch which tests for the bug instead of using browser detection:
comment:25 Changed 12 years ago by
And another, stripped-down, patch which only fixes the most common usage case (reading the value attribute):
comment:26 Changed 12 years ago by
Owner: | changed from flesler to timmywil |
---|---|
Status: | open → assigned |
comment:25 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fix value attribute and val for value on button elements. Fixes #1954
Changeset: 34d80709ce9bd583f6f5dd17e9bffa2fb7cff3c5
using .attr('value') does not work around this issue either