Local .md file rendered as plain text on Linux
michaelk83 opened this issue · 10 comments
Ubuntu 20.04, Firefox 100.0 installed manually to /opt/
from web download, Markdown Viewer Webext 1.8.1
When I try to load a local .md file, the file loads and is displayed (no download dialog), but renders as plain text, and isn't formatted. Same result with any local .md file.
I've followed the instructions to configure the MIME type, except I used /usr/local/share/
instead of ~/.local/share/
. This is my MIME file:
<?xml version="1.0"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
<mime-type type="text/plain">
<glob pattern="*.md"/>
<glob pattern="*.mkd"/>
<glob pattern="*.mkdn"/>
<glob pattern="*.mdwn"/>
<glob pattern="*.mdown"/>
<glob pattern="*.markdown"/>
</mime-type>
</mime-info>
IIRC, it worked correctly on an earlier version of FF, back when I set it up. I haven't used it in a while, but now it's not working, as described.
I have uBlock Origin, but disabling it makes no difference. Disabling all other extensions also doesn't help.
Are there some FF settings that may be blocking the extension scripts? What can I do to debug this further?
The mime-type does not always get picked up properly. Can you try the work-around number 2?
Point the helpers.private_mime_types_file
config value to a file you’ll create, e.g. /opt/firefox/mime.types
or the default ~/.mime.types
and then create that file with the following content:
type=text/plain exts=md,mkd,mkdn,mdwn,mdown,markdown, desc="Markdown document"
Same result with ~/.mime.types
. I don't think that it's a MIME issue, because the file does get loaded and displayed (as a text file). I'm not getting a download prompt. But the content is displayed as plain text, and not being formatted.
If I refresh the file with Web Developer Tools open, I get a "Error: An unexpected error occurred" in the console. But not sure how to debug this beyond that.
On the about:addons
page there’s a gear menu with a “debug add-ons” link, that opens a page with an “Inspect” button for each add-on. The console tab in the inspect window will filter any general issues about the add-on.
If the issue happens just on the page, which seems to be the case, there might be a hint as to where the error happens on the line with the error message (usually in file:line:column format), or a way to expand the message to see a full traceback of the error.
You could also try to deactivate the extensions from the add-on configuration page, by unticking all checkboxes.
Clicking Inspect on the Markdown Viewer opens a new dev-tools window which doesn't show anything, since there's no document loaded there. Loading or refreshing the .md file in another tab doesn't affect this window, and I don't see how to load the file there. There's a line near the top that says "about:blank", but it's not editable.
FWIW, the error that shows up in the regular dev tools console (in the same tab as the file) has "undefined" on the right. Is that where the file/line is supposed to be?
I've tried disabling all other extensions. It doesn't make any difference.
Loading or refreshing the .md file in another tab doesn't affect [the inspect] window, and I don't see how to load the file there.
Yes it’s basically showing errors for add-on background pages/threads − this add-on doesn’t have one − but also shows other general add-on errors, such as permissions etc. You might have seen a message in the console when reloading the page but nothing more.
FWIW, the error that shows up in the regular dev tools console (in the same tab as the file) has "undefined" on the right. Is that where the file/line is supposed to be?
Yes :(
Could you try the following options (should be in order of increasing effort):
- Provide the full path to the file that’s not working? I’m suspecting something in the add-on URL matching could be broken. Could be spaces or file extensions… Currently the local-URL matching rules are:
https://github.com/KeithLRobertson/markdown-viewer/blob/4db1f6623121566567871938149133d36b9fddf1/manifest.json#L45-L56 - Inspect the page and check whether the source code is just
<html><head>…</head><body><pre># the text file</pre></body></html>
where# the text file
is what you would see when opening the page as “view page source”. If it’s not exactly that, e.g. if there’s any<div>
in there, it might just be a CSS issue. - Check when opening the page with that URL directly as opposed to navigating to it? When you’re on the page rendered as text, copy the URL, open a new tab, and then paste & go to the copied URL. (This was an issue we had before and was fixed, see #45, if this fails we identified a FF regression.)
- Check with different md files, as the content could have an effect (see #58, though unlikely on Linux as mime types should avoid content detection)
- Try to reproduce the issue with this minimal extension? It’s the one from bugzilla issue 1512684 and uses the same mechanism to open
.txt
files. Here the permissions arefile://*/*.txt
(instead of*://*/*.md
), so we might update our permissions if this test passes.
The steps to reproduce the issue are:- Unzip the attached zip in your filesystem
- Inspect the 3 files to be sure there’s nothing unexpected
- from
about:addons
’ gear menu click “Debug add-ons” and from that page click “Load Temporary Add-on” - navigate to the directory where you extracted the zip and select the
manifest.json
file - open any txt file in a new tab − there’s one in the zip so you can test it on that
- check the contents are
Hello World!
(the test passed) or the original contents of the file (the test failed) − in the case of the provided txt file the contents areWebextension failed loading!
- if the test failed, check whether you see a similar error message as for MarkdownViewer
file:///data/Michael/Docs/gitdocs/index.md
, also tested same path withtest.md
andtest.markdown
.- View Page Source just shows me the same plain text. Dev tools Inspector tab shows the
<pre></pre>
stuff. - I am opening the files by pasting the URL in the address bar. Same result. (Initially I dragged the file from a file manager.)
if this fails we identified a FF regression.
I've meanwhile upgraded to FF 101, btw.
- Tried with a new test file:
# Headline
text
Which produces the following HTML in the dev tools:
<html><head><link rel="stylesheet" href="resource://content-accessible/plaintext.css"></head><body><pre># Headline
text
</pre></body></html>
Will try and update...Yeah, this one worked. Got "Hello World!" from the includedtest.txt
file.
A couple more data points:
- If I disable the Markdown Viewer add-on and reload the .md file, I still get the plain text, but the error is gone.
- I tried extracting the add-on to a new folder and loading it as temporary add-on (while the original is disabled). Adding
"file://*/*.md",
to thepermissions
array inmanifest.json
, or changing the"*://*/*.md",
line to"file://*/*.md",
and then reloading the temporary, didn't fix the issue for me.
Thanks for checking. So to summarise:
- It doesn’t seem to be an issue in accessing the file (permissions, mime types, paths)
- The minimal extension working suggests our rendering code is getting called
- The fact it happens on your minimal md file means it’s not choking on some unexpected output.
This all means it’s a bug while rendering the file, but I must say it’s a little hard to debug like that, without being able to reproduce on my side and without any kind of backtrace.
I've tried starting from the minimal extension and gradually adding back parts of the full one. AFAICT, the error is in the get({'plugins': {}})
call. Which then prevents the chained calls from being executed. Don't know why it fails, though.