Re: Removing a window from the session store

2013-10-25 Thread Matthew Gertner
So if I understand correctly, a window that contains a single private tab will 
have no visual indication that the tab is private and will also not be restored 
by the session saver? This would meet my current requirements as long as it's 
possible to set the tab to private after creation (since I won't know until 
shutdown whether I want the window to be restored or not).

That said, this seems like a worse hack than what I am doing now. Why are you 
getting rid of the nsISupportsString in sessionstore-state-write? Is there some 
urgency to doing this? Can't you fix 
https://bugzilla.mozilla.org/show_bug.cgi?id=930713 before you remove it? This 
seems like a pretty big lack in the current session saver API and something 
that should be straightforward to implement.

Cheers,
Matt

On Oct 25, 2013, at 11:40 AM, David Rajchenbach-Teller dtel...@mozilla.com 
wrote:

 We have partial handling of private tabs. SessionStore doesn't handle
 them yet, but I can prioritize this. Would this be sufficient for your
 needs?
 
 Cheers,
 David
 
 On 10/25/13 9:11 AM, Matthew Gertner wrote:
 Can you suggest some other means to do what we need? I don't want to make 
 anyone's life harder but I spent far too long on this problem and didn't 
 come up with another solution.
 
 Matt
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 
 
 
 -- 
 David Rajchenbach-Teller, PhD
 Performance Team, Mozilla

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing a window from the session store

2013-10-25 Thread Tim Taubert
On 25/10/2013 12:24 PM, Matthew Gertner wrote:
 So if I understand correctly, a window that contains a single private tab 
 will have no visual indication that the tab is private and will also not be 
 restored by the session saver? This would meet my current requirements as 
 long as it's possible to set the tab to private after creation (since I won't 
 know until shutdown whether I want the window to be restored or not).

Private tabs will be automatically excluded when bug 899276 has landed.
I don't know off-hand if setting a tab to private works even if the tab
has been around for some time but I think that might be possible.

 That said, this seems like a worse hack than what I am doing now.

Maybe, yes.

 Why are you getting rid of the nsISupportsString in sessionstore-state-write? 
 Is there some urgency to doing this?

There is no urgency but we're currently in the process of rebuilding
big parts of SessionStore to make it perform better. Giving add-ons that
much access to data makes it really hard to implement any kind of caching.

 Can't you fix https://bugzilla.mozilla.org/show_bug.cgi?id=930713 before you 
 remove it? This seems like a pretty big lack in the current session saver API 
 and something that should be straightforward to implement.

I understand that this feature seems important to you but I disagree
that is a big lack in the current API. This is the first time I hear
of a requirement like that.

Could you maybe describe what you are actually trying to achieve and
why? Is there any add-on code we could take a look at? Maybe we can
together find a different and better solution to your problem.

- Tim



 Cheers,
 Matt
 
 On Oct 25, 2013, at 11:40 AM, David Rajchenbach-Teller dtel...@mozilla.com 
 wrote:
 
 We have partial handling of private tabs. SessionStore doesn't handle
 them yet, but I can prioritize this. Would this be sufficient for your
 needs?

 Cheers,
 David

 On 10/25/13 9:11 AM, Matthew Gertner wrote:
 Can you suggest some other means to do what we need? I don't want to make 
 anyone's life harder but I spent far too long on this problem and didn't 
 come up with another solution.

 Matt
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform



 -- 
 David Rajchenbach-Teller, PhD
 Performance Team, Mozilla
 
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 


-- 
Tim Taubert
Firefox Engineer
ttaub...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing a window from the session store

2013-10-25 Thread Matthew Gertner
On Oct 25, 2013, at 12:34 PM, Tim Taubert ttaub...@mozilla.com wrote:
 Private tabs will be automatically excluded when bug 899276 has landed.
 I don't know off-hand if setting a tab to private works even if the tab
 has been around for some time but I think that might be possible.

I guess this is implied by what you said, but just to be sure: if a window 
contains just one private tab, the whole window won't be restored (i.e. it 
won't just open an empty window with no tabs in it)?

 Why are you getting rid of the nsISupportsString in 
 sessionstore-state-write? Is there some urgency to doing this?
 
 There is no urgency but we're currently in the process of rebuilding
 big parts of SessionStore to make it perform better. Giving add-ons that
 much access to data makes it really hard to implement any kind of caching.

