Differences between Firefox and other browsers displaying DOM SELECT object

VERIFIED DUPLICATE of bug 40545

Status

()

defect
--
major
VERIFIED DUPLICATE of bug 40545
4 years ago
4 years ago

People

(Reporter: tssoon, Unassigned)

Tracking

({testcase})

38 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-ie][parity-chrome][parity-opera][parity-safari], )

Attachments

(1 attachment)

Posted image bugreport.jpg
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36

Steps to reproduce:

Have to provide the links of the HTML and Javascript files because this bug report interface allows only one attachment. Please examine the files and download them for local execution using different browsers to compare the outputs. 

The index.html file is:
https://drive.google.com/file/d/0B9Wrdc6KAGZeOTZNb1J6MXg1TTQ/view?usp=sharing
The Javascript file is:
https://drive.google.com/file/d/0B9Wrdc6KAGZebkZIZTRWdk4taVk/view?usp=sharing

Or please get access to the files at the URL below using different browsers to compare the outputs:
https://cd1119ad39391502030bdc3fc17396d5db82f71b-www.googledrive.com/host/0B9Wrdc6KAGZefkExRjVrVTNQYlVXZTN5VzhtX0dUakRDekhLV2daUHU5NTE2WEV3NDVjU0E/

Safari, Chrome and IE11 display correct SELECT lists in the html files, while Firefox (v.38.0.5) displays only the SELECT lists without visible items of selection.


Actual results:

Looked through the execution of the Javascript via Firefox Debugger and didn't see any issues. All of the selection lists are populated with correction sets of Options. 

In fact, Firefox can capture correct user selected values from the selection lists which is shown below the <button> Today. However, the items in the selection lists are invisible!

If this Firefox display behavior is not considered as a bug, please provide the correct Javascript codes or workarounds to display the items in the selection lists.  


Expected results:

