Extension does not get active when using local http server

[Gobutah]

I used the second tweak (put type=text/plain exts=md,mkd,mkdn,mdwn,mdown,markdown, desc="Markdown document" into ~/.mime.types) to make the plugin work for local files. It does indeed work.

However I can't click on links in my local markdown files when they are relative links to other local files as the path is not correct then. I know that this is not a limitation of this plugin but just the rules how relative paths are translated in absolute paths, which does not work for local files because the browser does not know the base path from which these relative paths are taken.

In order to click on relative links in the markdown files I want to run a local http server with the correct base path. I tested both

1. python3 -m http.server
2. The node http-server https://www.npmjs.com/package/http-server.

The problem is that markdown files are downloaded and not opened by the plugin for both local servers above when I open a markdown file via these http servers. For example the node http-server sends the following HTTP headers when opening a .md link (firefox then just downloads the .md file instead of opening it):

HTTP/1.1 200 OK
accept-ranges: bytes
cache-control: max-age=3600
last-modified: Tue, 24 Jan 2023 12:26:32 GMT
etag: W/"21496529-7381-2023-01-24T12:26:32.089Z"
content-length: 7381
content-type: text/markdown; charset=UTF-8
Date: Wed, 25 Jan 2023 10:42:25 GMT
Connection: keep-alive
Keep-Alive: timeout=5

What can I do to have the .md files opened in the browser and rendered by the plugin instead of downloading them? Thank you.

[Cimbali]

However I can't click on links in my local markdown files when they are relative links to other local files as the path is not correct then.

You mean the relative path in the file is not the same as the relative path on disk? (e.g. because of where you’ll serve the file?) In that case the plugin can’t do much indeed, but if the paths are the same there should be no issue.

---

markdown files are downloaded

So the tweak you used makes Firefox consider .md files as text/plain mime type. Your server however, is specifying that the mime type is text/markdown, so Firefox uses that instead.

If you try the v2 beta (see #99), the local server approach should not have issues, as it fetches the page content without requiring firefox to open it as text first.
Just open ext+view-markdown:http://localhost/<path to file from base>.md.

[Gobutah]

You mean the relative path in the file is not the same as the relative path on disk?

Yes, links are with respect to a base directory like this:

tree .
.
├── a
│   ├── detail_stuff.md
│   └── overview.md
└── b
    ├── detail_stuff.md
    └── overview.md

2 directories, 4 files

and in a/overview.md I want to have a link to "b/overview.md" for example. I previously used grip and it works like the local server approach but it uses online (GitHub API) markdown rendering which I don't like.

---

I will try the v2 beta approach once I figured out how to use it. How do I install it? For now I have just used Firefox's about:addons to install this plugin and don't know how to install your 1.8.1.44.zip.

[Cimbali]

From about:addons, click the gear icon and select “install add-on from file”.

As to the file name, .xpi files are just renamed zip files anyway, but github has a whitelist of allowed extensions so I couldn’t upload .xpi.

[Gobutah]

Unfortunately, it says "Failed loading page http://192.168.178.32:8080/<filename>.md" in a red box, the funny thing is when I click on the link the file is downloaded again. I will check with a fresh Firefox profile and only this manually installed plugin and then make some screenshots...

[Cimbali]

Is the path to your file just .md?

[Gobutah]

Sorry, no. Actually I just put "filename" in brackets, somehow they were not rendered:

We have some policy to be careful with our internal files so I erased the filename and this is also why I need to migrate away from grip for help documentation (grip might send everything out to github). I will do some more investigation. It seems that on the fresh profile with only plugin manually installed from the zip I get a different result:

[Gobutah]

The red box does not appear anymore after a restart of Firefox. So now, when I prefix "ext+view-markdown:", there is now consistency again between my original profile and the fresh profile, both with your linked v2 beta version: They both give me the blue box, where I can select a local file with the original problem of bad relative links.

[Gobutah]

When the blue page above appears, the node http-server does not show a HTTP GET. The page is not looked up.

[Gobutah]

I found out (with respect to my example above):

• http://127.0.0.1:8080/a/overview.md downloads the page
• ext+view-markdown:http://127.0.0.1:8080/a/overview.md gives this (the link is clickable and the file downloads correctly).
• ext+view-markdown:127.0.0.1:8080/a/overview.md give this and does not hit the local server: I see that you explicitly wrote

Just open ext+view-markdown:http://localhost/.md

Sorry, I made this mistake (forgot http://) because firefox strips it from links (I clicked "open link in new tab" and prepended "ext+view-markdown:" that's why I forgot the http://). So the statement that restarting firefox changed the red box to the blue is wrong, things are exactly as listed in this post above. This means the issue is not solved yet. Do you have any ideas?

[Cimbali]

So 1) download the page: this is because your server enforces a mime-type and Firefox does not allow extensions to handle mime-types yet 2) this is the correct way of using the extension, and should work. Can you tell me what errors are shown in the console? (accessible from menu Tools > Browser Tools > Browser Console) 3) you need to pass the full URL to the extension, otherwise the extension does not know whether to fetch the page over http, https, file, etc.

[Gobutah]

Thank you.

2. "Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt" ("Reason: CORS-Header 'Access-Controll-Allow-Origin' missing")

3. But Firefox defaults to HTTP when no protocol is given I think? Because without the "http://" normal page load (without prefix "ext+view-markdown:" does work.

[Cimbali]

To me with python3 -m http.server it works, if launched from this repo I can open both top-level README.md and subdirectory test/test-file.md, while accessing them directly causes a download prompt.

---

Sorry, I made this mistake (forgot http://)

That’s useful feedback and why we have a beta. :) It’s likely more people will have the same experience.

[Gobutah]

It is sensitive to IPs vs "localhost": python3 -m http.server says and node's http-server says So clicking on these links leads to these IPs in the URL instead of localhost. With localhost it works for me too at least with this repo. I will try now with my own files.

[Gobutah]

It renders the markdown nicely now but links are not clickable (relative links to other files which are valid if I click open in new tab, they are downloaded). Do you have any ideas how to follow links?

I noticed the URL is immediately rewritten to "moz-extension://b18bcf4f-8a02-44d5-a556-15102ffb7056/ext/view-md.html?file=ext%252Bview-markdown%253Aht ..." is this normal or is this something unusual causing the links to be non-clickable?

[Gobutah]

download the page: this is because your server enforces a mime-type and Firefox does not allow extensions to handle mime-types yet

Can I modify the headers sent by the local server such that the extension is triggered without the need to prefix ext+view-markdown? See https://stackoverflow.com/questions/21956683/enable-access-control-on-simple-http-server. What would need to be changed?

[Cimbali]

So clicking on these links leads to these IPs in the URL instead of localhost. With localhost it works for me too at least with this repo. I will try now with my own files.

For me it works with 127.0.0.1 and localhost − not with my 192.168.0.X address, I get Upgrading insecure request ‘http://192.168.0.X/README.md’ to use ‘https’ and then the server does not understand the request.

I noticed the URL is immediately rewritten to "moz-extension://{id}/ext/view-md.html?file=ext%252Bview-markdown%253Aht ..."

This is normal, basically that is the extension page that does the rendering. ext+view-markdown: is just a mechanism to avoid you remembering/typing all that.

links are not clickable (relative links to other files which are valid if I click open in new tab, they are downloaded).

I’ve noticed that as well. I’m not sure where it comes from and will have to investigate.

---

To serve your markdown files as text/plain (which AFAICT solves all your issues):

python3 -c 'from http.server import HTTPServer, SimpleHTTPRequestHandler ; SimpleHTTPRequestHandler.extensions_map = {".md": "text/plain"}; HTTPServer(("", 8080), SimpleHTTPRequestHandler).serve_forever()'

[Gobutah]

Indeed, 127.0.0.1 also works. Your final command solves my issues thanks a lot!

But I cannot click back, as it immediately forwards me into the extension page again. This means that every click on a link adds two steps in the history, the first one forwards to the second one and the effect is that I am trapped and cannot go back in the history - just like these nasty websites in the old days of the internet that used this page forward trick to trap you on their page and would not let you go back to google again :)

Can this help somehow here? https://stackoverflow.com/a/32398717 (I am no javascript coder, this is just a hint, hopefully it can help)

[Cimbali]

Yes we need to handle a couple of things better:

• [x] Try reasonable defaults (http? and let Firefox upgrade to https?) if no scheme is present
• [x] navigation history, so going back does not trigger the redirect again
• [x] look into the CORS issues from using a local IP address: seem to be linked to mime-type. If served as text, the issue does not happen.

The links not working issue seems due to the text/markdown mime-type again. If you open the link to a new tab (e.g. middle click), you get the download prompt. But normal click does nothing without an error message and I’m not sure why.

[Gobutah]

Thank you for the good support. I will use the python command for now and go back two steps by right-clicking on the page back button.

[Cimbali]

I think you can even revert to using the current version of the add-on, that way you won’t have all the unfixed issues.

[Gobutah]

I think you can even revert to using the current version of the add-on, that way you won’t have all the unfixed issues.

Yes this works and this previous version does not have the navigation history issue!