Fragments identifier ignored when restoring from stash with Firefox Multi-Account Containers

[pchampin]

OS Version

Ubuntu 24.04 LTS

Browser Version

Firefox 129.0.2 (64-bit)

Tab Stash Version

3.0.1

Installed Extensions

• Firefox Multi-Account Container

Problem Description

When I open a tab from the stash, and this tab's URL contains a fragment identifier (# followed by an anchor), this fragment identifier is ignored, and the page is displayed at the top (while it should be displayed scrolled to the element identified by the anchor).

This only happens when the 'Firefox Multi-Account Containers' (FMAC) extension is also installed.

Steps to Reproduce

• open https://www.w3.org/TR/rdf11-concepts/#section-rdf-graph
• it displays section 3 of the document
• stash this tab
• reopen the stashed tab from the side panel
• it displays the top of the document (despite the fragment identifier being in the URL)

Expected Behavior

After reopening the stashed tabbed, it should display section 3 of the document. By the way, this is what happens when the 'Firefox Multi-Account Containers' is not installed.

Impact

As a workaround, one can reload the page after restoring it from the stash. It then displays the correct part of the document.

Also, I noticed that when the 'Firefox Multi-Account Containers' extension is configured to automatically open this URL in a specific container, then it is opened at the correct location when I restore it from the stash. The bug only occurs for URLs that open in the default container.

Additional Details

No response

Vote for This Issue

• Readers: If you are also experiencing this problem, please vote for it by giving the ORIGINAL POST a thumbs-up using the 😃 button below. You are welcome to leave comments and discuss the issue if you have more details to add, but "Me too!" comments are not counted by the voting system.

[josh-berry]

Interesting; this appears to be a bug in Firefox where it is ignoring the fragment identifier when first loading the page.

It's probably a quirk of how Tab Stash creates tabs; we pre-create empty tabs and then load them a few at a time, so we don't cause performance issues by trying to load them all at once. But this seems to cause Firefox to not realize that it needs to scroll the page after first load.

I'll have to dig further to see if there's a way to work around it, but for now, I recommend just refreshing the page if it's not positioned correctly. Thanks for letting me know!

[pchampin]

Interesting; this appears to be a bug in Firefox where it is ignoring the fragment identifier when first loading the page.

Please note that the bug only appears when both extensions "Tab stash" and "Firefox Multi-Account Containers" are installed, and only for tabs opened in the default container. So if this is a bug in Firefox, it only manifests in very specific conditions...

[josh-berry]

I did notice that, yeah. The container functionality is baked pretty deeply into Firefox itself (the extension just wraps this functionality in a nice UI), so it could be some weirdness with the container feature being enabled vs. not.

The specific reason I say this is a Firefox bug is that Tab Stash itself just makes a single API call to the browser to set the open tab's URL (which of course includes the fragment), and it is then up to the browser to load/reload the tab, scroll the page correctly, etc. It's literally the API equivalent of pasting a URL into the location bar and hitting the "Enter" key.