| Paladox | |
| Jul 2 2017, 1:46 AM |
| F28128944: 290BFD8B-4923-4C7A-A515-B936C212BA05.png | |
| Feb 5 2019, 10:45 PM |
| F8592637: IMG_0209.PNG | |
| Jul 2 2017, 11:21 AM |
Steps to reproduce
Expected results
It to work and show the file in raw format.
Actual results
Fails with:
ERROR_MESSAGE_MAIN
The operation couldn’t be completed. (QuickLookErrorDomain error 16.)
Tested on iOS 11 public beta using an iPhone 6 plus
I am filling this in SRE because the error sound unrelated to phabricator internal code. I think this may be the rewrite we setup to redirect https://phab.wmfusercontent.org main page to phabs main page.
I’m setting this to high since it is broken and the rewrites should be fixed.
But the rewrites seem to work for https://phabzilla.wmflabs.org/file/data/yydp2qcdrep6lrv2vlxn/PHID-FILE-wnr4rr7iatru4jo2ityf/index.php so strange.
ANd they work here https://phab.wmfusercontent.org/file/data/peuopop3vakr76tkilaj/PHID-FILE-mo4pxxlqyjyelktnyg3s/Gruntfile.js too
So somehow this is broken for some files.
Cannot reproduce, shows the raw file for me in Firefox 54 on Linux.
Not SRE territory. Resetting priority as I cannot reproduce.
I’m setting this to high since it is broken and the rewrites should be fixed.
Priority is urgency. "It is broken" is never an argument for high (otherwise all bug reports would be high), so please do not set Priority if no other arguments are provided.
Seems ios specific (please include such important information in the initial description) and nothing RelEng should look at but upstream
@Paladox: Can you still reproduce this? Asking as https://phabricator.wikimedia.org/T201460 got fixed (which might be unrelated but as I do not find any information what "QuickLookErrorDomain error 16" means, this is a shot in the dark)...
I don't think the fix for T201460 would affect loading images. It could be another cross domain policy issue but I don't really think so. Seems like a bug in iOS
Nope still fails.
Fails with
The operation couldn’t be completed. (QuickLookErrorDomain error 16.)
(null)
It's most likely a bug in iOS. I can reproduce it, with https://phab.wmfusercontent.org/file/data/qqvmtekknxnpbfwtap7q/PHID-FILE-rxk2etm7k467bhv3g2ot/Dockerfile.template.
It's the same file, but the one in the task description now returns a 404.
I'm using iOS 11.4.1 on an iPad Mini 2. Only Safari explicitly shows this error, Chrome just shows ERR_FAILED.
This is still a problem on iOS 12.1.3, although the error message is slightly different:
("null"? nice one, Apple)
I hooked up a debugger and got the following warning message in the console:
Resource interpreted as Document but transferred with MIME type application/vnd.iwork.pages.archive: "https://phab.wmfusercontent.org/file/data/sowitghztg2uqfykan6j/PHID-FILE-yfq3lindbcbplo2railp/Dockerfile.template".
This warning message seems to be lying, since the data is being transferred with content-type: text/plain; charset=utf-8 (unless we set different headers depending on the user-agent or something?). But I guess it indicates that Safari is trying to do some weird Apple thing with it, rather than treating is as plain text, as it should.
As I do not have an iOS device, I used a trial account on browserstack.com (os=iOS&os_version=15.0&device_browser=safari) and went to https://phabricator.wikimedia.org/diffusion/ODIT/browse/master/node18-sssd/base/Dockerfile.template and clicked "Raw File" to get in theory to https://phab.wmfusercontent.org/file/data/fg2x2pfutkat34lkguhl/PHID-FILE-uvxo7hmkzxciow74fbc5/Dockerfile.template
I got a Do you want to download "Dockerfile.template"? popup.
Though that's not ideal either (could render instead of asking to download), I assume this ticket is obsolete?
