76

I'm making a web app to manage product SKUS. One part of that is to associate SKUs with product names. On each row of a table, I list a SKU and display a <select> box with product names. The product that's currently associated with that SKU in the database is given an attribute like selected="selected". This can be changed and updated via AJAX.

There are a lot of product <option>s - 103 to be exact - and this list is repeated in the <select> on each row.

From another input on the page, I am using jQuery AJAX requests to add new SKU/product associations, and to make it clear that they're added instantly, I insert them into the top of the table with a little highlight effect. As the number of SKUs increases past 10 or so, if I refresh the page (which loads everything back out of the database ordered by product name), Firefox starts to show some wrong options as selected by default. It is not consistent about which incorrect option it shows, but it seems to be mixing up the options that existed before the page reload.

If I inspect the <select> using Firebug, the select="selected" is on the correct <option> tag. Refreshing the page (or leaving and typing this page's URL back in to return) does not make it show up correctly, but hard refreshing (Ctrl+F5) does.

Both Chrome and IE7 display this correctly in the first place.

My theory is that this is a result of a faulty cache strategy by Firefox. Does that sound right? Is there any way I can say in my code "if this page is refreshed, make it a hard refresh - reload everything from scratch?"

Update

To solve this problem, I changed strategies.

  • Previously, I put a <select> with a long list of <option>s on each table row, with the current value set as default
  • Now, I put the current value in a <span>. If the user clicks a "change" button, I replace the <span> with a <select>, and the "change" button becomes a "confirm" button. If they change options and click confirm, AJAX updates the database, the and the <select> goes back to being a <span>, this time with the new value.

This has two benefits:

  • It fixes the bug described above
  • It requires far fewer DOM elements on the page (all those redundant <option>s)
Community
  • 1
  • 1
Nathan Long
  • 122,748
  • 97
  • 336
  • 451
  • 4
    If you read all of this, **thank you**. I know it was wordy. – Nathan Long Sep 25 '09 at 19:45
  • 4
    It's amazing that FireFox still has this ODD behavior (ALL other browsers do not do this silly thing) and it's even more amazing that FireFox developers consider this as a good feature https://bugzilla.mozilla.org/show_bug.cgi?id=46845 rather than just an IRRITATING BUG!!! (still there in FF version 11). – Marco Demaio Apr 10 '12 at 20:36
  • This behavior should not be enabled by default!! The user should be prompt to opt in or out ( would you like to preserve you forms selections or something ? ). Here is one use case, say you have a cart and the cart content is updated on another page, then the user refreshes the cart page. The user should see the new changes! – mehany Apr 05 '16 at 19:30

12 Answers12

126

I had a similar problem, but after adding autocomplete="off" HTML attribute to every select tag it worked. [I was using Firefox 8]

Arsen7
  • 12,522
  • 2
  • 43
  • 60
BananaDeveloper
  • 1,363
  • 2
  • 9
  • 7
  • autocomplete is not a w3c valid – Jose De Gouveia Sep 18 '15 at 14:49
  • Doing this creates a validation error `Attribute autocomplete not allowed on element select at this point.` – Lee Oct 05 '15 at 08:56
  • 1
    I had a same problem on Firefox ver 44.0 (2016-Jan). And this solution still works. – Steven Feb 04 '16 at 06:05
  • **Why do people prefer this if it's not valid HTML?!?!?!** – doABarrelRoll721 Feb 16 '16 at 01:21
  • 8
    @doABarrelRoll721 **Because it works !!!** Other answers doesn't provide any non-dirty-JS way to fix this issue. This works as expected and is the most proper way to solve this issue (the iframe solution is terrible). And except if you're a W3C hardcore fan, adding this attribute does nothing wrong in browsers that doesn't support it. – vard Feb 17 '16 at 18:45
  • 2
    @doABarrelRoll721: prefer this than what? jQuery hack or playing around with iframes? Please provide us better solution. – Rafał Swacha Mar 04 '16 at 08:28
  • 1
    It's perfectly valid HTML. It doesn't have a standardized meaning prescribed by a w3c spec, so browsers are in principle free to e.g. ignore the autocomplete attribute on a select field, but that doesn't make it invalid. If all major browsers take autocomplete="off" on a select element to mean "don't remember the last selected value after a refresh", then this is a good solution. – Confusion Nov 17 '16 at 21:38
50

Firefox preserves your selected form elements when you refresh. It's intentional. Ctrl+F5 is a "hard" refresh, which disables this behavior.

--

Or Command+Shift+R if you are on a Mac

Steven
  • 113
  • 1
  • 5
Ted Mielczarek
  • 3,919
  • 26
  • 32
16

An easy way to prevent Firefox from caching the last selected option is to remove all of the option elements on page unload. For example (assuming jQuery):

$(window).unload(function() {
  $('select option').remove();
});
ozu
  • 161
  • 1
  • 2
12

I had this same issue. I was trying to change the value of the select depending on which option had selected="selected", but Firefox wasn't working. It would always default to the first option.

Chrome, Safari, etc worked when I did this:

$( 'option[value="myVal"]' ).attr( 'selected', 'selected' );

... but this wasn't working in FF.

So I tried:

$( 'option[value="myVal"]' ).prop( 'selected', 'selected' );

and it works.

jQuery v1.9.1

user1063287
  • 10,265
  • 25
  • 122
  • 218
clint_milner
  • 365
  • 6
  • 18
9

Although this is old question, but below solution can help someone

In firefox, I've notice that the "selected" attribute will not work unless you place the select inside a form, where the form has a name attribute.

<form name="test_form" method="POST">
<select name="city">
<option value="1">Test</option>
<option selected="selected" value="2">Test2</option>
</selecct>

Again remember :

  1. form must have the "name" attribute and
  2. "select" must be inside the form.
Rakesh Soni
  • 10,135
  • 5
  • 44
  • 51
  • Well, You saved me! I didn't need to add name to form, just `autocomplete="off"` but crucial was to insert `select` inside `form`. I've lost whole day on this because I didn't have `form` for this select. – Rob Mar 22 '17 at 12:54
  • for me this one works only. For firefox when I set name for the form then it works as expected. Firefox version: 54.0a2 – tioschi May 05 '17 at 11:36
  • I have a form with a name attribute but my select is still cached inside the form after page refresh. – Aurovrata Nov 08 '17 at 07:56
  • Yes! This was the answer for me. And I saw it here first: https://stackoverflow.com/a/12650918/470749 – Ryan Jun 10 '18 at 13:45
8

I make it worked by putting the autocomplete="off" on the hidden input.

Alex
  • 101
  • 3
  • 7
0

FYI: in order to stop Firefox from restoring the previously selected option after page reload you can place the entire <form> containing the <select> options inside an <iframe>.

When select boxes are in <iframe> and you reload the container page, Firefox finally behaves like ALL other browsers, by simply resetting select options.

Marco Demaio
  • 33,578
  • 33
  • 128
  • 159
0

Firebug has a cache disable function for exactly this scenario.

The deeper long-term solution is to work out how set no-cache headers server side. What web server are you using?

lod3n
  • 2,893
  • 15
  • 16
0

Every time I ever had weird select option bugs in Firefox it was because I had multiple options marked as selected. Are you quite sure that only one is marked as such? Seems like you could get out of wack pretty easily if you are changing that with AJAX.

Morinar
  • 3,460
  • 8
  • 40
  • 58
0

Thanks to @BananaDeveloper (https://stackoverflow.com/a/8258154/2182349) - this is my solution to solve this problem on a single page in an application

I didn't want to customize the off-the-shelf/open source application code

<Files "page_that_does_not_work.php">
        SetOutputFilter INFLATE;SUBSTITUTE;DEFLATE
        Substitute 's/<select/<select autocomplete="off"/n'
        Substitute 's/<form/<form novalidate/n'
</Files>

Apache docs for mod_substitute https://httpd.apache.org/docs/2.4/mod/mod_substitute.html

Thanks to: https://serverfault.com/questions/843905/apache-mod-substitute-works-in-curl-but-not-on-browser for the SetOutputFilter

user2182349
  • 9,569
  • 3
  • 29
  • 41
0

Replacing jQuery

.attr('selected', true)

with

.prop('selected', true)

for <option> tag fixes it for me. All other solutions didn't work

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Eugene
  • 1
-1

I've figured out. If you put onunload or $(window).unload (jquery) on your HTML with no-cache header, Firefox reloads the page and initialize DOM even from back button.

Won
  • 1,795
  • 2
  • 12
  • 22