Image in blog is 404, resolving against extension vs. original domain

[humphd]

I'm not sure if this is the right repo for bugs in Mercury Reader, so let me know if there is a better repo for it.

• Platform: macOS 10.14.6
• Mercury Parser Version: 4.3.1.0
• Node Version (if a Node bug):
• Browser Version (if a browser bug): Chrome Version 79.0.3945.79 (Official Build) (64-bit)

Expected Behavior

Images using paths /from/the/root should work when shown using the Mercury Reader. For example, on https://blog.humphd.org/open-source-fall-2019/, there is an <img src="/content/images/2019/12/telescope-gource.png"> element, which displays correctly in normal view.

Current Behavior

Using Mercury Reader, the same image is a 404. The path has been resolved relative to the extension, and becomes chrome-extension://oknpjjbmpnndlpmnhmekjpocelpnlfdi/content/images/2019/12/telescope-gource.png, which can't be found.

Steps to Reproduce

• Go to https://blog.humphd.org/open-source-fall-2019/
• Scroll down to notice that there is an image in the post
• Enable Mercury Reader on the page
• Notice that the image has been broken, and a 404 appears in the console.
• In the dev tools, inspect the broken <img> and hover the src value, which is now shown as chrome-extension://oknpjjbmpnndlpmnhmekjpocelpnlfdi/content/images/2019/12/telescope-gource.png

Here is a screenshot, with the page loaded normally on the left, in Mercury Reader o the right:

Possible Solution

I don't know how the Reader code works, but it appears that the relative URL is being made absolute, and resolved relative to the extension's domain vs. the blog's.

[jdq22]

We're also having this issue.

[humphd]

I've had to deal with this bug in other contexts, and I did it using a <base> element, to make sure that relative URLs resolved properly.

I notice in the <iframe> your extension injects, you have this in the document:

<base target="_parent">

If your <base> element also included an href="url-to-original-site" attribute, I bet it would fix this.

[kibiz0r]

Can confirm, also having this issue.

@humphd's proposed solution seems to work.

I started to write a TamperMonkey script to work around this, but cross-site scripting protections make it rather annoying. If someone puts in the time to do it, I'd love to know about it.

What are the chances we'll get a real fix, after 2 years of this issue being open with no reply? Is this extension just dead?