Sykje yn Support

Mij stipescams. Wy sille jo nea freegje in telefoannûmer te beljen, der in sms nei ta te stjoeren of persoanlike gegevens te dielen. Meld fertochte aktiviteit mei de opsje ‘Misbrûk melde’.

Mear ynfo

Dizze konversaasje is argivearre. Stel in nije fraach as jo help nedich hawwe.

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

  • 1 antwurd
  • 79 hawwe dit probleem
  • 269 werjeftes
  • Lêste antwurd fan 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!

Keazen oplossing

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

Dit antwurd yn kontekst lêze 👍 8

Alle antwurden (1)

more options

Keazen oplossing

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