asciidoctor-browser-extension icon indicating copy to clipboard operation
asciidoctor-browser-extension copied to clipboard

Can't open adoc files in the browser anymore (Ubuntu 18.04)

Open aivarannamaa opened this issue 6 years ago • 10 comments

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?

aivarannamaa avatar Oct 09 '18 13:10 aivarannamaa

Hello @aivarannamaa

Could you please check your /etc/mime.types file ? Do you have any reference to adoc or ad ?

ggrossetie avatar Oct 11 '18 07:10 ggrossetie

Hi!

Nope, neither is present in this file.

aivarannamaa avatar Oct 11 '18 07:10 aivarannamaa

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 avatar Nov 05 '18 22:11 jasontibbitts

@jasontibbitts Do you have any applications that are associated with .adoc files? Can you try different file extensions?

mojavelinux avatar Nov 05 '18 22:11 mojavelinux

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.

jasontibbitts avatar Nov 06 '18 00:11 jasontibbitts

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.

mojavelinux avatar Nov 06 '18 00:11 mojavelinux

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.

ggrossetie avatar Nov 25 '18 14:11 ggrossetie

https://bugzilla.mozilla.org/show_bug.cgi?id=1266960

ggrossetie avatar Nov 25 '18 15:11 ggrossetie

I think we should document the current behavior and explain why.

ggrossetie avatar Nov 25 '18 15:11 ggrossetie

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.

mojavelinux avatar Nov 25 '18 15:11 mojavelinux