[RFC] Should we persist dynamically generated iframes?

2013-11-13 Thread David Rajchenbach-Teller
*** The problem We are currently faced with a problem on facebook.com (see bug 934935) that brings Firefox to its knees because our session restore accumulates huge amounts of dead data. This problem is most likely a Facebook bug, and we are in touch with the Facebook team to see if they can

Re: [RFC] Should we persist dynamically generated iframes?

2013-11-13 Thread Bobby Holley
I don't know much about sessionstore.js, but I imagine that the issues it faces are similar to those of navigation and session history, which I've been involved with recently from the servo and spec angles. Restoring dynamically generated iframes is undecidable. This doesn't stop Gecko from

Re: [RFC] Should we persist dynamically generated iframes?

2013-11-13 Thread Mike de Boer
Perhaps we could take a nuanced version of this option... Or we could not save dynamic iframes that are not visible. …changing it to ‘Put a reasonable cap on the amount of history we store for invisible, dynamic iframes, using a fifo queue’? Mike. On Nov 13, 2013, at 2:09 PM, David

Re: [RFC] Should we persist dynamically generated iframes?

2013-11-13 Thread Robert O'Callahan
When you say iframes you mean content documents that aren't toplevel content documents, right? Can you explain why sessionstore.js needs to observe non-toplevel-content documents at all? I assume there's an obvious answer, I just don't know what it is :-). Rob -- Jtehsauts tshaei dS,o n Wohfy

Re: [RFC] Should we persist dynamically generated iframes?

2013-11-13 Thread David Rajchenbach-Teller
On 11/13/13 10:27 PM, Robert O'Callahan wrote: When you say iframes you mean content documents that aren't toplevel content documents, right? Indeed. Can you explain why sessionstore.js needs to observe non-toplevel-content documents at all? I assume there's an obvious answer, I just don't

Re: [RFC] Should we persist dynamically generated iframes?

2013-11-13 Thread David Rajchenbach-Teller
We could do that. This might make the behavior of Firefox a little harder to predict for web devs, though. Cheers, David On 11/13/13 7:38 PM, Mike de Boer wrote: Perhaps we could take a nuanced version of this option... Or we could not save dynamic iframes that are not visible. …changing

Re: [RFC] Should we persist dynamically generated iframes?

2013-11-13 Thread Robert Kaiser
David Rajchenbach-Teller schrieb: Or we could not save dynamic iframes that are not visible. It sounds to me personally like this would be the most sensible option. Do we know what, if anything, would break with this on the real web? Do we have any e.g. telemetry data for how often those are

Re: [RFC] Should we persist dynamically generated iframes?

2013-11-13 Thread Robert O'Callahan
On Wed, Nov 13, 2013 at 5:09 AM, David Rajchenbach-Teller dtel...@mozilla.com wrote: Or we could not save dynamic iframes in non-current positions in the history. Does this mean that currently, if a page creates an IFRAME, loads url A into it, then loads url B into it, sessionstore.js will

Re: [RFC] Should we persist dynamically generated iframes?

2013-11-13 Thread Bobby Holley
On Wed, Nov 13, 2013 at 5:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Does this mean that currently, if a page creates an IFRAME, loads url A into it, then loads url B into it, sessionstore.js will contain state for both A and B? That does seem excessive. Yeah. If we _do_ decide to