Button does not remove disabled on page refresh #793

paulrose opened this Issue Dec 12, 2011 · 16 comments


None yet

10 participants


When the state of a button is changed there is an error if the page is refreshed without resetting the button.

This has happened when I have been in development an AJAX call has failed for whatever reason and the button state not reset. The page gets refreshed with the latest code changes but the button still has a 'disabled' attribute. A solution would be calling something like this when loading the page:

$(document).ready('bootstrap_buttons', function() {

But would be better if the script did this automatically to have buttons in their correct state at page load.

fat commented Dec 12, 2011

can you provide a jsfiddle?


How is that possible that button states survive page refresh?


Try this:
Click the button, then refresh page. This is using latest Firefox.


That's clearly a Firefox sorcery :P This does not happen in Chromium/Opera.


Calling $('.btn').button('reset') on load does the trick...

Looks like the browser is keeping the disabled attribute.


Looks like this is a "feature": http://stackoverflow.com/questions/5985839/bug-with-firefox-disabled-attribute-of-input-not-resetting-when-refreshing

Seems setting autocomplete="off" on the input (or form) will prevent it from remembering the disabled attribute.

fat commented Dec 12, 2011

wow that's crazy, but not something I think we should deal with in bootstrap -- what do you guys think?


I think there's no point making a "fix" just for Firefox.

@cgunther and autocomplete="off" seems to work, just tested.


It should at least be documented if no fix is to be applied.


Rather than resetting the button states on load, what if we reset the button state on unload of the page?

fat commented Jan 8, 2012

just added a note here - 6e8a3bb

don't think we want to do the unload incase someone is relying on that for something (as weird as that would be)

@fat fat closed this Jan 8, 2012

Excuse me, but if you have a submit button that remembers a disabled state and think just because it happens in Firefox that you don't need a fix, you're fooling yourself. Many people use Firefox and if you have a commercial or donation site, having an active donate button on refresh after people might have errors in their form is EXTREMELY important.

Yeah, autocomplete="off" apparently works, but autocomplete="off" should have been the default.

giorgio commented Sep 27, 2012

I thought the whole point of frameworks like bootstrap or jquery is that they insulate you from the peculiarities of different browsers.
Therefore if Firefox behaves in an odd manner in this instance then a good framework should make that invisible to the developer.


This issue seems out of scope of Bootstrap's purpose as primarily a CSS framework to fix this.

Maybe Firefox is doing it "right" so if it is "fixed" perhaps the fix should be to make the other browsers like Firefox. (playing devil's advocate here)

Finally, how do you actually fix it? On page load a script could look for all disabled buttons and enable them, but how would that script know that those buttons shouldn't be disabled? The only solution seems to be to re-enable them on page unload.

-- edit: Just realized this is an old post but the issue seems to still exist as of FF23:


Ran into the same weird bug today, I think it should be included in Bootstrap for the sole reason that the framework should give a uniform behavior in all browsers, now I still have to apply browser specific fixes!


Another "fix" for this FF bug is to change from using a <button> to a <a> tag button if you can.

@cvrebert cvrebert locked and limited conversation to collaborators Jun 19, 2014
@cvrebert cvrebert added a commit that referenced this issue Sep 3, 2014
@cvrebert cvrebert Add Wall of Browser bugs entry for #793
Also, link to the Mozilla bug in the relevant callout.
@MatrixZ MatrixZ pushed a commit to MatrixZ/bootstrap that referenced this issue Oct 9, 2014
@cvrebert cvrebert Add Wall of Browser bugs entry for #793
Also, link to the Mozilla bug in the relevant callout.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.