Why doesn't Firefox show the correct default select option?

FirefoxSelectCaching

Firefox Problem Overview


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)

Firefox Solutions


Solution 1 - Firefox

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

Solution 2 - Firefox

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

Solution 3 - Firefox

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();
});

Solution 4 - Firefox

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

Solution 5 - Firefox

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

Solution 6 - Firefox

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.

Solution 7 - Firefox

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?

Solution 8 - Firefox

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.

Solution 9 - Firefox

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.

Solution 10 - Firefox

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

Solution 11 - Firefox

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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionNathan LongView Question on Stackoverflow
Solution 1 - FirefoxBananaDeveloperView Answer on Stackoverflow
Solution 2 - FirefoxTed MielczarekView Answer on Stackoverflow
Solution 3 - FirefoxozuView Answer on Stackoverflow
Solution 4 - Firefoxclint_milnerView Answer on Stackoverflow
Solution 5 - FirefoxAlexView Answer on Stackoverflow
Solution 6 - FirefoxRakesh SoniView Answer on Stackoverflow
Solution 7 - Firefoxlod3nView Answer on Stackoverflow
Solution 8 - FirefoxMorinarView Answer on Stackoverflow
Solution 9 - FirefoxMarco DemaioView Answer on Stackoverflow
Solution 10 - Firefoxuser2182349View Answer on Stackoverflow
Solution 11 - FirefoxWonView Answer on Stackoverflow