Only they seem to have forgotten to test whether it actually does block keyloggers, and it only does so in Firefox.
So my grand example for a website not working well in Firefox may be just the opposite - Firefox saving my money from getting siphoned off by thiefs. Very bad choice of example on my part! :-)
Here's what the HTML 5 spec says on the <option> element's text content:
The text IDL attribute, on getting, must return the result of stripping and collapsing ASCII whitespace from the concatenation of data of all the Text node descendants of the option element, in tree order, excluding any that are descendants of descendants of the option element that are themselves script or SVG script elements.
https://html.spec.whatwg.org/multipage/form-elements.html#th...
nbsp is not ASCII whitespace and so it should not be stripped. I can't seem to find anything specific on the autocomplete behaviour in this case, but arguably autocomplete should use the text content without further normalisation. Perhaps this is where Chrome and Safari devs would disagree.
In any event, this raises a bigger question. What if a site is actually broken in Firefox, but it's not Firefox's fault? Should Firefox then be changed to non-conforming behaviour, aping any Chrome bugs? That would put a huge question mark on all the work they put into making their own rendering engine instead of just using Blink.
I can remember one case of such a thing happening before: css box-sizing.
Before the attribute existed, the spec said content-box was correct, and all browsers except IE implemented it that way. IE implemented border-box, going against spec, but it turned out to make so much more sense it was eventually added to CSS, and nowadays is the recommended way to go (but still not the default value).
