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: http://raymondcamden.com/demos/2012/jul/17_3/test2.html
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?
Archived Comments
It could be worse ... In Internet explorer does not even work!!!
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.
Ran into this while doing some work with buttons using Bootstrap. There is an issue on the Bootstrap github about it - https://github.com/twitter/...
Apparently this is a 'feature' of Firefox - http://stackoverflow.com/qu...
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.
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?
You were right. The problem in IE9 was for the console!!!
Found this while looking up another issue.
http://stackoverflow.com/qu...
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.
Not sure if Firefox would remember it if you used jQuery. You'd have to test it to find out.
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.
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.
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.
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.
Ah, shift+reload. That works and is 100% accessible via the keyboard. Thanks!
Not sure about this, but...
"The .prop() method should be used to set disabled and checked instead of the .attr() method."
http://api.jquery.com/prop/
Have you tried it?
Andres, that doesn't make a difference, _but_ is a useful reminder. I keep forgetting about prop. Thank you.
I've been getting around this for years by enabling the button as part of any other commands I run on page load.
$(document).ready()(function(){
$('#btn').attr('disabled',false)
});
@Raymond:
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.