Bug 843746 - add 'exit' event to private-browsing module #823

wants to merge 1 commit into

3 participants

  • Added event
  • Updated documentation and unit test both for Firefox Desktop and Mobile
@ZER0 ZER0 Bug 843746 - add 'exit' event to private-browsing module
 - Added event
 - Updated documentation and unit test both for Firefox Desktop and Mobile
Mozilla member

Few things:

  • I still think we should go with non-blocking APIs for system events even though E10S is not a thing as any kind of upcoming concurrent changes will require that. In other words if we emit that event we should do defer it for a one tick.
  • I'm not seeing much value in adding this API, just because platform does is not a good reason IMO. If there are use cases let's put them into docs in examples. If not let's deffer adding this feature until we'll learn about use cases.

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

@erikvold erikvold closed this May 28, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment