views:

153

answers:

4

What might be changing the DOM of a web page after the browser receives the response?

I'm seeing this behavior in the value of a hidden input element that holds a single-use form token.

When I 'view source' in a browser, I see the correct value, as written out by the server. When I submit the form, view the current state of the DOM, or just change the element to a text input, i see a different string. So the value the input holds when it's time to post back to the server is different from the one the server originally sent.

The problem persists with javascript disabled. Adding a readonly attribute to the element didn't help either.

NEW INFO: I fiddled around with this some more, and, believe it or not, turning images OFF in Firefox makes this problem go away.

Why on earth would this happen?

+1  A: 

If the browser has "save form data" capabilities, it's possible it's pre-populating the data with a value previously submitted.

(I would expect that popular browsers are smart enough not to populate hidden fields, but that's one source of this I can suggest...)

Stobor
A: 

What do you mean by "when I submit the form, view the current state of the DOM"?

If you submit the form, does it send a request to the server? Are you talking about the state of the DOM on the resulting page sent back by the server?

It's not really possible that, with no client-side scripting involved, your DOM gets changed on the client side.

If on the other hand, you submit to a server and get back a whole new DOM, then, well, the server changed it.

AmbroseChapel
submitting the form to the server, viewing the DOM (inspect element), or using a text field are all ways to view the part I care about: value="XXX"These three all agree on what XXX is, but they do not match the value stored in the session OR the value I see when i 'View Source' in the browser.
grossvogel
+1  A: 

You might have some luck putting readonly="readonly" in the field tag, and autocomplete="off".

Not sure if browser autocomplete would be doing it, but it is plausible, could also try disabling autocomplete in your testing browsers and see if that changes anything.

seanb
+1  A: 

I wasn't correct in my interpretation of what was happening. I guess that's a good thing, because what I thought I was seeing shouldn't ever happen! Anyway, here's the situation as I now understand it:

The form token here is single use, so it's only valid for a single page load. Somewhere else on the page was an img tag with no src attribute, which was causing the browser to attempt to load the image from /. Since the index page is a php page, the token got cycled.

I believed the DOM changed, I think, because some implementations of 'view source' (I was testing in several browsers) seemed to cause a page reload, as well...

Thanks for all of the suggestions.

grossvogel
One of the (many) things that most pisses me off with Firefox is its insistence on reloading the page to view source. Especially when said page is on a logged-in system. Fortunately the Web Developer Toolbar has a workaround that lets you "View Generated Source" and avoid the reload.
Peter Boughton