Restoring Scroll Position

[smsmith]

For some reason I was under the impression that SeaMonkey would restore my scroll position during session restore. Scroll position on every site is always reset to the top of the page when I close and reopen the browser, no matter if the site allows caching or not.

Should my scroll position be restored? Is there a preference that governs this? Is my week old profile already borked?

Installed Extensions:

Adblock Plus 2.6 true
DOM Inspector 2.0.15pre true
Greasemonkey 0.9.13.1 true
Mouse Gestures Suite 1.3.0 true
Sea Fox 0.2.4 true
Speed Dial 0.9.6.16 true
Stylish 1.4.3 true
ChatZilla 0.9.90.1 false
JavaScript Debugger 0.9.89 false
SeaMonkey Debug and QA UI 1.0pre false

[therube]

There appears to be a bug, on some sites (at least from what I've seen, http://www.seamonkey-project.org being one of them) where position is not maintained after Session Restore.

FF appears to work correctly.

Somewhere, I've got a couple FF related bugs that were pointed out in #seamonkey that I was (will when I get time, unless you or someone else does so first) going to file a bug on this.

I think it was a-865 & myself.
Thinking going back 1 week in time is sufficient to pull up the posts, http://logbot.glob.com.au/?c=seamonkey
Two FF bugs in particular looked interesting.
Feel free to file a bug report.

[Gort]

I can confirm this with a new profile. I've recently noticed this happen myself, but admittedly wasn't too bothered about it (naughty, I admit). Anyway, I've just tried with a clean profile, and the problem is still there. Firefox works fine.

[smsmith]

The chatter I saw in the IRC log was about Firefox having turned off seer (never did figure out what that's supposed to do, but apparently it's a problem). So, I'll try turning that off and report back.

[Gort]

The chatter I saw in the IRC log was about Firefox having turned off seer (never did figure out what that's supposed to do, but apparently it's a problem). So, I'll try turning that off and report back.

Although I didn't turn off Seer when testing with a clean profile (is it enabled by default in SeaMonkey?), my default profile has that already turned off, yet the scroll problem is there.

Here's an interesting page explaining Seer.

[smsmith]

Yeah, I haven't noticed anything improving with it off. Must be something else going on. I don't think I am clearing my cache on exit.

I did find an interesting preference... "Compare the page in the cache to the page on the network", which I believe defaults to "When the page is out of date". Other options are Every time I view the page, Once per session and Never. Default feels like the right choice. Maybe SM is now deciding that pages are out of date more frequently than before? I know the page is supposed to send an expiry date, but maybe there's something afoot there.

I'm glad to see I'm not crazy here and that you guys have noticed this, too!

Thanks for the link on Seer.

I've also noticed, and it was mentioned in the IRC chat... that some pages are dropping their style on restart. The SM project homepage was mentioned, but Bugzilla pages do it, too. I use the "Mozilla" theme (chosen, not the "default") and it drops the background and some of the styling. Bugzilla pages also go from being full on "secure" with the green identity block to being "semi-secure" with the blue identity block.

Seems like there's something more nefarious going on than simply not restoring the scroll position.

[therube]

These were two of the bugs pointed out, so maybe something there we need to pick up on on our end?

Bug 921942 - Scroll position isn't restored in background tabs after session restore

Bug 952401 - Scroll position isn't restored after reloading a scrolled page

[smsmith]

Definitely need the second one. The name of the patch gives it away.
Collect scroll and pageStyle data

I can file something tonight that points to those two bugs in particular. Anyone you want me or need me to CC on the bug?

[patrickjdempsey]

I've also noticed that when you restore the browser the about:config filter bar is not remembered. I feel like this *used* to work but hasn't for several versions.

[smsmith]

It probably did work, because it still works in Firefox.

[patrickjdempsey]

So maybe several things in session restore are broken? Might be worth investigating more features that depend on it?

[smsmith]

I'll file the bug with "these are the things we've noticed and shouldn't be considered all inclusive". Can somebody check on search and form history? Shouldn't that be something that is saved in default conditions?

[therube]

about:config, yes I've seen it both remembered & not.
Have never paid attention to the circumstances.

Search and form history, alone, would not apply.

Search pages opened or form data entered (into a dialog box) but not yet submitted should be remembered when resuming from Session Restore.

[smsmith]

I typed a message in the reply box here, then closed (File -> Exit) and on subsequent restart, the reply box was empty.

Filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1016759

I added Philip Chee to the CC list. Feel free to add anybody else that's relevant.

[patrickjdempsey]

All features listed appear broken in latest Nightly as well. Confirmed that Prefs > Browser > History > Enable search and form history is checked and all Cache settings are at defaults.