All browsers should display consistent initial and subsequent SELECT lists.
Also downloaded and checked Opera, it shows consistent behaviors as Chrome, IE11, and ....
Component: Untriaged → DOM: Core & HTML
Keywords: testcase
Product: Firefox → Core
Whiteboard: [parity-ie][parity-chrome][parity-opera][parity-safari]
This is because the @label attribute doesn't work for <option> elements.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: option-label
(In reply to Giovanni Sferro [:agi] from comment #2)
> This is because the @label attribute doesn't work for <option> elements.
> 
> *** This bug has been marked as a duplicate of bug 40545 ***

Thanks for your reply. Seems this is a bug and it has a long history. My curious question is why this bug has not been fixed or addressed yet?! Is this the expected behavior of OPTION object, or all other browsers are wrong?
(In reply to Tom Soon from comment #3)

> Thanks for your reply. Seems this is a bug and it has a long history. 

Yes, and it's worth to read bug 40545, e.g. bug 40545 comment 17

> My curious question is why this bug has not been fixed or addressed yet?! 

Unhappily there are a lot of bugs in the engine, and this is much not the oldest. 

> Is this the expected behavior of OPTION object, or all other browsers are wrong?

This behaviour is bug 40545 with status of "NEW".
That means it is not INVALID or WONTFIX. Patches welcome!
(In reply to j.j. from comment #4)
> (In reply to Tom Soon from comment #3)
> 
> > Thanks for your reply. Seems this is a bug and it has a long history. 
> 
> Yes, and it's worth to read bug 40545, e.g. bug 40545 comment 17
> 
> > My curious question is why this bug has not been fixed or addressed yet?! 
> 
> Unhappily there are a lot of bugs in the engine, and this is much not the
> oldest. 
> 
> > Is this the expected behavior of OPTION object, or all other browsers are wrong?
> 
> This behaviour is bug 40545 with status of "NEW".
> That means it is not INVALID or WONTFIX. Patches welcome!


Thanks for your reply J.J. for letting me know the NEW status of 40545 for this bug. Given the far out past date of 40545, just curious how much attention will it call to get this bug addressed. Shouldn't there be a renewed bug report to call attention for fixing this bug again? Seems to me that every time a new report came up, the report was removed due to duplication. No one seems to be interested to take it on and get it done. Even under the pressure that this bug shows the inferiority of Firefox to other browsers. 

I tried the css fix and the result only showing the list but not the selected item in the list. It's a crude fix, still not entirely consistent with the display of other browsers. 

I am new here and don't have the background whether or not this css fix was used as an excuse not to fix the bug in the early years. I must say even it worked, the css approach to fix this bug is totally against the programming principles I follow. 

At this moment, I have to apologize that my only fix is to advise all my clients not to use Firefox for the applications I developed.

Thanks for your reply.
(In reply to Tom Soon from comment #5)
> Given the far out past date of 40545, just curious how much
> attention will it call to get this bug addressed.

This bug gets fixed when someone takes action and does it
(or facebook's startpage was broken due this bug :-)  )
see 1.2 of
 https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

> Shouldn't there be a renewed bug report to call attention for fixing
> this bug again? Seems to me that every time a new report came up,
> the report was removed due to duplication.

That's the process (one bug per issue)

> No one seems to be interested to take it on and get it done.
> Even under the pressure that this bug shows the inferiority of
> Firefox to other browsers.

People might be interested but have other fish to fry. There is no obligation.

> I tried the css fix and the result only showing the list but not the
> selected item in the list. It's a crude fix, still not entirely
> consistent with the display of other browsers.

If you mean the code below, yes, I can confirm it breaks in Chrome at least
  option[label] {
    visibility: hidden;
    width: 0;
  }
  option[label]:before {
    content: attr(label);
    visibility: visible;
    color: red;
  }

> I am new here and don't have the background whether or not this 
> css fix was used as an excuse not to fix the bug in the early years.

No, it was used by an helpful contributor who had the same problem 
as you and shared his solution.

> I must say even it worked, the css approach to fix this bug
> is totally against the programming principles I follow.
> At this moment, I have to apologize that my only fix is to advise
> all my clients not to use Firefox for the applications I developed.

That's unfortunate but a possible solution these days, because due to 
Mozilla's efforts since 16 years there is no monopoly in browser market. 


I see two ugly ways to address the problem:

1. Apply the CSS fix only to Mozilla browsers by browser sniffing:

<script>
        if (navigator.userAgent.match("Gecko/"))
        document.documentElement.className+="bugfix"
</script>
<style>
 .bugfix option[label] {
    color:white /*match to your background-color*/;
    /* you may need "width" or "min-width" here depending on content */
 }
 .bugfix option[label]:before {
    content: attr(label); color:black;
 }
...
</style>
This may or may not break the day the bug gets fixed


2. Use a -moz-pseudo-class

 :-moz-any(option[label]) {
    color:white /*match to your background-color*/;
    /* you may need "width" or "min-width" here depending on content */
 }
 :-moz-any(option[label]):before {
    content: attr(label); color:black;
 }

This will brake the day, when the -moz-prefix for any() is no longer 
supported and the bug is not fixed then.
(In reply to j.j. from comment #6)
> (In reply to Tom Soon from comment #5)
> > Given the far out past date of 40545, just curious how much
> > attention will it call to get this bug addressed.
> 
> This bug gets fixed when someone takes action and does it
> (or facebook's startpage was broken due this bug :-)  )
> see 1.2 of
>  https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> 
> > Shouldn't there be a renewed bug report to call attention for fixing
> > this bug again? Seems to me that every time a new report came up,
> > the report was removed due to duplication.
> 
> That's the process (one bug per issue)
> 
> > No one seems to be interested to take it on and get it done.
> > Even under the pressure that this bug shows the inferiority of
> > Firefox to other browsers.
> 
> People might be interested but have other fish to fry. There is no
> obligation.
> 
> > I tried the css fix and the result only showing the list but not the
> > selected item in the list. It's a crude fix, still not entirely
> > consistent with the display of other browsers.
> 
> If you mean the code below, yes, I can confirm it breaks in Chrome at least
>   option[label] {
>     visibility: hidden;
>     width: 0;
>   }
>   option[label]:before {
>     content: attr(label);
>     visibility: visible;
>     color: red;
>   }
> 
> > I am new here and don't have the background whether or not this 
> > css fix was used as an excuse not to fix the bug in the early years.
> 
> No, it was used by an helpful contributor who had the same problem 
> as you and shared his solution.
> 
> > I must say even it worked, the css approach to fix this bug
> > is totally against the programming principles I follow.
> > At this moment, I have to apologize that my only fix is to advise
> > all my clients not to use Firefox for the applications I developed.
> 
> That's unfortunate but a possible solution these days, because due to 
> Mozilla's efforts since 16 years there is no monopoly in browser market. 
> 
> 
> I see two ugly ways to address the problem:
> 
> 1. Apply the CSS fix only to Mozilla browsers by browser sniffing:
> 
> <script>
>         if (navigator.userAgent.match("Gecko/"))
>         document.documentElement.className+="bugfix"
> </script>
> <style>
>  .bugfix option[label] {
>     color:white /*match to your background-color*/;
>     /* you may need "width" or "min-width" here depending on content */
>  }
>  .bugfix option[label]:before {
>     content: attr(label); color:black;
>  }
> ...
> </style>
> This may or may not break the day the bug gets fixed
> 
> 
> 2. Use a -moz-pseudo-class
> 
>  :-moz-any(option[label]) {
>     color:white /*match to your background-color*/;
>     /* you may need "width" or "min-width" here depending on content */
>  }
>  :-moz-any(option[label]):before {
>     content: attr(label); color:black;
>  }
> 
> This will brake the day, when the -moz-prefix for any() is no longer 
> supported and the bug is not fixed then.

Dear J.J., 

Deeply appreciate your time and efforts to answer my insignificant questions. My sincere thanks again.

Indeed, this is an open community and bug fixes rely on contributions from interested and willing parties. 

Thanks again for your two solutions, I'll test them and see if I can take advantage of your helps in my code.


Best Regards,


Tom Soon
(In reply to j.j. from comment #6)

>  document.documentElement.className+="bugfix"

this should be either

   document.documentElement.className += " bugfix"
or
   document.documentElement.className = "bugfix"
(In reply to j.j. from comment #8)
> (In reply to j.j. from comment #6)
> 
> >  document.documentElement.className+="bugfix"
> 
> this should be either
> 
>    document.documentElement.className += " bugfix"
> or
>    document.documentElement.className = "bugfix"


J.J.  

Thanks a great deal. No problem. Got that. 

The first workaround show similar behaviors as the original CSS fix proposed before with the logic to zoom into only Firefox browsers to execute the CSS fix. This fix does replace the labels with the values and make them visible in the list. However, in the SELECT object, the selected value is still not displayed. The user may lose the immediate feedback after clicking on the selected item in the list. 

With that said, my guess is that the fix of the label attribute for OPTION itself might not be complete. The code of SELECT Object may also require some enhancement to display the selected item from the list correctly. As a deduction, the implementations of all objects uses OPTION will need careful review and perhaps some modifications. 

Really hope someone can take on the bug fixes so we can expect consistent behaviors with all of the rest browsers without such special treatment as you provided. 

Also, I am very curious and puzzled why for 15 years folks here considered bug 215083 is the complete fix of bug 40545 and why so many folks raised the issue but received the same treatment like what I have experienced so far.

As before, my sincere thanks to you.


Best Regards,
As I reported initially, the Javascipt correctly executed and populated both label and value attributes. My believe is after that the Javascript passes OPTION objects to Firefox processing, somehow the label attribute is ignored by Firefox processing. As such, the internal data structure in Firefox for the SELECT object doesn't have appropriate information to display the selected items, even for the selected value, correctly. 

Therefore, my conclusion here is that assigned "resolved" and "duplicated" status on this bug report is definitely not correct. First, Bug 40545 is still open. Second, Perhaps, this bug is a duplicate of those early reports about SELECT object, and all of such bug reports depend on the fix of OPTION object which bug 40545 referenced.
Severity: normal → major
OS: Unspecified → All
Hardware: Unspecified → All
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.