Twitter: raymondcamden

Address: Lafayette, LA, USA

Firefox bug(?) with DOM Manipulation

07-17-2012 4,485 views jQuery, JavaScript 17 Comments

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?


  • Elias #
    Commented on 07-17-2012 at 3:24 PM
    It could be worse ... In Internet explorer does not even work!!!
  • Commented on 07-17-2012 at 3:25 PM
    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.
  • Bryce #
    Commented on 07-17-2012 at 3:26 PM
    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 -
  • Commented on 07-17-2012 at 3:30 PM
    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.
  • Commented on 07-17-2012 at 3:32 PM
    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?
  • Elias #
    Commented on 07-17-2012 at 3:34 PM
    You were right. The problem in IE9 was for the console!!!
  • Bryce #
    Commented on 07-17-2012 at 3:36 PM
    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.
  • Bryce #
    Commented on 07-17-2012 at 3:38 PM
    Not sure if Firefox would remember it if you used jQuery. You'd have to test it to find out.
  • Commented on 07-17-2012 at 3:39 PM
    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.
  • Commented on 07-17-2012 at 3:47 PM
    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.
  • Commented on 07-17-2012 at 3:49 PM
    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.
  • Commented on 07-17-2012 at 4:07 PM
    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.
  • Commented on 07-17-2012 at 4:08 PM
    Ah, shift+reload. That works and is 100% accessible via the keyboard. Thanks!
  • Commented on 07-17-2012 at 4:10 PM
    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?
  • Commented on 07-17-2012 at 4:12 PM
    Andres, that doesn't make a difference, but is a useful reminder. I keep forgetting about prop. Thank you.
  • Paul #
    Commented on 07-18-2012 at 7:40 AM
    I've been getting around this for years by enabling the button as part of any other commands I run on page load.

  • Commented on 07-18-2012 at 9:01 AM

    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.

Post Reply

Please refrain from posting large blocks of code as a comment. Use Pastebin or Gists instead. Text wrapped in asterisks (*) will be bold and text wrapped in underscores (_) will be italicized.

Leave this field empty