Fair enough. It would definitely be much better to have controlled access via 
the API.

 Can't you fix https://bugzilla.mozilla.org/show_bug.cgi?id=930713 before you 
 remove it? This seems like a pretty big lack in the current session saver 
 API and something that should be straightforward to implement.
 
 I understand that this feature seems important to you but I disagree
 that is a big lack in the current API. This is the first time I hear
 of a requirement like that.

Also fair enough. I can't speak to the overall importance of this. It does seem 
like an obvious bug to me that if I call window.close() any time after 
quit-application-requested, the window just opens anyway next time I start 
Firefox.

 Could you maybe describe what you are actually trying to achieve and
 why? Is there any add-on code we could take a look at? Maybe we can
 together find a different and better solution to your problem.

The simple answer is that I'm opening a popup and I want to close it when the 
browser quits since the contents of the popup are specific to that particular 
session.

The more complex answer is that our framework lets people run Chrome extensions 
in Firefox, so I want to be able to do what Chrome does in all circumstances. 
In Chrome if you close a window during browser exit, it stays closed.

Anyway, if there's *some* way to do this then I'm not going to complain. I'm 
willing to descend to arbitrary levels of hackery if there's no other way. :-) 
But I'd be bummed if you get rid of the nsISupports in sessionsaver-state-write 
without there being any other way to work around this bug.

Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing a window from the session store

2013-10-25 Thread Ehsan Akhgari

On 2013-10-25 6:24 AM, Matthew Gertner wrote:

So if I understand correctly, a window that contains a single private tab will 
have no visual indication that the tab is private and will also not be restored 
by the session saver? This would meet my current requirements as long as it's 
possible to set the tab to private after creation (since I won't know until 
shutdown whether I want the window to be restored or not).


Non-private windows containing private tabs is not well supported, 
*please* don't do that.  If all you want is a SessionStore exclusion 
API, then please let's focus on getting that.


Cheers,
Ehsan


That said, this seems like a worse hack than what I am doing now. Why are you 
getting rid of the nsISupportsString in sessionstore-state-write? Is there some 
urgency to doing this? Can't you fix 
https://bugzilla.mozilla.org/show_bug.cgi?id=930713 before you remove it? This 
seems like a pretty big lack in the current session saver API and something 
that should be straightforward to implement.

Cheers,
Matt

On Oct 25, 2013, at 11:40 AM, David Rajchenbach-Teller dtel...@mozilla.com 
wrote:


We have partial handling of private tabs. SessionStore doesn't handle
them yet, but I can prioritize this. Would this be sufficient for your
needs?

Cheers,
David

On 10/25/13 9:11 AM, Matthew Gertner wrote:

Can you suggest some other means to do what we need? I don't want to make 
anyone's life harder but I spent far too long on this problem and didn't come 
up with another solution.

Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform




--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing a window from the session store

2013-10-24 Thread David Rajchenbach-Teller
Please don't do that, we are going to remove the nsISupportsString from 
sessionstore-state-write soon.
(So far, there is a single add-on that uses it, so we're busy preparing 
an API for that add-on before we remove that. Please don't make our 
life harder :) )

On Thu Oct 24 21:56:06 2013, Matthew Gertner wrote:
 The private browsing approach didn't work for me since there is a visible 
 indication in the title bar that the window is private, which I don't want. I 
 ended up solving this by observing sessionstore-state-write and changing the 
 session data manually (possible since it is passed in as the subject using 
 nsISupportsString). Not very convenient but it works.

 I also filed https://bugzilla.mozilla.org/show_bug.cgi?id=930713.

 Matt
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform



--
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing a window from the session store

2013-10-23 Thread David Rajchenbach-Teller
At the moment, there is no good way to do what you need. The only
solution I can think of would be to configure your popup to be in
private browsing mode. Would that work for you?


