[Support] Original TAB goes Blank on AMO

[B00ze64]

Good day.

This must've been discussed before but I looked at opened and closed bugs (not ALL closed bugs) and did not really find an answer. I use MAC and TC together. This works OK but I have not been using for long. Something I've noticed and would like to behave differently: If I am in a permanent container (this might occur in a temporary container too) and I click on a link to a different domain which is set to open in the same TAB (not by me, it just so happens not to have target-blank,) what happens is navigation is intercepted, a new TAB (temporary container) is opened, but my original tab remains (this is great) however, that original TAB is now empty of content and has lost all history. I would love it if all navigation to different domains was turned into "a new TC tab" (it kinda is) but with the original TAB remaining intact. I'm sure I'd find some situations where this would cause problems, but right now, with the original TAB getting "cleared" it is pretty annoying. I've got global isolation on navigation to different domain, and automatic mode, enabled, and that's pretty much all that's enabled.

I am used to right-clicking and selecting Open in New TAB (the first entry in the Link context menu), however, MAC replaces the context menu, and now I have to right-click and go to a Sub-Menu and select Open In No Container and I find this annoyingly long to do - And Open in temporary container (your own context menu entry) is all the way at the bottom of the context menu. If this all happened auto-magically without me having to right-click it would be awesome, and it kinda is happening auto-magically, except that the original TAB goes all blank...

PS: You should update the Wiki to mention %domain% in container name (neat feature). In fact you should probably update the Wiki and the UI to simplify the setup somewhat, I'm not using more than 1% of the options because I keep having to re-read the Wiki to understand why there are so many different options. For example, I have no idea what "Isolation -> Domain -> Always Open In" does. I expect Always Open In to have the following choices: Temporary Container OR Permanent Container OR No Container, but the option is Enable/Disable, I don't get it - If I want to exclude a domain I can use the exclusions, so I really do not understand why this is there. There's other stuff I'm not quire sure about; you might want to open-up your Wiki so ppl can assist writing it...

Thank you. Best Regards,

[stoically]

Hey,

that sounds like you might be affected by #317, where the cause is setting fission.autostart to true in about:config?

You should update the Wiki to mention %domain% in container name (neat feature).

Yeah, I didn't add it at the time because it only works in special circumstances, namely when isolation happens. While it might signal that it somehow works generally when its documented for the container name itself.

In fact you should probably update the Wiki and the UI to simplify the setup somewhat

Yeah, I hope to simplify at least the isolation UI a bit with #397, which would allow to merge some things and hide some others.

For example, I have no idea what "Isolation -> Domain -> Always Open In"

"Always Open In" is short for "Always Open In Temporary Containers", and basically is a toggle to open a specific domain in a temporary container, e.g. if you're not using automatic mode.

you might want to open-up your Wiki so ppl can assist writing it

In theory I'd be fine with this - but since that wouldn't be PR-based and doesn't have any sort of notifications, it could easily get defaced. I've started once to convert the wiki into docs (with a folder in the repo), but haven't had the time to finish that. Would be nice to have tho.

[B00ze64]

Good day Sir.

Hmm, not related to fission.autostart (false). I am upgrading my Firefox from FF52 to FF77 now that Mozilla has fixed Addon CSP injection, so I have to test tons of Addons and try out new things, like Containers. So I am on AMO alot and this is where the TAB goes blank. I think it's happened on some other places, but I do not have an example; maybe it happens only on AMO? I've been there so much lately.

So it might have to do with your Addon doing something special with that ridiculous outgoing.prod.mozaws crap they implemented? If you enable Automatic Mode and Global Isolation when not same sub-domain, then go to AMO and click an outgoing link, does it not clear the original TAB for you? For me it clears the TAB (it kinda flashes,) then opens the redirector TAB, then a 3rd TAB to where the link goes, and then it closes the redirector. The original TAB keeps it's title; it's still called whatever Addon page I was on at the time, but the URL is empty and there's nothing inside the TAB and no history. If I close the TAB, I can re-open it to where it was supposed to be from the history recently-closed. I was sure this was known behaviour, I've tried on a blank profile with just temporary-containers and it still does that.

