10

I am trying to dynamically change the actual HTML value attribute of an input using jQuery. Although using input.attr('value', 'myNewVal'); works to change it visually, when I inspect the source using Developer Tools in Chrome, the HTML attribute hasn't changed.

Since I'm doing a check in some PHP later on to see if the input has its original value, I need a way of changing the actual HTML attribute, ideally in jQuery. Has anyone else encountered this annoying bug and do any of you guys know a workaround?

I've also tried with .val() and the same happens - the underlying HTML attribute is unchanged.

BenM
  • 52,573
  • 26
  • 113
  • 168

11 Answers11

15

attr should work as well, specially since you do see it change, but try also to use val - it is better suited for changing values:

input.val('myNewVal');

Make sure not to use the "View Source" command, it reloads the page, or shows the page as it was loaded. Instead, use the DOM viewer - right click on the input element and choose "Inspect element". (This is the same as "Development tools" - Ctrl+Shift+I in Chrome in Windows)

Kobi
  • 135,331
  • 41
  • 252
  • 292
  • Should have mentioned that I already tried that, and it doesn't affect the actual underlying HTML attribute. – BenM Mar 31 '11 at 22:13
  • 1
    Definitely use `.val()`. jQuery provides a great service there, providing a common interface over e.g. textareas and inputs. I remember some bug in relation to `.attr('value')` and IE. `.val()` takes care of that as well – skarmats Mar 31 '11 at 22:14
  • 1
    This does not address the question: the value is changed successfully. It's the *markup displayed by the tools* that does not update. – Jon Mar 31 '11 at 22:16
  • @Jon - I hope it's better now, I was getting there. – Kobi Mar 31 '11 at 22:19
  • Excellent tip on not using View Source – Brendan Mar 26 '15 at 20:14
  • @Kobi It is. My problem with both was that I wasn't waiting for the page to load. So, \o/. Deleted the comment, as it might be misleading. – Mooncrater Apr 10 '20 at 15:40
  • 1
    @Mooncrater - Got it, glad it worked out. I'll delete my comments too. Thanks! – Kobi Apr 10 '20 at 23:25
8

Both attr() and val() deal exclusively with the value property [update February 2014: this was true prior to jQuery 1.6 but is not true since the introduction of prop() in 1.6], not attribute. The value attribute only specifies the initial value of the input. Once the actual text within the input has changed (either by user input or script), the value property and attribute operate entirely independently. In almost all cases, this doesn't matter, because it's almost always the current value that you want (and it's that value that is submitted to the server).

If you really must change the actual attribute (which I'm pretty sure you don't), do it via setAttribute():

input[0].setAttribute('value', 'myNewVal');

Note that IE < 8 (and compatibility modes in IE 8) has broken support for getAttribute() and setAttribute() that maps attributes to properties, so the above doesn't apply in those browsers.

Tim Down
  • 318,141
  • 75
  • 454
  • 536
  • The whole concept sounds awfully counter productive. I mean, since when clicking "shut down" caused a computer to "restart" (by comparison)? – Christian Mar 31 '11 at 22:39
  • Oh, and again, if the Developer Tools actually show the old value, why use them in the first place? Anyone can see the old value by looking at the page source. It defeats the whole purpose. – Christian Mar 31 '11 at 22:40
  • @Christian: Retaining different values for current and initial state doesn't seem unreasonable to me, but I agree the mechanism by which it is done in DOM isn't very intuitive. jQuery hasn't helped matters by pretending this poorly understood fundamental difference doesn't exist with its unfortunately-named `attr()` method. – Tim Down Mar 31 '11 at 22:49
  • 2
    @Christian: For a text input box you can see the current value by looking at the page :) – Tim Down Mar 31 '11 at 22:51
  • @Tim Down - Aha! You got me there. Either case, +1 for this little info about properties vs attributes; something I thought never existed (or well, more of a quirk than a fact). **Edit:** Arguably, the input *might* have been hidden (or it *might* be of type hidden), which again brings us to our little dilema. – Christian Apr 01 '11 at 01:07
5

Use .val(). 

input.val("some text");

Based upon your comment, the view source will most likely not be updated. If you are still getting the original value, something else must be going on and more details most likely will be required.

jsfiddle goodness.

Mark Coleman
  • 40,542
  • 9
  • 81
  • 101
4

This is not a bug. The value attributte is not supposed to change.

The input control is a bit special. According to the HTML spec, the value content attribute gives the default value of the input element. You can see the actual control value which has been set programatically or changed by user in the DOM explorer. When the form is reset the value of the element is set to the value of the value content attribute. (too many values here :))

This is the standard behaviour for all VISIBLE input types. (try setting value for a HIDDEN element and value content attribute will be updated ... in Firefox at least).

Corneliu
  • 2,932
  • 1
  • 19
  • 22
3

Don't use .attr() to change the value, use .val(), which was made specifically for this purpose:

