Onboarding-page force-close before you have read it (with MV3 it becomes a critical issue I think)

Add-ons Development
#1

For a long time I have noticed a problem with mine and other extensions too. On a new install, an “onboarding page” might unwanted close when you select if an extension is to be allowed to run in Private Windows or not. I don’t know about others, but I instinctively always make my choice in the little “popup” to get rid of that, before I look at content on onboarding page:

private-popup-open
private-popup-open1909×1359 273 KB

But in the moment I make my choice in the popup, the onboarding page has disappeared:

private-popup-closed
private-popup-closed1905×1268 221 KB

It doesn’t happen for every extension, and I think it depends on if onboarding page is an “internal extension page” or it a standard “external web page”. So a work-around could probably be to make my onboarding page an external webpage. I did however deliberately choose it to be an internal extension-page for privacy reasons, and I would probably also need to change privacy policies for my extensions if I make the switch. So I’m not very keen on doing that.

I’ve been annoyed by but living with the issue so far. Also because it doesn’t happen so often I install an extension (so I’m not reminded of it), and I’m always in doubt if it is still a problem or if it has been fixed when I remember about it. But now I saw the issue again a few days ago when adding one of my extensions to a new Firefox Beta (Developer Edition) installation (the above screenshots).

Anyone know a way to avoid this without using an external webpage?

With the introduction of MV3 and the way host-permissions are going to work, I feel it can become critical that new users get the onboarding experience. When “No, I didn’t just install Flickr Fixr because I think it looks cool in my list of installed extensions, I actually really want to run it”(*) kind of confirmations becomes necessary, I think it needs some kind of help and explanation.

(*) Yes, sorry. I’m being slightly sarcastic here. But I really don’t get the reasoning for the way its planned to handle host-permissions.

And I’m the only one concerned about this bug? Maybe even the only one experiencing it?

#2

This happens because changing that permission causes the extension to restart, which closes any internal pages for that extension. If the onboarding page is an external page, then it won’t disappear.

There’s no built-in way to prevent this. You would need to somehow track if the onboarding page has been displayed. An alternative workaround could be to display a blank external page and have the extension inject the content onto the page (if you already have the permissions to do that).

But unfortunately, any workaround is going to be a “hacky” type of workaround.

2 Likes
#3

It’s this bug:

Regarding a workaround, you could check incognito status on addon start and store the result in the store. Then when it’s changed to “true”, re-open onboarding page again.
Or something like that :slight_smile:

1 Like
#4

Thanks @ComputerWhiz and @juraj.masiar
Maybe I could make it work somehow saving incognito state when onboarding page is shown on extension-install, and if I on (next only) browser-startup (using runtime.onStartup) the status is changed to allow use in private windows, I could show the onboarding a second time (with an explanation for why they might see it a second time).

Actually, in one of my extensions, I have already added use of runtime.onStartup for a hack simulating a “storage.session” functionality (Reserving part of my storage.local for “session data”, and clearing that data on every browser startup).