For %domain% I do not see when it would NOT work, I mean your Addon is all about isolation, I'll have to take your word for it that it sometimes does not work (about:blank does not count, we know it's special).

For Domain-Always-Open-In, I do not see why we'd go to configure some domains on that page and NOT want to isolate them. I guess we could go there and configure the domain not to isolate but all outgoing requests to do so? That's kind of what I mean when I say configuration is fairly complex, I am too new at this and have not run into all those use-cases you support.

For the Wiki, I hear you, but this is a complex Addon, and it must be time-consuming to answer ppl like me and feature requests etc. So if the community could help you with the documentation, might be a good thing. Since MAC is a Mozilla Addon, it will take about 17 years for it to catch-up and do temporary containers (Mozilla being a corporation, with committee based decisions, lowest common denominator, etc) - I predict a need for your Addon for many years to come; good documentation will be important in reducing support tickets lol, you might have 200,000 users at some point! There's always FPI, but it's global and so unusable; TC is a lot more flexible...

Thank you. Best Regards,

[stoically]

So I am on AMO alot and this is where the TAB goes blank. I think it's happened on some other places, but I do not have an example; maybe it happens only on AMO? I've been there so much lately.

I can reproduce it on AMO, so it might affect other sites too, but I suspect it's because the AMO domain is special (about:config extensions.webextensions.restrictedDomains). What happens is that the navigation to outgoing.prod.mozaws gets cancelled and reopened in a new TC. At that point the old tab should have at least still the history. Unfortunately, that's not something TC can fix, but would need to be reported upstream to the Firefox bugtracker.

For %domain% I do not see when it would NOT work, I mean your Addon is all about isolation, I'll have to take your word for it that it sometimes does not work (about:blank does not count, we know it's special).

It doesn't work for regular Automatic Mode, where the tab instantly gets reopened into a TC (which is the default, but only works with "Firefox Home" as start page, not with "Blank page").

For Domain-Always-Open-In, I do not see why we'd go to configure some domains on that page and NOT want to isolate them. I guess we could go there and configure the domain not to isolate but all outgoing requests to do so? That's kind of what I mean when I say configuration is fairly complex, I am too new at this and have not run into all those use-cases you support.

"Always open in" doesn't exclude things. It "includes" things. If you don't configure Automatic Mode or Isolation, but just one Per Domain Isolation rule with "Always open in" for the domain "Enabled", then that domain will always open in a new TC if you try to navigate there, while all other navigations will be left untouched.

For the Wiki, I hear you, but this is a complex Addon, and it must be time-consuming to answer ppl like me and feature requests etc. So if the community could help you with the documentation, might be a good thing.

Well, for this issue there wouldn't have been something in the documentation, since its a bug. But sure, more docs don't hurt - though, setting them up, make them look good and link them everywhere, might currently take more time than reply to issues here and there. However, I'll gladly review a PR setting up docs (favorably done with VuePress), and ideally additionally added to the TC preferences themselves.

I predict a need for your Addon for many years to come; good documentation will be important in reducing support tickets lol, you might have 200,000 users at some point! There's always FPI, but it's global and so unusable; TC is a lot more flexible...

I'm glad you find it useful!

[B00ze64]

Good day.

I can reproduce it on AMO, so it might affect other sites too, but I suspect it's because the AMO domain is special (about:config extensions.webextensions.restrictedDomains). What happens is that the navigation to outgoing.prod.mozaws gets cancelled and reopened in a new TC. At that point the old tab should have at least still the history. Unfortunately, that's not something TC can fix, but would need to be reported upstream to the Firefox bugtracker.