input.val("new value");
Alex
  • 64,178
  • 48
  • 151
  • 180
3

That's because the developer tools do not refresh. This is a well known bug in these tools, including Opera's, Safari's as well as Firebug's (the latter one being a different issue).

As far as I know, you can right-click the source tree window and hit "refresh". This doesn't refresh the page, just the source view. This "fix" doesn't work in firebug though.

Christian
  • 27,509
  • 17
  • 111
  • 155
  • +1, this is the only answer that correctly addresses the question. – Jon Mar 31 '11 at 22:14
  • But even parsing the value in PHP from the `$_POST` array once the form has been submitted returns the initial value, rather than the one changed through jQuery... – BenM Mar 31 '11 at 22:15
  • 1
    Then you're dealing with two bugs. Do something like: `` – Christian Mar 31 '11 at 22:17
  • 3
    It's not a bug in the developer tools at all. jQuery's `attr()` method almost always changes *properties*, not attributes. In the case of `value`, once the value has been changed (by user input or script), the value attribute and the `value` property will have different values. – Tim Down Mar 31 '11 at 22:19
  • @Tim Down - It's definitely a bug if they [dev tools] report something while the server gets something else. Who causes the bug is an entirely different matter ;). – Christian Mar 31 '11 at 22:22
  • 2
    I don't really agree with the claim it is a common bug in *all* of these 4 browsers. I rely quite heavily on Firebug and Chrome when I debug scripts, and I've never experienced a problem with them - they always refresh with the DOM, at least in my experience. – Kobi Mar 31 '11 at 22:25
  • @Kobi - Firebug is a separate beast. The other 3 major browsers share the same Developer Tools codebase, except maybe MSIE (not sure). I've had this issue while using jquery that quickly modified page elements. Could be they fixed it lately, but it was there for sure. – Christian Mar 31 '11 at 22:28
  • @Christian: The value property (which represents the current state of the input) and value attribute (which represents the initial state) are different things. There is more to an HTML document's DOM than its HTML string representation. – Tim Down Mar 31 '11 at 22:32
  • 1
    @Christian Sciberras I assure you with 100% confidence that Microsoft is definitely **not** using the WebKit developer tools :-) – Pointy Mar 31 '11 at 22:33
  • @Pointy - Well, I'm always careful not to bet my head on anything Microsoft related :). @Tim Down - That brings us to the question; what should the developer tools tree window show us? Personally, I view it as a bug, since this isn't about "how it works" but "how it should make life easier". – Christian Mar 31 '11 at 22:37
  • @Christian: It's a fair question. Seeing as it shows an HTML string representation, it seems reasonable for it to display attributes (which are used in HTML to specify information about an element's initial characteristics) rather than properties (which represent information about the current state of the element). It's also consistent with what `innerHTML` returns (in most browsers, at least). – Tim Down Mar 31 '11 at 22:44
1

I have a case in which jQuery function .val() and .attr("value", "...") works incorrect for value with url. Functions update the user interface but it doesn't effect with DOM(source). In this case should be used:

jQueryObj[0].setAttribute("value", "...");

It's right for jQuery v1.5.* => v1.6.*, for another versions it's not be checked.

Anton
  • 1,583
  • 12
  • 17
1

The dev tools show you the source code as it arrived from the server (for the value attribute), so you see the truly original value.

If you want to alter it (and check against the new value) you can store a reference somewhere. Best would be to use the .data() method and check against that stored value.

For usage purposes though (submitting or accessing it through JS), changing the value through the .attr() or .val() method should be enough.

Gabriele Petrioli
  • 191,379
  • 34
  • 261
  • 317
1

It won't change the value in the DOM explorer of most development tools. But JavaScript will still get the current values. So

var newValue = 'new';
$(sel).val(newValue);
newValue == $(sel).val(); // true
skarmats
  • 1,907
  • 15
  • 18
1

They responses that inform you to use the .val("value") method are correct, the only way that I know of to see these changes (in the source) is using the Firefox Web Developer Plugin and clicking "View Source" -> "View Generated Source". This shows the source after DOM manipulation (i.e. calls to the .val() method) have occurred, I use it a lot when working with functions/methods that modify DOM elements.

So to recap: [#input_id = ID of your input field]

$("#input_id").val("new value");

Then use the plugin to view the generated source and you will see the updated value.

niczak
  • 3,897
  • 11
  • 45
  • 65
0

This may be slightly off topic, but I have found that when I use the .data() function in jQuery, the value is set correctly, but the change isn't reflected in developer tools.

So,

$('#element').data('to-update', 'newValue')

In the developer tools (Elements view) still shows the old value.

But

$('#element').data('to-update')

returns 'newValue'

fragilewindows
  • 1,394
  • 1
  • 15
  • 26
David McEleney
  • 3,397
  • 1
  • 26
  • 32