Page MenuHomePhabricator

Browsers that do not support async JS do not degrade gracefully
Closed, InvalidPublic

Description

What

The UC Mini browser which is highly popular in certain parts of the world does not appear to support async JS loading.

When the async attribute is present the JS inside it appears to be ignored. I've verified that this happens for:

<script async>
<script async="true">

as well as the approach we take to enabling:

<script async="">

Yet we add inline JS that changes the body class from client-nojs to client-js: https://github.com/wikimedia/mediawiki/blob/master/includes/resourceloader/ResourceLoaderClientHtml.php#L264

As a result, this is not as resilient as it could be: the state of the page is left in a limbo state where UIs that require JavaScript are shown but the JS is never loaded.

The user agent for UC Mini is rather unhelpfully "Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv: 1.2.3.4) Gecko/"

Related user facing problems (useful for QA/Signoff)

In the mobile site search is inaccessible for UC mini browsers (see T136803)

Event Timeline

@Jdlrobson @ovasileva It appears this task is the result of the spike in the sprint. Given the stuffed state of the sprint right now, I'm not sure this resultant task was meant to be in the current sprint. Backlog, or Unplanned-Sprint-Work ?

In theory we should be able to feature detect this e.g.

if ( "async" in document.createElement("script") ) {   document.documentElement.className =   document.documentElement.className'
                        . '.replace( /(^|\s)client-nojs(\s|$)/, "$1client-js$2" ); 
}'
Jdlrobson updated the task description. (Show Details)

... but it seems that is true for the UC Mini browser o_O
I've written this proof of concept patch:
https://gerrit.wikimedia.org/r/312935
which makes search work again on the UC mini browser and any browsers that do no support async attribute, but the solution is icky and I'm sure we can do better.

@MBinder_WMF yes it is the result of the spike. I don't consider the spike done however until we have some consensus on the approach to do that so it should be in the sprint either in the needs analysis or the tracking column. If it's not in the "Todo" column surely there's no problem with it hanging out here?

yes it is the result of the spike.

Thanks for clarifying

I don't consider the spike done however until we have some consensus on the approach to do that so it should be in the sprint either in the needs analysis or the tracking column.

I'm not sure this jives. If there isn't consensus on the approach, the task isn't ready, so it probably shouldn't be in the sprint. (Also, there is no longer a Tracking column, unless you mean the backlog).

If it's not in the "Todo" column surely there's no problem with it hanging out here?

I hear that logic (that it's not harmful in Needs Analysis), but it's not my call, and the team has previously indicated that if there is work in the sprint it should be work that the team has committed to, or else UBN. Add that to the fact that there was a fair amount of work already in the sprint that had to be removed (and a case to be made for even more removal), I'm under the impression that this work isn't a higher priority. That said, it's @ovasileva 's call. :)

@MBinder_WMF and @ovasileva would you mind if we continue this process orientated conversation on email rather than spamming everyone?

@Krinkle and @Peter I'd be interested in your thoughts on how to solve this since it touches ResourceLoader (scroll up to read my comments/analysis so far).

@Jdlrobson

would you mind if we continue this process orientated conversation on email rather than spamming everyone?

Sounds fine, can do so in retro, as well. The task still needs addressing though. :)

Change 312935 had a related patch set uploaded (by Jdlrobson):
POC: UCMini browser should behave correctly as a NORLQ client

https://gerrit.wikimedia.org/r/312935

@Jdlrobson, @MBinder_WMF - I'm confused why we've pulled this in as well, given that the spike is not yet resolved. Let's bring it up during standup so the rest of the team can weigh in as well.

@Krinkle any ideas of how we might more gracefully support the UC Mini browser given these constraints?

@ovasileva This task is the outcome of the spike which is resolved now. Needs appropiate grooming.

sounds like we should bump it to the next sprint - let's discuss during prioritization

Just curious, did you get the UA in the example when you tested @Jdlrobson ?

When I checked before it was possible see that it was mini through the user agent: https://wikitech.wikimedia.org/wiki/ProxyBrowsers#User_Agent_2
or maybe it's still different depending on os.

The official docs: http://www.ucweb.com/download/UCBrowser_User_Agent_en.pdf

Are we really sure that the async doesn't load at all? It seems like if that's the case, UC mini should have problem across the board on many sites?

I've made a test:
https://www.peterhedenskog.com/orange.html

If the async script isn't loaded the page background should be orange. If it's loaded, it should be white with the message "Loaded by async".

When I tried with UC Mini on my android I get the white background, so the script is loaded and executed (Speed mode enabled).

@Peter let me do what I should have done beforehand and give you a minimum test case. I suspect there might be more conditions that lead to this problem. {hits head}

This doesn't seem to be to do with async like I first thought. I've got a new lead. I'll open a new task when I've got a little further.

Change 312935 abandoned by Krinkle:
POC: UCMini browser should behave correctly as a NORLQ client

Reason:
Obsolete per T146699. New task at T147369 and see I60b40bcb8c684.

https://gerrit.wikimedia.org/r/312935