2

I have a <input type = 'file'>. To enable/disable it I use jQuery("#my_input").prop('disabled' ,true/false).

If I disable it, then refresh the page, jQuery outputs: 

console.log(jQuery("#my_input").prop('disabled' )) ==> true

even though the 'disabled' prop is not included in the html.

Clearing the cache does not fix it.

Omar
  • 32,302
  • 9
  • 69
  • 112
dsdsdsdsd
  • 2,880
  • 6
  • 41
  • 56

2 Answers2

4

Firefox has long been saving input values through refreshes, and now the latest builds also save input / button's disabled status through refreshes.

I'm not sure whether this is intended or a bug, but for the time being an workaround is to just set the inputs' disabled status to their default ones inside a DOM ready handler.

jQuery(function($) {
    $("#my_input").prop('disabled', false);
});

Demonstrating the issue: Fiddle (open with Firefox)
And now fixed with the snippet above: Fiddle

You can also apply autocomplete="off" to the element and its disabled status won't persist through refreshes.

Fiddle

Note that this will prevent any form of auto-completion in the element. Of course, this is an excellent solution for file inputs and buttons, however depending on your use case (e.g. when it involves text inputs) you may prefer the former solution. Thanks to @dsdsdsdsd for the tip!

p.s. This has been reported to Mozilla already: Bugzilla ticket.

Fabrício Matté
  • 69,329
  • 26
  • 129
  • 166
  • Nice info. My fiddle works fine, sounds like your answer is good! http://jsfiddle.net/yNH6M/ – scrowler Oct 10 '13 at 21:38
  • 1
    "Firefox has long been saving input values through refreshes" led me to this: [SO](http://stackoverflow.com/questions/4263536/firefox-cache-textarea-value) which has a solution that worked: `
    `
     – dsdsdsdsd Oct 10 '13 at 21:40
  • @dsdsdsdsd yes nice to mention that, though `autocomplete="off"` completely disables autocompletion right? That doesn't work very well for all use cases, but yeah it kills the post-refresh values keeping. – Fabrício Matté Oct 10 '13 at 21:42
  • yes you're right ... maybe applying it to the form element is a little too nuclear-bomb-ish ... could apply the attribute directly to the input element instead of the form. – dsdsdsdsd Oct 10 '13 at 21:45
  • @dsdsdsdsd that's worth a try. `=]` Let's see – Fabrício Matté Oct 10 '13 at 21:49
  • @scrowler thanks for the fiddle, I've made some adaptions and added to the answer. `=]` – Fabrício Matté Oct 10 '13 at 21:50
  • @FabrícioMatté if you'll add the discussion about the autocomplete to your answer, I would think that a reader would have a solid set of possibilities to solve their problem. – dsdsdsdsd Oct 10 '13 at 21:55
  • @dsdsdsdsd Just did. `=]` Was still testing, I'll add a fiddle and a note. – Fabrício Matté Oct 10 '13 at 21:56
  • 1
    fyi i (and at least a couple other people i've spoken too) use a greasemonkey script that blanket nukes `autocomplete="off"` because it's almost always used for terrible reasons like preventing password storage. so you might want to go with the less nuclear approach of restoring form state explicitly. – Eevee Oct 10 '13 at 22:19
  • @Eevee Yes, I tend to disable autocompletion as a last-resort approach, and that is an use case that I didn't think of. I really hope this to be a short-lived bug, well I'll browse bugzilla a bit. – Fabrício Matté Oct 10 '13 at 22:24
0

Firefox should include it in html also.

What happens if you use:

jQuery("#my_input").attr('disabled' ,true)
edwardbrosens
  • 112
  • 7