Firefox bug(?) with DOM Manipulation

This post is more than 2 years old.

I was working on a new project today when I ran into an odd bug with Firefox. Firefox is not my primary browser, but I've been trying to use it a bit more lately as it seems to be adding some new features. But this bug.... wow. It seems, and let me be clear here, it seems so incredibly stupid that I have to imagine that I'm doing something wrong. I can't imagine a browser doing something like this without it being some setting that maybe I tweaked in the past. That being said, here is a simple example of it that you can try yourself. I'm more than willing - shoot - I'm hoping I'm wrong.

Basically - the page has one button. I use jQuery to create a click listener for it that simply disables the button. Nothing magic, right? You can run my version here:

Run this in Chrome. Click the button. Confirm it disables. Then reload. Everything is cool, right?

Run this in Firefox. Click the button. Confirm it disables. Then reload. WTF. You clearly see a new console message with the right date, but the button stays disabled. To get around this I have to press Enter in the URL bar.

Firefox reran the JavaScript but kept the DOM unchanged from its last stage.

I cannot begin to imagine by what logic this makes sense, but.... maybe one of you smart people can tell me what I'm seeing here?

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Elias posted on 7/18/2012 at 12:24 AM

It could be worse ... In Internet explorer does not even work!!!

Comment 2 by Raymond Camden posted on 7/18/2012 at 12:25 AM

Probably because of console. Console is in IE9 I think. The jQuery should work in IE6 and higher though. FOr the heck of it, download my code, remove the consoles, and tell me what you see.

Comment 3 by Bryce posted on 7/18/2012 at 12:26 AM

Ran into this while doing some work with buttons using Bootstrap. There is an issue on the Bootstrap github about it -

Apparently this is a 'feature' of Firefox -

Comment 4 by Raymond Camden posted on 7/18/2012 at 12:30 AM

My god.... well, that explains it. Thank you. I find this... incredible.

The next question is - is there a way to disable this w/o modifying the HTML? And shoot, does autocomplete="off" even make sense on a button? Trying it.

Comment 5 by Raymond Camden posted on 7/18/2012 at 12:32 AM

Yep, autocomplete="off" in the button seems to work, but feels dirty and unnecessary. Disabled is a property of the field, NOT the value. Shoot, if I use jQuery to move it to a new position, would Firefox remember that too?

Comment 6 by Elias posted on 7/18/2012 at 12:34 AM

You were right. The problem in IE9 was for the console!!!

Comment 7 by Bryce posted on 7/18/2012 at 12:36 AM

Found this while looking up another issue.

Seems like it isn't supported in Firefox 3.6.15. Not sure if it is just that version or anything previous to it as well.

Comment 8 by Bryce posted on 7/18/2012 at 12:38 AM

Not sure if Firefox would remember it if you used jQuery. You'd have to test it to find out.

Comment 9 by Raymond Camden posted on 7/18/2012 at 12:39 AM

I just tested. Using jQuery to move a button's top/left position does NOT persist in Firefox. But by what logic is "disabled" considered ok to persist but not other things like left/top. If you are going to do something like this then be consistent.

Comment 10 by Michael Stone posted on 7/18/2012 at 12:47 AM

I've ran into this before. Seems to be FireFox is doing a little too much DOM caching and forces developers to add kludge fixes.

Comment 11 by Raymond Camden posted on 7/18/2012 at 12:49 AM

To be clear - I'm pro autocomplete, but isn't it the "standard" that you wait until the user types stuff in? Like I type "R" in a name field and I get an auto complete for Raymond. _Before_ that if the html was value="" I'd expect to see an empty field. Always.

Comment 12 by Chris Heilmann posted on 7/18/2012 at 1:07 AM

This is Firefox caching form entries in case you reload by accident. You need to shift+reload the page to avoid it during testing. I find it annoying during development but it saved my tushie quite some time when getting flight tickets.

Comment 13 by Raymond Camden posted on 7/18/2012 at 1:08 AM

Ah, shift+reload. That works and is 100% accessible via the keyboard. Thanks!

Comment 14 by Andres Cayon posted on 7/18/2012 at 1:10 AM

Not sure about this, but...
"The .prop() method should be used to set disabled and checked instead of the .attr() method."

Have you tried it?

Comment 15 by Raymond Camden posted on 7/18/2012 at 1:12 AM

Andres, that doesn't make a difference, _but_ is a useful reminder. I keep forgetting about prop. Thank you.

Comment 16 by Paul posted on 7/18/2012 at 4:40 PM

I've been getting around this for years by enabling the button as part of any other commands I run on page load.


Comment 17 by Dan G. Switzer, II posted on 7/18/2012 at 6:01 PM


I think Mozilla's point of view is that a "disabled" field is part of the cached state of your form--which is why setting autocomplete to "off" resolves the issue.

For example, a common use case is to have a series of radio elements with an "Other" option that has a corresponding text box you can fill in. For any radio option not "Other" you disable the text box. If by caching the state of the disabled field, the form is returned to it's exact state before you reloaded.

That said, I think that should be on the developer to control behavior, but I'd assume that's why they implement caching of the disabled property along w/the value of the fields.