I've disabled restrictedDomains (blank) and also mozAddonManager, so that I can run Skip-Redirect on AMO. And Skip-Redirect DOES intercept the requests, but not quickly enough, the original TAB goes blank anyway. I did find a solution: Install your favourite Monkey Addon and run https://github.com/Infocatcher/UserScripts/tree/master/Direct_Links (or other similar script) which edits the page to remove those redirections. Still kind'of a strange bug. If I get it on another domain I'll let you know. I've had various bugs trying-out Container Addons (like Facebook container) together, it's hard to remember exactly which bug happened where.

It doesn't work for regular Automatic Mode, where the tab instantly gets reopened into a TC (which is the default, but only works with "Firefox Home" as start page, not with "Blank page").

For %domain% it works for me everywhere, including About:Blank - i.e. I fail to see why we need to use FF Home, Isolation on Navigation instantly catches navigation OUT of About:Blank and creates a container, works beautifully, and the Container is named correctly after the target domain. And AFAIK, I am using regular Automatic Mode, lol. Your Addon works extremely well I find, and it plays nice with MAC.

"Always open in" doesn't exclude things. It "includes" things. If you don't configure Automatic Mode or Isolation, but just one Per Domain Isolation rule with "Always open in" for the domain "Enabled", then that domain will always open in a new TC if you try to navigate there, while all other navigations will be left untouched.

But that's what I mean, why would you configure a domain and leave Always-Open-In disabled? If you put a domain in there, it's to isolate it! The only use-case I can see for leaving Always-Open-In disabled is if you want NOT to isolate the domain in question but make sure Clicks out from that domain do get isolated. It's kinda confusing because you have 2 things on the Domain Isolation Setup page, isolation of the domain as a TARGET (Always-Open-In) and isolation OUT of the domain (the rest of the setup). For now Automatic Mode is sufficient for me ;-)

PS: I added "addons.cdn.mozilla.net" to Ignored Requests, so that when I click to install an Addon it does not open a TC. Probably should be in the default configuration?

Thank you. Best Regards,

[stoically]

And AFAIK, I am using regular Automatic Mode, lol

Sorry, I've mixed that up. "Firefox Home" for new tabs is Firefox's default and Automatic Mode works differently in that case (instantly reopens the tab, so there's no %domain to use in that case). Using "Blank page" does have privacy implications which are described when you change the preference under Advanced > Automatic Mode (which makes it so that "Firefox Home" behaves the same as having "Blank page" - and personally I prefer that mode as well).

The only use-case I can see for leaving Always-Open-In disabled is if you want NOT to isolate the domain in question but make sure Clicks out from that domain do get isolated.

Ah, right, fair point. There are other use cases, e.g. only changing how "isolation out" works for a domain (which could be loaded in "no container" or a permanent container), but not isolate the domain itself. However, I do agree that isolation currently can be confusing, I hope to address that with #397 at some point.

PS: I added "addons.cdn.mozilla.net" to Ignored Requests, so that when I click to install an Addon it does not open a TC. Probably should be in the default configuration?

In the Firefox default configuration there's no isolation happening since those domains are on the restrictedDomains list, so I don't think it makes sense to add them to "ignored requests"

Thank you.

Thanks for the feedback

Btw, if you're going to file the redirect/blank-tab issue on Bugzilla, please leave a link here to it!

[B00ze64]

Lol, If you are going to open a bug ;-) Kinda telling me to do that eh ;-)

https://bugzilla.mozilla.org/show_bug.cgi?id=1649054

[stoically]

Thanks for filing. According to the analysis this is a regression and will be fixed in Firefox 79 - therefore closing this issue.

[B00ze64]

Lol, I was going to wait until I could test 79 myself before reporting back here. But I guess we can close, they DID confirm it was a bug in Firefox and not in Temporary Containers. I hope the TAB remains as-is in 79, and does not turn into some sort of error TAB; the report mentions something about generating an un-handled error which is why the TAB gets cleared - the TAB turning into a 404 or something like that will not be much better than now lol. Regards,

[B00ze64]

Confirmed Fixed in FF79 :-)