Mozilla Destek’te Ara

Destek dolandırıcılığından kaçının. Mozilla sizden asla bir telefon numarasını aramanızı, mesaj göndermenizi veya kişisel bilgilerinizi paylaşmanızı istemez. Şüpheli durumları “Kötüye kullanım bildir” seçeneğini kullanarak bildirebilirsiniz.

Daha Fazlasını Öğren

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

  • 1 yanıt
  • 79 kişi bu sorunu yaşıyor
  • 269 gösterim
  • Son yanıtı yazan: 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!

Seçilen çözüm

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

Bu yanıtı konu içinde okuyun 👍 8

Tüm Yanıtlar (1)

more options

Seçilen çözüm

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