Bug 843746 - add 'exit' event to private-browsing module
- Added event
- Updated documentation and unit test both for Firefox Desktop and Mobile
As I mentioned on IRC, let's talk about the simplest use case: storage. As the MDN says, "it is permissable to store private data in non-persistent ways for the duration of a private browsing session". But the devs needs to be notified when the private session ends, in order to do some clean up.
Now, you said that, in case of storage, we should do that internally, without exposing anything to the devs. I can agreed, but here we have a dilemma: let's say that the add-on uses simple-storage to store some data during the private session: if he's able to do so, it's because the add-on have the proper flag on the package.json, therefore is able to behave in the same way than a non private browsing window. So, should we automatically clean up the data stored during the private session, when the session ends? If we do so, then we have the problem that the flags could be misunderstood, because maybe the add-on needs to store persistent data even if we are in the private session. And also, how we can detect if the data was actually added during a private session or not? I don't think we have a "context" there – like, we don't have a context if we set a pure string in the clipboard from add-on.
I this such case, it's easier let to the dev choose. What should be keep, and what should be delete? And of course, in this scenario, he needs to know when the session ends.
And this is bring up the other topic I discussed with Erik: should our modules works as in no-private mode, if they have the proper flag set, or should they have some additional logic – e.g. the cleanup stuff?
Say that, I agree with what @Gozala said in IRC: “[High Level] APIs should not require cleanups”. So I can see why don't exposes an event like exit; however if we do this choice, we should at least document how to use system/events in order to catch the end of a private session.
bug is now closed