Page MenuHomePhabricator

[Bug] A large amount of our errors are occurring in iOS Safari
Closed, DuplicatePublic

Description

About 50% of our client side errors in Minerva seem to be coming from iOS. Today I spent some time on Browserstack in iOS Safari and was surprised to find quite a few bugs in the console just by exploratory testing, hitting URIS obtained from Hive [1]. It would be great to commit some time to browsing the website via Browserstack and identifying bugs. In this ticket I already record 2 specific bugs I've found (haven't checked if I can replicate them locally).

It would be excellent to focus on this problem, either by running some extensive exploratory testing on iOS or by adding Sentry-like capabilities and targeting specific problems.

[1] select referer, count(*) from webrequest where hour = 23 and day = 22 and month = 1 and year = 2019 and uri_path LIKE '%beacon%' and access_method = 'mobile web' and uri_query LIKE "%WebClientError%" group by referer;

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 23 2019, 1:36 AM
Jdrewniak updated the task description. (Show Details)Jan 23 2019, 7:57 AM
Jdrewniak updated the task description. (Show Details)Jan 23 2019, 8:01 AM

Change 486032 had a related patch set uploaded (by Jdrewniak; owner: Jdrewniak):
[mediawiki/skins/MinervaNeue@master] Fix page-issues overlay error in Safari

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

Jdrewniak updated the task description. (Show Details)Jan 23 2019, 10:06 AM

We can spin out a more specific task for the page issues problem if necessary but i was thinking of this more like an epic since the other issue i saw did not seem to be page issues related

Change 486145 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Explicitly pass in parseHTML

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

Change 486146 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@wmf/1.33.0-wmf.13] Explicitly pass in parseHTML

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

Change 486147 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@wmf/1.33.0-wmf.14] Explicitly pass in parseHTML

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

Change 486145 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Explicitly pass in parseHTML

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

Change 486032 abandoned by Jdrewniak:
Fix page-issues overlay error in Safari

Reason:
Abandoned in favour of https://gerrit.wikimedia.org/r/#/c/486145/

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

Change 486146 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@wmf/1.33.0-wmf.13] Explicitly pass in parseHTML

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

Change 486147 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@wmf/1.33.0-wmf.14] Explicitly pass in parseHTML

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

Mentioned in SAL (#wikimedia-operations) [2019-01-24T00:34:31Z] <thcipriani@deploy1001> Synchronized php-1.33.0-wmf.14/extensions/MobileFrontend: SWAT: [[gerrit:486147|Explicitly pass in parseHTML]] T214451 (duration: 00m 57s)

Mentioned in SAL (#wikimedia-operations) [2019-01-24T00:42:45Z] <thcipriani@deploy1001> Synchronized php-1.33.0-wmf.13/extensions/MobileFrontend: SWAT: [[gerrit:486146|Explicitly pass in parseHTML]] T214451 (duration: 00m 55s)

Please beware that passing in document as context for parseHTML disables the security guards provided by jQuery, and thus makes it equivalent to $() for most purposes, including that inline scripts may end up being evaluated and executed.

The nodes created by parseHTML are detached by default (you have to insert or append them somewhere) from both any parent, as well as any document. This last bit is what makes it secure, and also what makes it different from a plain document.createElement('div').innerHTML = assignment. Rather, it's effectively like document.implementation.createHTMLDocument().createElement('div').innerHTML =.

This difference should only be observable when code is attempting to access the owner document before your code has decided where to insert the element, which tends to be a sign that something has gone wrong somewhere.

It'd be nice if you could trace down what code is attempting this kind of access. And if that is occurring within jQuery, to create a minimal test case. I can help prioritise it upstream. At that point I could also help find a different workaround in the interim, one that doesn't open us up to the security problem that jQuery 3.0 fixed.

Please beware that passing in document as context for parseHTML disables the security guards provided by jQuery, and thus makes it equivalent to $() for most purposes, including that inline scripts may end up being evaluated and executed.

Yup, and View's should be safe in this regard. Previously they were using $() and we overlooked this when migrating to parseHTML.

Please beware that passing in document as context for parseHTML disables the security guards provided by jQuery [..]

Yup, and View's should be safe in this regard. [..]

Do you mean that mean that View is never used to display interface messages (e.g. mw.msg) and never used to display user input (e.g. search queries, edit summaries, block reasons etc.). Or that these kinds of values will only ever be inserted through safe DOM methods (like text()) after parsing, and not through string interpolation as part of what is parsed initially?

Jdlrobson updated the task description. (Show Details)Feb 20 2019, 9:48 PM

We are essentially using it like createElement (in fact in future we might consider replacing it with that). It will never be passed interface messages.
Right now this is the most complicated usage of it:

this.parseHTML( '<p class="content empty">' ).text( mw.msg( 'mobile-frontend-donate-image-nouploads' ) )

but normal usages look like:

return util.parseHTML( '<div>' ).html( html ).text();

Merged into logging infrastructure task, as there's little we can do to identify and fix these bugs without the stack trace.