Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Wannan tattunawa ta zama daɗaɗɗiya. Yi sabuwar tambaya idan ka na bukatar taimako.

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

  • 1 amsa
  • 79 sa na da wannan matsala
  • 20 views
  • Amsa ta ƙarshe daga 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!

Mafitar da aka zaɓa

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

Karanta wannan amsa a matsayinta 👍 8

All Replies (1)

more options

Zaɓi Mafita

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