I want to use Firefox on my phone, but it's UI is just so confusing - specifically the tab switching flow. When you try to switch tabs, the whole screen is replaced, the typically white background is replaced with a dark background, and the tabs are shown as tiny rectangles. And a very fast animation which makes my head spin. Why don't they just copy the tab switching from mobile Chrome?
They also have a new version of mobile Firefox, which will replace the current one at some point in the future. It's called Firefox Preview. I tried it, tab switching is acceptable, but now they moved the URL bar to the bottom of the screen. Why????? So I've uninstalled it and I'm back to Chrome.
Nobody is going to switch from Chrome to Firefox if the UI is radically different.
I personally like the url bar at the bottom of the screen because its easier to reach. I can understand how this being configurable would be important though.
your motivation to switch to Firefox was based on your willingness to support them over Chrome. The other poster is saying maybe you switched to Firefox from Chrome (presumably, you don't say if you were primarily Chrome prior) due to a preference for supporting Mozilla over Google, but how many users are going to be motivated by that to move the needle?
If you were using Chrome before, Mozilla was around before and their motivations were the same: why did you switch to Chrome in the first place? I'd imagine the motivations there are the ones that are most common (after all, Google ended up eating Firefox's and IE's lunch somehow).
> but how many users are going to be motivated by that to move the needle
1 is enough to disprove "Nobody is going to switch from Chrome to Firefox if the UI is radically different" which was my point. zazaraka is projecting their displeasure on a lot of people.
HN is a community. Users needn't use their real name, but do need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
Frankly I would, and do. I use mobile Firefox for its features like adblocking extensions and reader mode but it's always a less pleasant experience than mobile Chrome because it's less snappy and intuitive.
I switched back almost 10 years ago (because Google creeps me out), and the UI differences made it much harder.
I ended up tweaking firefox with extensions to make it look and behave like Chrome as much as possible, then gradually turned it back to the default UI. It made the switch far more pleasant.
>Nobody is going to switch from Chrome to Firefox if the UI is radically different.
I've actually had a lot of success getting non-techie Android users I know to switch to Firefox when they found out that it has proper adblocking available via Ublock Origin. They're usually quite willing to learn a new UI if it means that they no longer have to deal with advertising infestations.
> but now they moved the URL bar to the bottom of the screen. Why?????
Because on a phone, your thumbs are already down there. No need to stretch to reach the URL bar. I can see users switching to Firefox because of that convenience.
If the browser is going to allow scrolljacking, then I understand the case for it being implemented in the browser's CSS engine. But on so many sites it's a usability issue because space, pgup/pgdn, arrow keys (not to mention Vimium navigation) do not behave predictably.
I am glad Mozilla took their time, because their implementation is better than the one in Chrome. If I open https://codepen.io/rachelandrew/pen/vwMyMr in Chrome and use the scrollbar arrow buttons to scroll up from the second section, it reverts back to the original position...
I viewed the code pen example on my phone, and the bottom of the sections are cut off in each of the snapped positions. So, even the canonical example is making a ton of content inaccessible to people with minor motor control (that allow them to swipe and tap, but not keep their finger in a one pixel radius for extended periods of time).
Such issues tend to crop up later in life, precisely when you need to start cranking the font size up (and therefore get outside of the configurations checked during usability testing), so this is not only hitting a big percentage of the population, it will eventually hit a sizable fraction of the currently-healthy people reading this comment.
Which circle of Dante’s guide to web development in the inferno are we in again? I’m having trouble keeping track.
(the context here is scroll behavior, not markers)
I too tried their codepens and my immediate reaction was "I hope nobody ever does this."
This definitely feels like one of those Ian Malcolm moments.
"Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should."
Having the position jump away from where I just put it feels extremely hostile.
> The update in Firefox 68 brings the Firefox implementation in line with Scroll Snap as implemented in Chrome and Safari
While "and Safari" is a less-relevant detail here, the general point is: where there is a monopoly, minority browsers will often need to implement user-hostile features in order to remain relevant/up-to-date/compatible.
Web devs today don't test in Firefox, they test in Chrome. They might have a webdriver/saucelabs/etc. setup with Firefox/IE/Edge thrown in but in terms of day-to-day these are afterthoughts.
What we do at my work is assign each developer a browser. I only use Firefox. Another coworker only uses Chrome. Etc. This way we will hopefully find any major browser issues before they get to QA.
> In addition, it removes the old properties which were part of the earlier Scroll Snap Points Specification.
The earlier API was based on a working draft spec and has been available since 2015 in Firefox (Chrome only brought it out without a flag in 2018), so this isn't a recent development.
I only test in Firefox, because FF is my browser of choice. Everyone else in the office only tests on Chrome because that is their browser of choice. We all know it is wrong, but cross browser compatibility makes it so much easier to forget that there are subtle differences.
Fun fact, we recently found a performance issue on one of our products which I was completely unaware of because it didn't affect. Even now, we cannot get Chrome to match FF's performance especially (of all things) for Google maps. Just goes to show that basic assumptions that Chrome is faster than Firefox are not 100% accurate. Like most things, it depends.
The CodePen is not great on mobile, but that has everything to do with the CodePen mobile UI and nothing to do with CSS scroll snapping. If anything scroll snapping helps those with poor motor skills as it requires less precision in movement... because it snaps.
No, it's pretty bad on desktop too. If I try to scroll a little bit to read the bottom of the first section (which doesn't quite fit in the 300px height), I get snapped to the second section, with no way of reading the last part of the first section without "maintaining" the scroll by click+dragging the scroll bar without releasing it. It's a pretty bad experience overall.
Removing the `mandatory` value from the attribute makes it a little better (in that the snapping is more a suggestion but you're still able to at least scroll such that all content is accessible), but it's still frustrating that the scroll position is hijacked.
> but not keep their finger in a one pixel radius for extended periods of time
I know you're exaggerating some, but this isn't even close to what I'm seeing: You can drag the entire content area to scroll, not just the scrollbar, and you can drag it past its container to keep scrolling. This is normal for scrolling on mobile, and the snap behavior doesn't affect it.
I do agree that the snap behavior is annoying, it's just nowhere near as bad as you describe...
Well there is one for the first: `text-align: center;`.
But things can quickly get very complicated. This all needs to be done in the context of a ton of other CSS rules that could alter layout. And by the way, what do you mean by "vertically centered"? Using the font's baseline? Text top? Bottom? How are we dealing with text overflow if there isn't enough room in your rectangular element?
Pretty useless features. Don't you think that HTML is getting too complicated? This often happens with open source projects, when everyone starts adding features for themselves and the program ends up as a monster that nobody can maintain (see: openvpn, x11vnc and so on).
But on the scale of uselessness this cannot be even compared with dark mode support. Never needed it.
Scroll snap is a useful feature. The way you can tell that it's useful is because a ton of sites are already doing it, but in a manual, hacky way with JavaScript. This works better and uses less code and CPU. A win all round.
> Scroll snap is a useful feature. The way you can tell that it's useful is because a ton of sites are already doing it, but in a manual, hacky way with JavaScript. This works better and uses less code and CPU. A win all round.
Useful in the same way that popup windows are. Developers certainly liked those - they were such a useful tool to annoy users with! And now "real" popup windows are blocked and developers create them the hacky way with JavaScript. The circle of life.
That's a bit of an odd comparison to make. Scrollsnapping is a useful feature in many scenarios and as the previous comment mentioned the current way of doing it is hacky.
Popups are an entirely different thing but there are legitimate uses for these too. There was never any work around for popups, it's a simple one line of code, you just need to make sure its opened in a trusted event such as a real user click to ensure the user actually wanted the pop up to show.
What a silly comparison. Are you suggesting users find swipeable photo galleries as irritating as popup windows? Because they really don't. If they did then the photos app in both major mobile OSes would be infuriating.
44 comments
[ 3.0 ms ] story [ 31.8 ms ] threadThey also have a new version of mobile Firefox, which will replace the current one at some point in the future. It's called Firefox Preview. I tried it, tab switching is acceptable, but now they moved the URL bar to the bottom of the screen. Why????? So I've uninstalled it and I'm back to Chrome.
Nobody is going to switch from Chrome to Firefox if the UI is radically different.
https://github.com/mozilla-mobile/fenix/issues/3651
I did. I care a lot more about supporting Mozilla than I care about UI though
If you were using Chrome before, Mozilla was around before and their motivations were the same: why did you switch to Chrome in the first place? I'd imagine the motivations there are the ones that are most common (after all, Google ended up eating Firefox's and IE's lunch somehow).
> but how many users are going to be motivated by that to move the needle
1 is enough to disprove "Nobody is going to switch from Chrome to Firefox if the UI is radically different" which was my point. zazaraka is projecting their displeasure on a lot of people.
HN is a community. Users needn't use their real name, but do need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
You could easily make the argument that no one is going to switch from Chrome if Firefox is very similar too because there'd be no good reason to.
Guessing what users will do is a waste of time. You have to do experiments and actually measure it.
I switched back almost 10 years ago (because Google creeps me out), and the UI differences made it much harder.
I ended up tweaking firefox with extensions to make it look and behave like Chrome as much as possible, then gradually turned it back to the default UI. It made the switch far more pleasant.
I've actually had a lot of success getting non-techie Android users I know to switch to Firefox when they found out that it has proper adblocking available via Ublock Origin. They're usually quite willing to learn a new UI if it means that they no longer have to deal with advertising infestations.
Because on a phone, your thumbs are already down there. No need to stretch to reach the URL bar. I can see users switching to Firefox because of that convenience.
Takes a bit of hoop jumping though.
Such issues tend to crop up later in life, precisely when you need to start cranking the font size up (and therefore get outside of the configurations checked during usability testing), so this is not only hitting a big percentage of the population, it will eventually hit a sizable fraction of the currently-healthy people reading this comment.
Which circle of Dante’s guide to web development in the inferno are we in again? I’m having trouble keeping track.
I too tried their codepens and my immediate reaction was "I hope nobody ever does this."
This definitely feels like one of those Ian Malcolm moments. "Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should."
Having the position jump away from where I just put it feels extremely hostile.
> The update in Firefox 68 brings the Firefox implementation in line with Scroll Snap as implemented in Chrome and Safari
While "and Safari" is a less-relevant detail here, the general point is: where there is a monopoly, minority browsers will often need to implement user-hostile features in order to remain relevant/up-to-date/compatible.
Web devs today don't test in Firefox, they test in Chrome. They might have a webdriver/saucelabs/etc. setup with Firefox/IE/Edge thrown in but in terms of day-to-day these are afterthoughts.
> In addition, it removes the old properties which were part of the earlier Scroll Snap Points Specification.
The earlier API was based on a working draft spec and has been available since 2015 in Firefox (Chrome only brought it out without a flag in 2018), so this isn't a recent development.
https://caniuse.com/#search=scroll%20snap
It's kind of an aside, but is that true? I only do small scale solo dev but I test in like a dozen UA as the bare minimum I can get away with.
Presumably you're being slightly hyperbolic and saying that devs who are under major constraints will target Chrome?
Fun fact, we recently found a performance issue on one of our products which I was completely unaware of because it didn't affect. Even now, we cannot get Chrome to match FF's performance especially (of all things) for Google maps. Just goes to show that basic assumptions that Chrome is faster than Firefox are not 100% accurate. Like most things, it depends.
Removing the `mandatory` value from the attribute makes it a little better (in that the snapping is more a suggestion but you're still able to at least scroll such that all content is accessible), but it's still frustrating that the scroll position is hijacked.
> but not keep their finger in a one pixel radius for extended periods of time
I know you're exaggerating some, but this isn't even close to what I'm seeing: You can drag the entire content area to scroll, not just the scrollbar, and you can drag it past its container to keep scrolling. This is normal for scrolling on mobile, and the snap behavior doesn't affect it.
I do agree that the snap behavior is annoying, it's just nowhere near as bad as you describe...
"horizontally center this text inside its rectangular element"
And another one for:
"vertically center this text inside its rectangular element"
The issue of centering wrapped multiline text has been solved in many UI libraries.
justify-content: safe center; align-items: safe center;
On the parent:
On the element to be centered:But things can quickly get very complicated. This all needs to be done in the context of a ton of other CSS rules that could alter layout. And by the way, what do you mean by "vertically centered"? Using the font's baseline? Text top? Bottom? How are we dealing with text overflow if there isn't enough room in your rectangular element?
But on the scale of uselessness this cannot be even compared with dark mode support. Never needed it.
Useful in the same way that popup windows are. Developers certainly liked those - they were such a useful tool to annoy users with! And now "real" popup windows are blocked and developers create them the hacky way with JavaScript. The circle of life.
Popups are an entirely different thing but there are legitimate uses for these too. There was never any work around for popups, it's a simple one line of code, you just need to make sure its opened in a trusted event such as a real user click to ensure the user actually wanted the pop up to show.
If you don't need [insert-shiny-feature-here], don't use it.
In terms of this update...
::marker support is very useful and something we've been asking to have for years.
Scroll snapping is also very useful as most sites implement it in very hacky JS.