Should of added - this seems to occur on IE (all recent versions), Microsoft Edge and Firefox (occasionally Chrome, not very often though).

In T108834#1531725, @Mdann52 wrote:

Should of added - this seems to occur on IE (all recent versions), Microsoft Edge and Firefox (occasionally Chrome, not very often though).

No js load at all? Maybe your firewall is blocking bits.wikimeda.org in some cases?

I can't reproduce this.

@Mdann52: Are there exact steps to reproduce available? I'm not sure what "a link" is here (and this might be not be UW-specific as expressed already).
Also, as you set "HTTPS" here, how do you think this is related to HTTPS?

Exact steps (I take ) are
1)click on link to random Wikipedia page, for example the link in https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=8566916
2)Attempt to use UploadWizard, or other js tool (ie. VE in my case).

I tagged this as HTTPS as I wasn't sure if this was a HTTPS config issue - feel free to remove if I'm misunderstanding!

Unfortunately, if you don't have access to OTRS, I'll have to figure out another way to sort this out (it's currently in Junk (not spam), so anyone should be able to access it with an OTRS account.

In T108834#1531738, @Steinsplitter wrote:

In T108834#1531725, @Mdann52 wrote:

Should of added - this seems to occur on IE (all recent versions), Microsoft Edge and Firefox (occasionally Chrome, not very often though).

No js load at all? Maybe your firewall is blocking bits.wikimeda.org in some cases?

I can't reproduce this.

Using the most updated Chrome on OSX, I can. I got this error message when I went to Special:UploadWizard: UploadWizard uses JavaScript for an improved interface. Your browser either does not support JavaScript or has JavaScript turned off, so we are showing you a simple upload form.

My browser definitely supports JavaScript and it is definitely turned on.

I see the raw text when navigating to https://commons.wikimedia.org/wiki/Special:UploadWizard. Strange.

This is really weird...

No JavaScript loads at all...but if I open a new tab and navigate directly to the page it's fine.

@Legoktm I don't suppose you could give me the raw request/response data for that, could you?

In T108834#1532283, @Steinsplitter wrote:

I see the raw text when navigating to https://commons.wikimedia.org/wiki/Special:UploadWizard.

Same here (Firefox 39). That raw HTML has some surrounding <noscript> tags.

Playing with Firefox' "Network" tab in the Developer tools for https://commons.wikimedia.org/wiki/Special:UploadWizard?debug=true , when this problem happens the HTML page has 220.41 KB size. When this does not happen, 216.87 KB size.

Comparing the Response HTML via a diff, the broken one seems to have wrong encodings:

Correct: <a onclick="insertTags(&#39;שׂ&#39;,&#39;&#39;,&#39;&#39;);return false" href="javascript:void()">שׂ</a>
Broken: <a onclick="insertTags(&#39;שׂ&#39;,&#39;&#39;,&#39;&#39;);return false" href="javascript:void()">שׂ</a>

Correct: <option title="{{PD-Art}}" value="PD-Art"> Reproduction of a painting or other 2D work that is in the public domain because of its age – needs specification after uploading</option>
Broken: <option title="{{PD-Art}}" value="PD-Art">  Reproduction of a painting or other 2D work that is in the public domain because of its age – needs specification after uploading</option>

In Chromium 43ish, JavaScript is still disabled, but the fallback form displays fine:

Just tried with debug=true, diffed the responses, no differences anymore except for edit/watch/patrol tokens and response times and wgHostname. Still seeing raw HTML text in one tab and perfectly functional UploadWizard in the other.

I have no idea what witch put what kind of curse on OTRS but we need to find her. And burn her.

I spoke too soon, I don't know how I mixed up my responses, but the same diffs are there...

Blocked script execution in 'https://commons.wikimedia.org/wiki/Special:Preferences' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

Not sure what causes it, the OTRS link seems perfectly ordinary.

So it seems that OTRS displays the email contents in an iframe with sandbox="allow-same-origin allow-popups" and any new tab that's opened by that iframe (as a result of the user clicking on the link which has target="_blank" for example) will inherit those attributes and disallow scripts. You can right click and select "open in new tab", that will work normally (in Chrome). Left or middle click or Ctrl-click won't.

Oh. Wow. Holy crap.

So do we want to "fix" this somehow?

This example case shows @Tgr is correct:

https://tools.wmflabs.org/gerrit-reviewer-bot/sandbox/frame.html

frame.html:

<iframe src="link.html" sandbox='allow-popups allow-same-origin'>

link.html

<a href="https://commons.wikimedia.org/wiki/Special:UploadWizard" target="_blank">click here</a>

WHATWG living spec, MDN. The latter mentions a Chrome-only allow-unsandboxed-auxiliary keyword which makes sandbox flags not stick when opening new windows.

I have no strong opinion on whether we should weaken the security of OTRS (and no idea whether we even can).

In T108834#1536026, @Tgr wrote:

The latter mentions a Chrome-only allow-unsandboxed-auxiliary keyword which makes sandbox flags not stick when opening new windows.

This doesn't seem to work in my test case ( https://tools.wmflabs.org/gerrit-reviewer-bot/sandbox/frame.html , the last one).

One workaround that will not weaken security is to remove the allow-popups flag. This means one has to right-click -> open in new tab to open the link, and normal clicks will be ignored. This is still confusing, but less so than suddenly not having any javascript anymore.

Hmm, this actually seems like a useful feature. If some evil user emails OTRS, sandboxing the tab is probably a good idea...

Yeah, looks like it's not supported in stable Chrome yet (only shipped three weeks ago). Also, has been renamed to allow-popups-to-escape-sandbox. WHATWG proposal, Chromium bug, Chrome platform status. So disallowing popups seems to be the only realistic option (apart from not doing anything).

In T108834#1536075, @Legoktm wrote:

Hmm, this actually seems like a useful feature. If some evil user emails OTRS, sandboxing the tab is probably a good idea...

It is useful, but I am not sure its usefulness outweighs its annoyingness. OTRS agents deal with emails linking to on-wiki diffs/discussions/permission requests a lot.

In T108834#1536075, @Legoktm wrote:

Hmm, this actually seems like a useful feature. If some evil user emails OTRS, sandboxing the tab is probably a good idea...

Yes, but permission team's Commons' license tagging tool is made by JS and it is extra work to open it in a new clean tab, isn't it?

Agent receives an email complaining about the content of https://xyz.wikipedia.org/…

He decides to edit the page, so he tries to log in.

Login page does not work. "Log in" button does nothing. If he happens to know how to open the javscript console, only then is the message shown
«Blocked form submission to 'https://en.wikipedia.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login' because the form's frame is sandboxed and the 'allow-forms' permission is not set.»
which doesn't clarify anything, either. The tab shows a normal top-level wikipedia url. The workaround is trivial, just reloading the same url in a different tab will fix it. But that's not discoverable.

allow-popups-to-escape-sandbox is now part of the living HTML standard and Chrome 46 will understand it (platform status, test), so adding that to the OTRS sandbox seems reasonable. That would probably mean locally patching OTRS though since we use a very old version of OTRS.

Of course, a much easier solution is to update OTRS, along with the other benefits, then implement this (I note T74109 here).

Hi everyone.
I just registered to inform this was fixed today.
https://github.com/OTRS/otrs/commit/d3ef057570f828bb433691bf56bbecbcf274b5e5
bug info: http://bugs.otrs.org/show_bug.cgi?id=11838

It should not happen anymore, but feel free to test it.
cheers,

Could someone try to reproduce this? We were upgraded to OTRS 5.0.7 (which contains the fix referred to by @m00derp) today. According to the upstream bug report, that should now address the issue at least in Chrome, while Firefox users will have to wait pending Firefox support for the allow-popups-to-escape-sandbox tag (https://bugzilla.mozilla.org/show_bug.cgi?id=1190641).

I still get Blocked script execution in <URL> because the document's frame is sandboxed and the 'allow-scripts' permission is not set. when visiting a link with Chrome 48 for Linux. The iframe has sandbox="allow-same-origin allow-popups" (ie. no allow-popups-to-escape-sandbox). Are we sure we are using 5.0.7?

Well, the OTRS interface says so (hover over "Powered by OTRS 5" at the bottom), and @akosiaris confirmed he completed the update earlier today. So I hope everything worked fine. The 5.0.7 change notes are at https://github.com/OTRS/otrs/blob/master/CHANGES.md#507-2016-02-16 ("Fixed bug#11838 - New tabs opened from links in a sandboxed Iframe cannot execute JavaScript"). Not sure what the issue is, in this case.

I'm still getting the error too (same error message as Tgr's in T108834#2032302 , Chromium 48 on Ubuntu 64-bit).

@Tgr helped me in finding why the changes have not been applied. We have some local customizations in the form of an OTRS package. It is overriding some templates. It is tracked here https://phabricator.wikimedia.org/diffusion/OSOT/browse/master/.

The change in https://github.com/OTRS/otrs/commit/56d02e081488998f73a597b0d7f9e55249ed5a57 (the one referred to by http://bugs.otrs.org/show_bug.cgi?id=11838) updates some of the templates we are locally overriding. I 'll update our local package and build it/install it.

Change 274436 had a related patch set uploaded (by Alexandros Kosiaris):
Bring templates up to date with 5.0.7

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

Change 274436 merged by Alexandros Kosiaris:
Bring templates up to date with 5.0.7

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

Change merged, package built and installed. That should fix our problems. @Tgr, care to test ?

Just FYI, I got Blocked form submission to 'https://commons.wikimedia.org/w/index.php?title=File:Ulukaya_at_UN.jpg&action=delete' because the form's frame is sandboxed and the 'allow-forms' permission is not set. after having been at OTRS previously in the same tab, which caused me not being able to delete that file in that tab. Not sure if this is till supposed to happen given the "Resolved" status of his ticket.

Does your browser support allow-popups-to-escape-sandbox? It is relatively new.

In T108834#2775303, @Tgr wrote:

Does your browser support allow-popups-to-escape-sandbox? It is relatively new.

How do I find out? I am using Chrome Version 53.0.2785.154 (64-bit) on Chromebook/OS
Mozilla/5.0 (X11; CrOS x86_64 8530.96.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.154 Safari/537.36

So, I am on a fairly recently updated browser, so I'm guessing it should support that (unless I have to manually turn it on).

https://www.chromestatus.com/feature/5708368589094912 implies it's supported

Yeah, a recent Chrome should work. Can you check the HTML source and see what the sandbox attribute says?