search

wallabag / wallabagger

Chrome / Firefox / Opera plugin for wallabag v2.
http://wallabag.github.io/wallabagger/
MIT License
363 stars 48 forks source link

"Missing host permission for the tab" when trying to bag a PDF in firefox #386

Open jakkarth opened 4 months ago

jakkarth commented 4 months ago

I've got a PDF open in a tab in Firefox. You can open it too: https://repository.ubn.ru.nl/bitstream/handle/2066/239928/239928.pdf When I click the wallabagger icon in my tool bar like usual, it opens its little window, and says "Loading wallabag API" forever. When I look in the extension's console, I see this:

Uncaught (in promise) Error: Missing host permission for the tab
    apply self-hosted:2337
    applySafeWithoutClone resource://gre/modules/ExtensionCommon.sys.mjs:677
    wrapPromise resource://gre/modules/ExtensionCommon.sys.mjs:1005

It never shows up in wallabag. What else can I provide to help diagnose this issue?

Simounet commented 3 months ago

It's because Firefox uses it's own internal viewer. You should be able to add it to wallabag it through a right click on the document then wallabag it! from the context menu. We should display that inside the popup instead of the dumb waiting behavior.

jakkarth commented 3 months ago

Similar issue when trying to save a PDF firefox is displaying using file:// from my hard drive. Trying to use the toolbar icon crashes in popup.js line 610:

this.entryUrl.textContent = /(\w+:\/\/)([^/]+)\/(.*)/.exec(tab.url)[2];

because the result of exec is null. tab.url is "file:///home/jakkarth/Downloads/foo.pdf", so there's no domain to collect. Also the / after ^ should be escaped I think. User behavior is same as the original case, just says "loading api" forever.

When trying to do it through the context menu, it winds its way through to isServicePage on background.js:570, which returns true, so the action fails without any indication to the user that something has gone wrong.

I can see why using the URL here would fail (toolbar case), and I think the fix @Simounet mentioned is a reasonable workaround for that case. However, I don't see any reason we should fail to save from the context menu here. file:// isn't a "service page" in the sense that moz-extension:// or about:debugging would be. The contents seems reasonable to save, and should be available the same way that any other viewer'd pdf would be.

jakkarth commented 3 months ago

On further examination, the context menu option is still just sending the URL, rather than getting the dom contents from the browser, as far as I can tell. Using content_scripts doesn't work because of the pdf viewer. And no host permissions in the context menu means the executeScript approach won't work. It may just not be possible.

Simounet commented 3 months ago

Yes, at the moment, we can't send PDF content from the browser. Adding from right clicking on the document send the URL. If you've already downloaded the document (having file://*** it won't work. The only case my advice is working with, is the first scenario with a remote URL https://***. At the moment, wallabag's purpose is about storing remote content not local one. Plus, as you mention it, it doesn't seems to be possible to send the PDF viewer content from the browser anyway.