Temporary-containers: 'Close previous same domain tab' option for mouse clicks

[grenzor]

The option I'm thinking of this for is mainly left click (and isolation). When left click is set to 'Always' every left click will open a new page which will be opened in a new container (hence new tab). This is great for privacy (since every page will have each have its own container), but browsing experience is affected because if you use a website/domain for a while you will start to create too many tabs and clutter your tabs. If an option to close the previous tab from which the user clicked is there it would provide essentially the same level of privacy without cluttering the tabs.

I think this kind of option (which the user can choose to use or not) can be very useful for sites which the user will only browse to read and not really do anything else on. Just an idea I had let me know what you think

[stoically]

I must admit, I like the every-click-a-temporary-container-attitude, hehe :D I'll look into providing an advanced preference to replace the current container instead of opening a new one. I think it should affect Isolation and Mouseclicks.

[stoically]

Just published version 0.72 with the advanced "Creating new Temporary Containers in case of Isolation and Left Mouse Clicks" preference. Let me know if something doesn't work as expected.

[grenzor]

Thanks @stoically, seems to work great!

[grenzor]

Some pages even if Isolation+Mouse click is set to Always open in a new temp container it stays in the same container.

Example:

Go to addons.mozilla.org (use the old theme also needs privacy.resistFingerprinting.block_mozAddonManager set to true for Temporary containers to work). Using the AMO search bar search anything. Scroll to the bottom of the page and click the 'Next' page button. I'd expect this to open in a new container but it doesn't, not sure if it's a bug.

[stoically]

The reason for that is, and it e.g. happens for most of the navigation on GitHub too, is that some Websites don't actually trigger a request (navigation) in the tab which could be canceled and reopened. Instead they use XHR or fetch to get new content, inject it into the website and then change the URL using window.location or pushState. So there's unfortunately no sane way to handle that.

[grenzor]

From the Github/AMO examples, it seems they always append a parameter _pjax= at the end of their XHR/fetch requests. Not sure if that parameter is always used for the sites using PJAX requests, but if so it could be something unique enough to be possible to monitor XHR/fetch requests and open them in a temporary container instead of opening them as XHR/fetch when that parameter is found (as an advanced preference that only takes effect when a Mouse Click is made for a site that always opens a temp container on mouse click?).

I think PJAX is the most widely used of these kinds of AJAX-type requests so the above if it's possible could cover a good chunk of the sites using these requests but you probably know more than me about this.

[stoically]

How individual sites handle dynamic fetching of content for their WebApps differs heavily, as there's no standard. AMO for example uses https://addons.mozilla.org/api/v3/addons/search/?app=firefox&appversion=59.0&page=2&q=containers&lang=en-US&wrap_outgoing_links=true. The _pjax thing is GitHub specific and I've tested some other sites that also do completely different things. Also there's no guarantee that pushState (changing of the Tab URL) is executed before the dynamic loading is successful, which would break navigation on sites completely. So the only way here would be to build site-specific request rules. Maybe something like that could be done in cooperation with Request control.