On 10/23/13 2:33 AM, Ehsan Akhgari wrote:
 On 2013-10-22 12:52 PM, Matthew Gertner wrote:
 I am trying to close a popup browser.xul window during Firefox
 shutdown so that it won't get loaded on restart by the session saver.
 I close the window before the browser shuts down (e.g. on
 quit-application-requested) but it is still opened when I start the
 browser again.

 After trawling through SessionStore.jsm, it looks like the problem is
 that the session store freezes the session on
 quit-application-requested so that it doesn't accidently lose windows
 that are closed as a normal part of the shutdown process. It wasn't
 immediately obvious to me how to circumvent this behavior.

 The only idea I have is to grab the state with
 SessionStore.getBrowserState(), remove my window manually and then set
 it back with SessionStore.setBrowserState(). Is there an easier way to
 do this?
 
 That won't work well, since it will close all but one of the windows and
 tabs and reopen them all again.
 
 Cheers,
 Ehsan
 
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing a window from the session store

2013-10-23 Thread Matthew Gertner
On Wednesday, October 23, 2013 2:36:12 PM UTC+2, David Rajchenbach-Teller wrote:
 At the moment, there is no good way to do what you need. The only
 solution I can think of would be to configure your popup to be in
 private browsing mode. Would that work for you?

That might be a good solution. The side effects (not adding the page to 
history, etc.) are probably things we want anyway.

Should I file a bug about this? It seems to me that it should be possible to 
close a window during shutdown without it being restored on restart. The most 
flexible option might be an API to cause a window to opt out of session saving 
completely.

Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing a window from the session store

2013-10-23 Thread David Rajchenbach-Teller
Yes, please do.
There's a component Session Restore.

Cheers,
 David

On 10/23/13 2:39 PM, Matthew Gertner wrote:
 On Wednesday, October 23, 2013 2:36:12 PM UTC+2, David Rajchenbach-Teller 
 wrote:
 At the moment, there is no good way to do what you need. The only
 solution I can think of would be to configure your popup to be in
 private browsing mode. Would that work for you?
 
 That might be a good solution. The side effects (not adding the page to 
 history, etc.) are probably things we want anyway.
 
 Should I file a bug about this? It seems to me that it should be possible to 
 close a window during shutdown without it being restored on restart. The most 
 flexible option might be an API to cause a window to opt out of session 
 saving completely.
 
 Matt
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing a window from the session store

2013-10-23 Thread Neil

Matthew Gertner wrote:


The most flexible option might be an API to cause a window to opt out of 
session saving completely.
 

Probably not relevant to you but on SeaMonkey the secret sauce to opting 
out of session saving is to remove the windowtype attribute very early 
on (onload handler is early enough I think).


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing a window from the session store

2013-10-23 Thread Ehsan Akhgari

On 2013-10-23 8:39 AM, Matthew Gertner wrote:

On Wednesday, October 23, 2013 2:36:12 PM UTC+2, David Rajchenbach-Teller wrote:

At the moment, there is no good way to do what you need. The only
solution I can think of would be to configure your popup to be in
private browsing mode. Would that work for you?


That might be a good solution. The side effects (not adding the page to 
history, etc.) are probably things we want anyway.


That's not really gonna work well if you actually want the tab to be in 
private mode, since there are some parts of our code which cannot 
correctly handle private tabs in non-private windows.


Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Removing a window from the session store

2013-10-22 Thread Ehsan Akhgari

On 2013-10-22 12:52 PM, Matthew Gertner wrote:

I am trying to close a popup browser.xul window during Firefox shutdown so that 
it won't get loaded on restart by the session saver. I close the window before 
the browser shuts down (e.g. on quit-application-requested) but it is still 
opened when I start the browser again.

After trawling through SessionStore.jsm, it looks like the problem is that the session 
store freezes the session on quit-application-requested so that it doesn't 
accidently lose windows that are closed as a normal part of the shutdown process. It 
wasn't immediately obvious to me how to circumvent this behavior.

The only idea I have is to grab the state with SessionStore.getBrowserState(), 
remove my window manually and then set it back with 
SessionStore.setBrowserState(). Is there an easier way to do this?


That won't work well, since it will close all but one of the windows and 
tabs and reopen them all again.


Cheers,
Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform