Create a new profile. Open Firefox with that profile. Set the new profile to show your tabs from the previous session. Put http://wiki.answers.com/Q/What_is_the_party_song_in_sarah_silverman_program_episode_mongolian_beef into a tab and have nothing else. Close Firefox. Each subsequent open and then close of Firefox will almost double the size of the sessionstore.js file in the new profile's directory. This leads to huge sessionstore.js files and frequent 5 second pauses of the browser.

Doesn't happen in 3.6.

The 2010-07-31 nightly seems to grow only about 5k each restart, not nearly doubling.

On my Windows XP box the problem is much less serious. Instead of doubling it's only going up around 20% in size each time after a few iterations. The 12th restart the size of sessionstore.js only went from 627,544 to 755,830, an increase of only 128,286 bytes. (All in one line, that's one long line.) In spite of the reduced growth, this could be a serious problem if party songs about Mongolian beef are popular. I created another new profile and tried some other pages. about:home kept a constant size through several restarts, as did Google. For http://wiki.answers.com/ the size jumped up and down, no clear trend. I tried the first question on the site (<http://wiki.answers.com/Q/Is_mercury_fun >) and the pattern was similar to the URL in comment 0 (doubling for the first few times then slowing down but still with significant increases).

It is not specific to that question for me either, I tried another unrelated question on wiki.answers.com and it had a similar problem (although not quite doubling).

Paul, can you dig in here and figure out what's happening? If it's highly localized/edge casey and you think it shouldn't block, re-nom - otherwise it sounds like we need to understand and fix it.

So this is shitty, but I'm hesitant to block on this. After a quick investigation, I'm guessing it's a very site specific thing (but I'm not 100% sure of that yet). Disregarding sessionstore for 1 second, when you load that url it adds 4 (yea really) history entries for that page. I'm guessing this is intentional to force multiple back button clicks & be annoying. (I want to give them the benefit of the doubt but this is answers.com, sooo they don't get that benefit) So when sessionstore looks at that, it goes through each of them and processes each history entry (which subsequently looks up the history stuff for each child and unfortunately there are plenty of ads and subframes on that page). So then when we restore that and load that page it does the whole thing again and we end up with 8 history entries. Rinse & repeat. Worth noting is that each history entry has the same docshellID and docIdentifier for everything (entry & children entries). Not sure if there's anything to take from that. CC'ing Boris & Olli since this bleeds over into session history and might be something on that end.

Do you get the 4 history entries in 3.6 too?

(In reply to comment #7) > Do you get the 4 history entries in 3.6 too? No

Any idea what the regression range for that is?

(In reply to comment #9) > Any idea what the regression range for that is? Quick range is between beta 2 and beta 3. Looking for something better now.

July 23rd nightly shows 2 entries (as does the 18th, which was before b2, so I'm not sure why b2 only shows 1). July 24th shows 5 entries. So that gives us: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58101a16aff7&tochange=30239e4cebd8 Nothing in there jumps out at me

What about bug 580819?

(In reply to comment #12) > What about bug 580819? I can confirm that when undoing that patch, the problem basically disappears. Current trunk, size of session file per restart (in K): 13, 36, 71, 120, 180. When undoing that patch: 7, 9, 13, 18, 23. Note that it still grows though, so even before things were not perfect. Perhaps we should have a hard limit on the size somehow, and fix things that way?

Some other size experiments: I visited the URL and restarted Firefox until my session save was 160K, closed the tab and restarted several times. The session save stay about the same size. I them opened and closed several tabs (so answers.com was no longer in my "saved for undo list") and restarted -- down to 14K. I then kept opening answers in new tabs, closing the old tabs, and restarting. The size of the file grew -- the growth was much faster than 3.6, but didn't seem to be as fast reloading on one answer. The growth rate would be a problem (eventually) for someone who constantly keeps using wiki.answers.com and never spends time browsing elsewhere. How big does the session restore file have to get before the size of the file is a problem? How many other web sites have a similar problem? It seems like it would be a good idea to try to prevent the session restore file from getting gigantic for Firefox 4.0.0, but clearing the session history if it gets larger than a megabyte would probably avoid running into a serious problem and not affect many users. Then after 4.0.0, try to figure out how to stop unnecessary growth. (Of course, a simple, easy to verify solution to the growth created soon would be better.)

By "clearing the session history" do you mean not saving the back/forward history for tabs? Or not saving the tabs at all? Because the latter seems unacceptable.

Here is a prettified diff of the change from one run to another. The main causes of growth are the new elements with ID 13, 14, etc., which are in windows[0].tabs[0].entries[0].children - that is, new children are being created.

Here is one possible solution to this issue: Strip out parts of the sessionstore.js file, if it exceeds a certain maximum size. This should hopefully protect us from most silliness that sites can do that bloats the sessionstore.js file, and not just this specific bug. Thoughts?

For what it's worth, that MAX_FILE_SIZE is about 30 time smaller than my usual session restore file....

So I looked more closely at the session I had, and interesting thing I noticed between entries is that one of the children started with url: "about:blank" and then the next entry had url: "javascript:'<script>admeld_publisher%20%20=%2090;admeld_site%20=%20\"wikianswers\";admeld_size%20=%20\"300x250\";admeld_placement%20=%20\"atf_ent-music\";</script><script%20src=\"http://js.admeld.com/meld120.js\"%20target=\"_self\"%20></script>'" And then there were 2 more child entries that did this (each one at a time). Session history adds a separate entry for subframe navigation and so in total that's 4 entries. This doesn't seem like a coincidence. I'm going to try and reduce this to something that doesn't rely on answers.com. As for just capping the file size, I'm not really in favor of that, especially at 128k

I wasn't serious about the specific 128K number - that was for my testing. The idea I was proposing in the patch was that we have *some* number beyond which we start reducing the size. Aside from this bug here, it might reduce the cases of people reporting that "Firefox is slow, but a new profile makes it fast again."

Marking for .x due to driver discussion. Please renominate if you disagree

The other bug here is that writing the sessionstore file blocks the entire app. Is there a bug for changing that?

(In reply to comment #22) > The other bug here is that writing the sessionstore file blocks the entire app. > Is there a bug for changing that? We write async so that definitely shouldn't be the case... https://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/src/nsSessionStore.js#4025

(In reply to comment #23) > We write async so that definitely shouldn't be the case... In addition we use the new DEFER_OPEN option now, so not just the file writing but also the file creation is off the main thread.

So I guess it wasn't the actual writing out of the file to disk, but breaking in gdb and calling DumpJSStack was almost always in sessionstore code. So maybe it was another phase of creating and writing the sessionstore file. Maybe the actual generating of the string to write? I can do the same again with gdb and a large sessionstore.js to get some stacks if needed.

It seems like there are two separate issues here. One is that this page creates more SHEntries than perhaps it should. This seems to be a regression from bug 580819, and I've been working on what appears to be the same issue in bug 673467. There's a separate issue, though: A page might legitimately create many large SHEntries, and it appears that this slows down the browser. If nobody objects, let's track the illegitimate extra SHEntries in bug 673467, and the slowness associated with them here.

do you stilll see this problem using a current release, given that some related bug reports have been fixed?

With today's Nightly I can not reproduce the problem as described in the original bug report (and I was able to reproduce it before). Also, none of the sessions I have lying around on this computer have a large sessionrestore.js.

Yeah, the specific issue in comment 0 doesn't reproduce anymore. Whether that is due to wiki.answers.com changing their site or changes in our code I don't know.