I am reopening cause some people are still having issues.
- remove, browser_update_user_agents we don’t want to feature detect with that anymore.
optimise_traffic_on_modern_mobile_browsers(default true) - if users have a supported mobile user browser (modern chrome / safari) we will optimise transport by avoiding shipping the HTML payload.
- Some basic design work on crawler / html view - (improve styling / padding / margins) and so on by @Designers
@Falco how does this sound?
I will see if I can get to this next week, if not will get it assigned internally the week after.
Be careful when testing on Meta, the tableless design experiment here regressed our crawler view quite a bit.
People on early iOS 12 still fail to boot the app because they lack window.globalThis. You can easily repro that on Browserstack. We need to ship the HTML no-script content for those folks. Your plan step 1 will solve that.
Looks amazing, I also left a comment on a PR. Google does mobile first indexing, so we have to test a mobile resolution carefully, cause that is the general consumer of this view.
IIRC this was essential for some browsers (IE < 10?) because it’s impossible to access
Note that there are two fallback ‘modes’ at the moment:
Serve the crawler view. No JS required. This is gated on
Serve the full app, feature detect, and fallback by moving
<body>. This is not based on user agent.
The problem here is that (2) is not working on mobile, because the server isn’t rendering any
<noscript> content. We need to fix that, without breaking (1) for mega-old browsers.
That is correct. Old IE does not allow reading the contents of
I suggest we update the steps to:
How were you thinking of implementing (2) @sam? Maintain a list of ‘modern’ user agents matchers in core? And then we bump them up as part of the stable release cycle?
Yes something like that, to be honest this week is not looking too promising for me, not managing to carve out much programming time
Likely I will pass this work on, your amended action plan sounds great
Please excuse my lack of knowledge here…I tried looking around for the answer but couldn’t find anything…
With a pull request like the above, how long before it’s “merged”?
Meaning I’ll go into my discourse admin panel, it will prompt for an update, and the above will be implemented.
Looks like there are some comments to resolve, but it’ll probably be merged in the next 24hrs. We’ll update here when it is. Then, assuming you’re on tests-passed, you’ll be able to visit
/admin/upgrade on your forum and pull in the change.
Not sure what that is but I think I am
Awesome and thank you @david
Interestingly in a iphone 5 on browser stack, proxying to local, I am seeing a white page even after I fiddle with
include_crawler_content? and set it to true.
There may be some stuff that ember cli is doing on local to break this testing.
It certainly looks broken as designed on iOS 7 in production. (no content cause we don’t ship it)
Going to be reasonably tricky to test the fix, but I guess I can fake some things on local.
Thinking out loud about
What is a modern Mobile browser?
- iOS 14+
- Android + Chrome 88+
- Android + Firefox 85+
This should catch a good 95% of all our mobile traffic anyway so the payload saving is significant and risk extremely low.
@Falco am I forgetting any browsers? Firefox is like a drop in the ocean for Android, vast majority are simply on Chrome it appears.
3 posts were split to a new topic: Support for ‘Adblock Browser’
This seems to have broken again yesterday. I’m getting a white page with no error message via my browser and the app on the same two out of three forums
On meta (this site) as well?
Yikes, we will get this sorted quickly, thanks for raising it.
This was an unintentional side effect of removing IE11 from our JS build targets. Should be fixed by:
Will get this merged and deployed ASAP