Rewrite all of it?

[kintesh]

Hi everyone,

I created this extension for only one purpose, which was to automatically open a website in a container when visiting from the default Firefox container. Because of this, I kept everything simple as possible; like storing all domain maps at top level on storage, using basic ui and other things. Overtime, more and more people started using this extension so we added more features. Now we are at the stage where it's becoming very difficult to add new things without breaking existing features. I was thinking what if we write all of it again? what do you all think?

Thanks.

Hi,

My knee-jerk reaction is we shouldn't rewrite it, since it's a good code-base imo. But it's your project, so you're free to do as you wish and anybody who doesn't agree can just fork it.

Once we get a settings page, I believe it'll be easier to separate features a little.

Which issues make you want to rewrite the extension? Since you're asking the question you might also already have ideas on what to do too 🙂

[kintesh]

I was thinking mostly the UI.

[NomDeMorte]

I think the highest priority for changes right now, is handling what happens when you open a link to a domain with no rule for that domain. I know you started work on this for 3.1.0 but there was a bug so it was rolled back for 3.2.0, but I think it would be good to keep working on that.

@kintesh oh, ok. UI is not at all my strong-suit, so I'm fine with how things are.

If you think there are improvements to be made and are concerned about reception, you could start on the preference UI. Then with a preference UI in place, you could then introduce an option for theming with the options: light, dark, custom. Custom could be a custom text-box for people to paste their CSS into.

@NomDeMorte I really think that behavior should also be hidden behind a preference with multiple options e.g "Do nothing", "Add to default container" (#20 ), "Create new container for domain" (#80) and "Open in random container" (#59).
Therefore, I believe a preference UI comes first and if nobody else does it, I will. However it will look like shit (should I do it), because I'm not a UI guy.

[NomDeMorte]

I definitely agree that options are important here... And the option you are talking about there is basically a global exit rule. And, given the myriad suggestions on how to handle exiting a container, I'd lay London to a brick that if it's made global, someone will ask for it to become site-or container-specific, as per the suggestion I made there in #20. I, for one, would.

But the thing is, you can't really create a UI for options that don't yet exist. Then, you'd have to recreate or at least change the UI when the options are introduced. I guess one could create a UI with non-functional parts which are not yet supported by the back-end code, and then update the back-end code afterwards, but of course that requires a design for the eventual back-end code to be made first.

So yes, I think a UI design would be great, and supporting various options is also very important as per the links you gave, but I see a need to specify the functionality before the interface to that functionality.

I see a need to specify the functionality before the interface to that functionality

@NomDeMorte eh... I'd rather have something functional than something beautiful. I'll write the a shitty preference UI that just works for #71 and let whoever wants to improve the UI do that. The backend code for preferences is nearly there and I don't want to wait around for people to discuss UI before making something work.

[NomDeMorte]

Well yes I agree, that's exactly my point - you do the function first - at least the design for it - and then you can make an interface to it - and maybe even make it pretty - later. If you try to make it pretty first, then you add functionality, you mess up the 'pretty' and then you have to do that again.... and more work for the same result, is bad, right?

The idea isn't to wait for people to discuss the UI, it is to determine the function, so that you can build a UI - pretty or ugly as it may be - that will serve that purpose. Note that I said:

I see a need to specify the functionality before the interface to that functionality

not

I see a need to specify the interface before the functionality

Having backend code for storing prefs is obviously a necessity for functionality that includes prefs, so that's a good track.... But #71 isn't actually a problem, it's one issue on github which is one small part of a larger problem - the handling of clicking a link with no rule. As per the above, this has arisen out of the extension's growth beyond the original design:

I created this extension for only one purpose, which was to automatically open a website in a container when visiting from the default Firefox container.

It would be a real shame for you to do work and that work to need to be re-done later, but even worse, making changes without planning ahead sometimes means that some work has to be un-done and then re-done, which creates a resistance against future improvements - as exemplified in the post above:

Now we are at the stage where it's becoming very difficult to add new things without breaking existing features.

I think it's great to see your enthusiasm and contribution of code, I'm just providing a contribution of project management by trying to avoid 'putting the cart before the horse'. Planning can be slow and boring when we just want to cut code but it does make sense in the long run.

[StuartMacKay]

It's important the you think about who this add-on is for. If you look at the discussion on the Multi-account Containers, mozilla/multi-account-containers#473 then it's clear that they are dragging their feet on allowing sub-domains and it's probably never going to be implemented because "think of the users!". The ux is driving the add-on so functionality and even purpose gets a back seat.

Today, the UI is simple and easy to understand and right out of the box I was able to get containerise to work exactly as I wanted. So right now, the UI meets my needs 100%. If you want this to replace multi-account-containers then, yeah, the UI is not the best. However you could create an add-on that was used and loved by many thousands of people with what you already have.

[woolkingx]

Hi @kintesh — I went ahead and did the rewrite you were thinking about.

Fork: https://github.com/woolkingx/containTAB

Rewrote the core into pure function modules (matcher, lock, naming, URL parsing) with 54 tests. Replaced the UI with a drill-down popup + dark mode.

New features:

• One-tab-one-world: unmatched URLs auto-create isolated containers
• Container lock: tabs stay in their container
• Temporary container auto-cleanup on last tab close

Code is MIT — if you want to pull anything back into Containerise, go for it. Or if you want the whole repo, happy to hand it over.