asciidoctor-browser-extension
asciidoctor-browser-extension copied to clipboard
Can't open adoc files in the browser anymore (Ubuntu 18.04)
I used to read adoc files with Chrome extension, but I can't do it anymore -- the browser keeps downloading the files. I have "Allow access to file URLs" enabled.
I tried using the extension in Firefox, but it's still the same -- the browser keeps downloading instead of rendering.
I suspect it has to do with some application which changed the associations for adoc files. I uninstalled one of them and removed file-type part from *.desktop file for the other, but it didn't help.
Can you suggest what should I do next?
Hello @aivarannamaa
Could you please check your /etc/mime.types
file ? Do you have any reference to adoc
or ad
?
Hi!
Nope, neither is present in this file.
I was just trying out this extension and ran into the same problem. It does work fine if I copy the file to a web server, though, so the issue appears to be related to some difference between loading from a file:/// URLs as opposed to https://.
@jasontibbitts Do you have any applications that are associated with .adoc files? Can you try different file extensions?
I have no associations within Firefox and nothing specific within my OS or desktop environment. xdg-open will open the file in a text editor, presumably because the file utility indicates that the file is ASCII text. I edited /etc/mime.types to add "text/asciidoc adoc asciidoc" and restarted the browser; afterwards Firefox would would only offer to save the file or open it in an external application. I removed that line from mime.types and the browser reverted to opening the file as plain text.
I renamed the file to end in ".txt" and checked the box in the extension preferences to enable previewing of txt files. The behavior did not change; the browser simply displays the file as plain text. The same happens if I rename the file to end in ".asciidoc".
I note that the web server I was using has no particular MIME type definition for asciidoc files, and presents the file as text/plain. When I open it, the extension immediately renders it and the browser indicates that it was retrieved as text/plain.
So all I can think of is that Firefox simply handles loading from file:/// URLs differently somehow.
I'm running today's Firefox nightly. It doesn't appear that the behavior under 63.0 is any different.
Edit: Looked at #243 and realized it's pretty much the same issue. And the solution there of just hitting enter in the URL bar without editing the actual URL causes the page to render properly.
I renamed the file to end in ".txt" and checked the box in the extension preferences to enable previewing of txt files. The behavior did not change; the browser simply displays the file as plain text.
Aha. So the behavior you're describing is a little different from the original post. When using Firefox, you have to request the file directly from the location bar when it begins with file:///. You can't just navigate to it (for example, from a directory listing). After navigating to it, you can focus the location bar and press enter. This step is necessary due to some sort of security feature in Firefox.
Thanks @jasontibbitts and @aivarannamaa, I can now reproduce this issue.
The root cause is that Firefox does not allow access to file://
URLs unless explicit user input: https://wiki.mozilla.org/WebExtensions/Filesystem#Not_planned
"explicit user input" means you have to type the file://
URL and press "Enter".
In theory it's a good thing but in practice the user cannot even give his permission. WebExtensions have a manifest where the developer can define what "permissions" are needed. In addition, in Chrome you can specifically choose to give the extension file://
access or not but in Firefox nothing is available...
So unfortunately for now the only thing we can do is wait for Firefox to implement a permissions system for extensions.
https://bugzilla.mozilla.org/show_bug.cgi?id=1266960
I think we should document the current behavior and explain why.
Now that I've learned that I have to select the location bar and press enter, even though it's not ideal, it's not too annoying and it works. I think we could avoid a lot of future issues by calling this out in the documentation.