Viewer does not seem to recognize .md docs from HTTP URLs

[braytak]

Hi!

I don't really know if this is an issue or a known limitation.
The again, I might not be doing what I need to do to get that functionality working...!

Tks,

[KeithLRobertson]

It actually might be a feature. :-) If the .md content is received as HTML, then the viewer doesn't style it. The content has to arrive as raw text.

For example, navigate to this .md file (https://github.com/KeithLRobertson/markdown-viewer/blob/master/README.md). You see it has the standard github menus, headers and footers; github has styled the document, so the viewer does not. Click on the "Raw" button; it's on the right just above the markdown document content. (There are text buttons Raw, Blame, History.) That navigates here (https://raw.githubusercontent.com/KeithLRobertson/markdown-viewer/master/README.md). It is not styled by github, so it should be styled by the addon.

If you see the latter link as raw text, then there may be an issue with how the addon detects whether the content is styled yet or not. (Could be different versions of Firefox wrap raw text into an HTML DOM in different ways?) I would need your help to open the developer view and show what the DOM looks like. The viewer expects that for unstyled text, the document body has exactly one child node which is a PRE element.

[KeithLRobertson]

@braytak Did you try the above steps? Was the raw link styled?

[braytak]

@KeithLRobertson Yes I did.
The extension successfully displayed the raw markdown!

What I can tell you is that the type column of the network tab in the Developer Tools shows plain for the working case and x-markdown for the case where the .md extension is not recognized.

[braytak]

@KeithLRobertson Addigionally, I get the following prompt from Firefox - the documents are served by express

[KeithLRobertson]

@braytak Well, again, the extension doesn't style the markdown if the server has already styled it. I think that's being reflected in the content-type sent by the server, which is then shown in the type column.

Regarding your second message, under what conditions do you see that prompt? This means Firefox wants to download the file rather than open/display it. In this case, Firefox would not pass the content to the extension, so you couldn't have seen "the extension successfully [styled] the raw markdown".

[braytak]

@KeithLRobertson

... if the server has already styled it.

No, the x-markdown MIME type is a text type qualifier; the data is delivered in plain text.

...under what conditions do you see that prompt?

I get it when I access my .md documents NOT your readme...

I will get back to you with further information in a couple of days.

[braytak]

@KeithLRobertson I have now "refreshed" Firefox (v56.0) which included re-installing your extension.

• Navigating to your readme.md gives a content-type response header value of `text/plain;charset=utf-8 and NOW displays un-styled content (plain text) - I have a screenshot of this if you want it.

• Navigating to my .md documents shows up as content-type of text/x-markdown;charset=utf-8 and brings up the application prompt panel.

How does the extension decide to engage styling; file extension, content-type header, both?

[KeithLRobertson]

@braytak What platform are you running on? I am using FF 56.0 on Windows, and the viewer styles local .md files and the raw readme.md just fine.

When the readme.md is unstyled, what does the DOM look like?

The viewer hooks into the tabs updated event. If FF decides to download the file (or open in an application) rather than display it, the viewer doesn't see it. That seems to happen for your local .md documents based on the file extension and some Firefox settings/mappings.

• On Windows, FF loads .md documents, so this isn't an issue.
• On Ubuntu Linux, there is a known fix. See issue Not loading md files in firefox on Ubuntu Linux #2.
• On OSX, I wish someone would resolve it and post on issue Not loading md files in firefox on OSX #6. I don't have a Mac so I can't help here.

Assuming FF loads the document, the viewer triggers when the update is "complete" (i.e. the document is loaded) and when the URL extension looks like .md, .mkd, .markdown, etc. The viewer never sees the file or characters directly; at this point, FF has already read the file, decided the encoding and converted it to characters, decided whether it's plain text or HTML and converted it into a DOM (Document Object Model).

For plain text, FF will have created a single <pre> element in the <body> and placed the file content in there. If the viewer sees other elements, then the document is already styled, so the viewer doesn't change it. Otherwise, the viewer pulls the content out, styles it as HTML, and replaces the <pre> element with the styled HTML elements in the DOM body.

[KeithLRobertson]

Oh wait! It's not styling the raw readme.md any more! I'll look into that ASAP.

[braytak]

@KeithLRobertson Same platform FF56, W10.
Here is a snapshot of the readme.md...

[KeithLRobertson]

As noted above, I am seeing the same. This appears to be a new defect in FF 56.0+. The extension background script activates, but tabs.executeScript() doesn't do anything. This is supposed to load the content script into the page which rewrites it. It works for local markdown but not for markdown loaded from a non-local URL. My extension has "activeTab" permission, and according to the documentation that should be all that's needed.

I also tested FF 56.0.1 and FF Dev Ed 57.0b, and they have the same problem.

[braytak]

@KeithLRobertson Sorry... selected wrong reaction icon... I meant "bummer" ;-)

[braytak]

@KeithLRobertson Willing to do further testing if ever you need it...

[KeithLRobertson]

@braytak, thanks! This is still an issue in FF 57.0, Quantum. Since 56.0, tabs.executeScript() doesn't work for non-local documents. I need to open a bug with Mozilla, but I haven't had time to gather all the info.

[caneta]

The same here on Firefox 57 with Ubuntu Linux

[KeithLRobertson]

It looks like some change in permissions, but I haven't seen any documentation on what is now required.

[asim-vax]

On a similar note with Firefox on ubuntu - going to the file through file:/// it renders correctly, but over http:// it does not. I have set the mime type & in nginx set Content-Type to text/markdown for md files.

[KeithLRobertson]

The viewer doesn't currently look at the Content-Type but at the URL "file extension". As mentioned above, the viewer is activating for http:// URLs, but something has changed in FF. The viewer calls tabs.executeScript(), but that no longer works for non-local documents; it just does nothing, so the Markdown is not converted. To me, this is a Firefox bug unless Mozilla documents what it requires (permissions?). And I don't have time to figure out how to work around this problem.

[Cimbali]

This is apparently a by-design limitation, where the user needs to click or use a shortcut (or some other action) to "enable" the activeTab permission.

See https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions#activeTab_permission (emphasis mine).

This permission is specified as "activeTab". If an extension has the activeTab permission, then when the user interacts with the extension, the extension is granted extra privileges for the active tab only.

"User interaction" includes:

• the user clicks the extension's browser action or page action
• the user selects its context menu item
• the user activates a keyboard shortcut defined by the extension

And also https://bugzilla.mozilla.org/show_bug.cgi?id=1392459#c1

Kris Maglione [:kmag]
The activeTab permission doesn't give blanket permission to access the active tab. It grants permission to access the currently-active tab when a user triggers one of the extension's actions.

[Cimbali]

Also, after doing some tests, it appears this permission is reset every time the page is reloaded.

[Cimbali]

It's also worth noting that the plugin will not work if it is explicitely prohibited by the website (such as raw.githubusercontent.com). Check for a Content Security Policy header, it looks like:

Content-Security-Policy:default-src 'none'; style-src 'unsafe-inline'; sandbox

[asim-vax]

If it helps, i found another extension which manages to get this to work:
https://github.com/simov/markdown-viewer

[Cimbali]

Yes @asim-vax, I had a look at how they do it:

• They support stripping CSP headers from pages when loading (which requires webRequestBlocking permissions).

• For "host" permissions, which require user interaction, they use optional permissions.
  You have to go to the configuration page of the extension first to set-up domains matching (possible all domains with *://*/) at which point the extension asks you for the optional host permissions.

  This means you can't get tab.url through the onUpdate() API, to match which tabs should be targeted. They work around this They match URLs and headers by directly injecting some code that returns the URL, and failing silently if the permissions for the host are not set.

So if we wanted to, we could do something similar, maybe have a toolbar button that asks for (or toggles) permission on the current domain. Possibly complemented by a button in the settings page to ask for permission on all domains. I don't know how persistent those permissions are. It doesn't change the fundamental drawback that we now need to start by (trying to) inject code on every page.

Edit: some misconceptions. This approach is probably better.

[asim-vax]

@Cimbali thank you for investigating and taking the time to explain it :)

[KeithLRobertson]

Closed via #25 and version 1.3.0.