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

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.

In T214451#4904462, @Jdlrobson wrote:

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?

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();