mozilla / bedrock

Making mozilla.org awesome, one pebble at a time
https://www.mozilla.org
Mozilla Public License 2.0
1.18k stars 919 forks source link

Moz.org incorrectly identifies Chromebooks as desktop Linux (ARM) #8006

Open alexgibson opened 5 years ago

alexgibson commented 5 years ago

Description

As reported by @MKS-moz, if you visit mozilla.org on a Chromebook you see a "Please follow these instructions to download Firefox" message, which links to https://support.mozilla.org/kb/install-firefox-linux

Steps to reproduce

Visit any mozorg page with a download button on it, using a Chromebook.

Expected result

There should be a message that explains Firefox is unsupported on Chromebooks.

Actual result

Instead of a download button, there is a link to instructions for installing Firefox on Linux.

Environment

Chromebook

ejregithub commented 4 years ago

0.06% of chromebook users on www

hoosteeno commented 4 years ago

When I use a popular UA spoofing addon to send a Chromium OS user agent, I don't get the same message. Instead, I get this:

image

I'd like to try to replicate the issue. @alexgibson, how did you replicate it? Here's the UA I'm sending:

Mozilla/5.0 (X11; CrOS x86_64 12239.19.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.38 Safari/537.36

Errolyn commented 4 years ago

I talked with a couple people with chromebooks and got screenshots of what they see:

On the "https://mozilla.org/en-US/ " page they see: downloadpage

Then after clicking on the download button they get the thank you page which auto downloads the linux package: downloadingpage

This sounds like a bit of a different experience from the original reported and what Alex produced with the UA string.

I have found when testing other things that the UA add-on you linked doesn't always replicate the experience correctly for our users so I think this might be another case of that.

alexgibson commented 4 years ago

@hoosteeno @Errolyn looking into our platform detection code, I think the key here is a combination of navigator.userAgent, navigator.platform, and also architecture type.

Some Chromebooks are built using arm processors, so whilst certain models may get the Linux download (which is incorrect already), others will see a message linking to SUMO (like in the original report). Mozorg is assuming these users are running desktop Linux, in some form or another.

One of the longer term things I'd like us to think about (on the technical roadmap) is simplifying some of our platform detection code. A lot of it is built around edge cases. Some of it may be old enough now we can simplify it.

alexgibson commented 4 years ago

Looks like we can detect ChromeOS with something like the following:

var chromeOS = /(CrOS)/.test(navigator.userAgent);

I'm loathsome to add more UA detection to our already complicated platform logic, but this may be the best thing we can do short-term, until we can work on reducing our reliance on these types of checks.

The bigger question to ask is, what should Chromebook users see? The easiest path to at least some sort of understandable UX is to display our "Your system may not meet the requirements for Firefox, but you can try one of these versions:" message.

Does this sound ok, @hoosteeno ?

hoosteeno commented 4 years ago

@alexgibson It sounds like that's the best choice to me. I'd like to ask PMMs for a suggestion here. Will come back.

hoosteeno commented 4 years ago

@alexgibson the product team is evaluating this. Let's hold.

ejregithub commented 4 years ago

Blocking based on feedback required from Product (flatpack as a possible means to ID browser)

hoosteeno commented 4 years ago

We are working on a SUMO page that helps ChromeOS users install Firefox using a Linux installer packaged as a Flatpak. It's drafted here: https://docs.google.com/document/d/1k8AVJgxiN_Vu-PZ64oUUsLni_qelrpYV9Kko-n7A2YM/edit

That means, for the purposes of this bug, we should expect to redirect ChromeOS users to SUMO when they try to download. Does that seem like a reasonable path, @justinkropp @cgonz0 ? How would you design this interaction -- would you give them a modal with a brief explanation before redirecting them?

alexgibson commented 4 years ago

We should consider SEO here as well - placing a string like this in every page of the website is not without a cost/impact for crawlers. Perhaps we could hide that information somewhere that is out of their reach, or perhaps we could place it on /thanks/

alexgibson commented 4 years ago

/cc @rraue

rraue commented 4 years ago

Redirecting based on setup sounds extremely dangerous, as crawlers come with a various set of user agents and virtual setups and it would be a enormous risk of a search crawler being identified on /new as a chromeOS and getting repeatedly redirected. That could deindex any page with such a redirect!

A clear message is a better way. It would be good if we could have that message at the end of the DOM and wrap it in a data-nosnippet.

Aditional question: isn't it possible to install android apps on ChromeOS? Wouldnt that be an easier solution?

And another one, we do not have much ChromeOS users on www, but ballpark 100k monthly sessions might be a good way to build a /firefox/ChromeOS/ page like /mac if we have a doable way to get firefox on ChromeOS. And even if its just a button getting you to sumo with instructions.

alexgibson commented 4 years ago

Oh, I totally missed the part above that said redirect. I totally agree with Raphael here, the last thing we should do here is redirect people away from our site based on user agent.

Either a message in the page, or at a singular destination such as /thanks is the appropriate solution here imho (this message could link to sumo or a /chromeos page). This may be what Justin already means, but it’s a good call out to be clear on this.

alexgibson commented 4 years ago

Also: let’s design this solution with performance in mind if possible. It’s not really optimal to ship all the code required for a modal on every page of the site, for such a small % of visitors who would see it.

rraue commented 4 years ago

@alexgibson I think we should push for your solution getting all error messaging and such to /thanks freeing the download button from its ballast.

mkaply commented 4 years ago

The SUMO article is live.

https://support.mozilla.org/kb/run-firefox-chromeos

ejregithub commented 4 years ago

Needs design treatment (re-usable, extensible component for notifications) for messaging identified users (on /thanks) that informs users where they can get Firefox for Chrome OS

ejregithub commented 4 years ago

@justinkropp - ping

alexgibson commented 4 years ago

I filed a separate issue for creating a design treatment to display platform messaging on /thanks/, as it's a dependency for several other issues as well: https://github.com/mozilla/bedrock/issues/9137

alexgibson commented 4 years ago

@hoosteeno is there still appetite to try and address this issue?

The messaging on /thanks work is now in place, and we could incorporate a similar design treatment as the Window 10 warning perhaps.

janbrasna commented 7 months ago

FYI there's no reason to redirect people away to sumo, there's a page now https://www.mozilla.org/firefox/browsers/chromebook/ describing the two ways (Play Store and Flatpak) with the appropriate outbound links, so this could be a good target where to send people hitting "download" — if there's a realiable way to detect ChromeOS ofc.