[Bug] When using Firefox as local file viewer and tabs from outside managed, TST prepends "about:blank?" to URL and breaks viewing

[raunn]

Abstract

When using Firefox as a local file viewer (e.g. for PDFs) and TST is set to manage new tabs from outside Firefox, the URL will be modified after the management event, and "about:blank?" will be prepended. This breaks viewing, and a blank page is shown.

For example, if the user has their system set to open PDF with Firefox, and then opens a PDF in the system, normally (unmanaged) a new tab will appear with a URL like "file:///C:/Users/Path/To/File.pdf" . If TST is installed and set to manage those new tabs (which is the default setting) then the tab will open correctly and then get moved immediately to the managed tree location and container, and the URL will be changed to "about:blank?file:///C:/Users/Path/To/File.pdf" and it will fail to display the file. The URL must be manually edited in the resulting tab to remove the prepend before the file can be viewed.

Steps to reproduce

1. Start Firefox with clean profile.
2. Install TST.
3. Set system to open PDF files with Firefox.
4. Open Firefox and start a new tab in any container.
5. Open a PDF file from the system filesystem (e.g. by double-clicking on the file in Windows File Explorer )

To demonstrate non-managed behavior, set:
New Tabs Not From Existing Tabs -> Non-Blank New Tabs -> New Tab From Outside Firefox
to
"Open as (no control)"
and repeat steps 4-5.

Expected result

Tab is opened in correct tree position and container, URL remains "file:///...", and Firefox displays the file correctly

Actual result

Tab is opened in correct tree position and container, but URL is prepended with "about:blank?" and Firefox cannot display the file

Environment

• Platform (OS): Windows 11
• Version of Firefox: 119.0.1
• Version (or revision) of Tree Style Tab: 3.9.18

[piroor]

This is due to the restriction of WebExtensions API: it does not allow addons to reopen tab with file: URL with different container.
See TST options => "New Tabs not from Existing Tabs" => "Non-blank new tabs" and choose "(no control)" for all "Container:" options, then TST never tries to reopen file: URL tabs on your case.

Here is a solution idea: disabling the feature "reopen tab with different container" for some type URLs , to avoid such a "about:blank?" prefixed URL tabs problems. How about this idea?

[raunn]

Yes, that would be perfect, if you could select action based on URL prefix. Or at least treat "file://" separately. Because most links from outside are still https:// links (like clicking on email link), and you do want a container for these. But if local "file://" links are not in a container, it usually does not matter as much. There are some cases where you will follow links from within a file, but I think it would be more valuable to not break the viewing flow. Agree your suggestion results in a better flow for this case.

…

On Sun, Nov 19, 2023 at 2:26 AM piroor ***@***.***> wrote: This is due to the restriction of WebExtensions API: it does not allow addons to reopen tab with file: URL with different container. See TST options => "New Tabs not from Existing Tabs" => "Non-blank new tabs" and choose "(no control)" for all "Container:" options, then TST never tries to reopen file: URL tabs on your case. Here is a solution idea: disabling the feature "reopen tab with different container" for some type URLs , to avoid such a "about:blank?" prefixed URL tabs problems. How about this idea? — Reply to this email directly, view it on GitHub <#3410 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVWNWGQG7S6MHDOR3VSZNDYFHNFPAVCNFSM6AAAAAA7RO3VVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXHAYTENBYHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[piroor]

I've introduced a change 4ad0b62, now TST won't reopen un-reopenable URL tabs for cases like this.

[raunn]

You rock, looking forward to it!

…

On Sun, Nov 19, 2023, 10:18 PM piroor ***@***.***> wrote: I've introduced a change 4ad0b62 <4ad0b62>, now TST won't reopen un-reopenable URL tabs for cases like this. — Reply to this email directly, view it on GitHub <#3410 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVWNWFFUVBLSRFFNMSBPQTYFLY2RAVCNFSM6AAAAAA7RO3VVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJYGI4TGMRWHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[irvinm]

@piroor should this one be closed?

[piroor]

Related topic: now TST supports drag-and-drop of local files to its vertical tab bar. It is based on blob: URI which is generated from dataTransfer which is a part of drag events. File: URL tabs looks to be reopened with blob: URI but actually it is impossible because there is no genuine method to generate dataTransfer from file: URL tabs. Moreover, calling of fetch() for file: URL is not allowed for addons.

I hope to keep this issues tracker as the place to track unresolved problems possible resolved, so I close this for now.