Hilfe durchsuchen

Vorsicht vor Support-Betrug: Wir fordern Sie niemals auf, eine Telefonnummer anzurufen, eine SMS an eine Telefonnummer zu senden oder persönliche Daten preiszugeben. Bitte melden Sie verdächtige Aktivitäten über die Funktion „Missbrauch melden“.

Weitere Informationen

HTML styles for <option> elements no longer work with latest Firefox 49.0.1

  • 1 Antwort
  • 79 haben dieses Problem
  • 20 Aufrufe
  • Letzte Antwort von philipp

more options

Hi. We have a web application which has a number of <select> elements whose <option> child elements have CSS 'style' attributes to change the background color of some of the options, to make them stand out, like this simple test:

<select name="select">

 <option value="one">ONE</option>
 <option value="two" style="background-color: #00FF00;">TWO</option>
 <option value="three" style="color: #FF0000;">THREE</option>
 <option value="four" style="color: #FF0000; background-color: #00FF00;">FOUR</option>

</select>

This works with older version of Firefox but our users have discovered that the latest version, 49.0.1, ignores the styles for the <option> elements; in the example above all of the lines in the dropdown list for the <select> element have the same default background and color.

Older versions of Firefox show the different colors. Also Firefox 49.0.1 on Windows XP (must be the 32-bit version of Firefox) still does. But Firefox 49.0.1 for Windows Vista and Windows 7 does not show the colors.

Other browsers - Internet Explorer on XP, Google Chrome - also show the style colors.

We standardize on Firefox - we tell our users to use Firefox with our application. If there are no plans to return the styling then we will have to try and replace our <select> elements with customized javascript controls, which will be messy. Or move to another brower, which will take a lot of time in testing. Is there any way/setting to return the old behavior and have Firefox again take note of the 'style' attribute for <option> elements in a <select>? Or might there be plans to fix this in a future release? Thanks!

Hi. We have a web application which has a number of <select> elements whose <option> child elements have CSS 'style' attributes to change the background color of some of the options, to make them stand out, like this simple test: <select name="select"> <option value="one">ONE</option> <option value="two" style="background-color: #00FF00;">TWO</option> <option value="three" style="color: #FF0000;">THREE</option> <option value="four" style="color: #FF0000; background-color: #00FF00;">FOUR</option> </select> This works with older version of Firefox but our users have discovered that the latest version, 49.0.1, ignores the styles for the <option> elements; in the example above all of the lines in the dropdown list for the <select> element have the same default background and color. Older versions of Firefox show the different colors. Also Firefox 49.0.1 on Windows XP (must be the 32-bit version of Firefox) still does. But Firefox 49.0.1 for Windows Vista and Windows 7 does not show the colors. Other browsers - Internet Explorer on XP, Google Chrome - also show the style colors. We standardize on Firefox - we tell our users to use Firefox with our application. If there are no plans to return the styling then we will have to try and replace our <select> elements with customized javascript controls, which will be messy. Or move to another brower, which will take a lot of time in testing. Is there any way/setting to return the old behavior and have Firefox again take note of the 'style' attribute for <option> elements in a <select>? Or might there be plans to fix this in a future release? Thanks!

Ausgewählte Lösung

hi, i think you are seeing an unintentional byporduct of the firefox multiprocess architecture landing on release - this issue is tracked in bug 910022...

Diese Antwort im Kontext lesen 👍 8

Alle Antworten (1)

more options

Ausgewählte Lösung

hi, i think you are seeing an unintentional byporduct of the firefox multiprocess architecture landing on release - this issue is tracked in bug 910022...