4 ms·
For instance, my bank (Lloyds) has a login screen where you have to select letters from three long drop down lists containing all letters and numbers. With Saf
by fauigerzigerk 7y ago
For instance, my bank (Lloyds) has a login screen where you have to select letters from three long drop down lists containing all letters and numbers.
With Safari or Chrome, I can select the dropdown (by clicking it or navigating there using the keyboard) and then enter the letter or number on the keyboard.
With Firefox, I have to click on the dropdown, scroll down looking for the right letter/number and then select it with the mouse. It takes at least 10 times as long as with other browsers. So I'm not using Firefox for that site.
Of all the interactive sites I use regularly about 10% have some sort of bug when visited with Firefox. And this is getting worse at an alarming rate.
I think many mainstream sites not created by actual tech companies have simply stopped testing with Firefox.
(I don't use ad blockers, just browser default settings)
- realusername 7y agoThis used to work on Firefox as well with Lloyds, I don't know what changed but it stopped working about a year ago.
- fauigerzigerk 7y agoI think it's some sort of anti-keylogger pattern that Lloyds are using. The select options all look like this: <option value="&nbsp;c"> c</option> I suspect the nbsp is what blocks the usual keyboard behaviour on Firefox but not on Chrome. This is quite strange, because it could mean that the anti-keylogger feature only works as intended with Firefox but not with Chrome.
- realusername 7y agoInteresting, that could be something not too complicated to change on Firefox, I'll try to contribute when I'll have a bit more time. At least that's the first time I see something I could realistically improve.
- fauigerzigerk 7y agoI'm not sure whether Firefox should actually be changed. It looks like Firefox may be conforming to the standard and Lloyds devs may have intended to use that standardised behaviour to thwart keyloggers. 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#the-option-element 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.
- Izkata 7y ago> 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? 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).
- JadoJodo 7y agoAs inconvenient as powering through this bug might be, switching to Chrome to use this site just reinforces their choice. Perhaps emailing them to report the issue might also be beneficial for all?
- isostatic 7y agoAs it’s a bank I suspect their devs have to use IE6 and have recently upgraded to IE8 and thus change in behaviour.
- isostatic 7y agoI changed bank - I had an account with a bank (RBS?) in the late 90s / early 00s, couldn't access it from linux, yet I could access HSBC, so RBS lost my custom. My current bank (Smile) works in Firefox on linux, so that's fine. If it didn't, they'll be losing my custom.
- jstummbillig 7y agoSometimes I am astonished by the life other people apparently lead. For example when they'd invest the energy to switch their bank (and all that is attached to that) over using a different browser to access a singular website. I do not understand. It boggles my mind, in the most curious way.
- Izkata 7y agoSometimes the way it fails gives the impression of a less-than-comfortable level of competence with technology. I also almost switched banks when my first was acquired by another, its webui was so much worse.
- fauigerzigerk 7y agoPlease see the sibling thread (to your comment) for why I'm not going to do that. This "glitch" is probably intentional. Also, I have actually tried to communicate with that bank about a far more important issue. It was frustrating and pointless, starting with the fact that they don't have a customer support email address.