Incomplete Startup/Terminate Housekeeping For Multi-Profile Browsing

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
9 years ago
9 years ago

People

(Reporter: david, Unassigned)

Tracking

SeaMonkey 2.0 Branch
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0

I had two tabs open.  I closed the tab on the right.  Then I switched profiles (I have four).  When I switched back to the first profile, the closed tab was open.  

Reproducible: Sometimes
(Reporter)

Comment 1

9 years ago
After reporting this bug, I terminated SeaMonkey.  I checked Windows Task Manager; SeaMonkey was not in either the Applications or Processes tab.  When I started SeaMonkey again (about an hour later) in my primary profile, I then switch to another profile.  Two tabs opened, one of which I had closed before terminating SeaMonkey.  

My preferences for both profiles at set to display my home page on browser startup, new window, and new tab.  Neither of the two tabs that opened in the second profile were my home page.  I changing the Importance from Minor to Normal.
Severity: minor → normal
(Reporter)

Comment 2

9 years ago
Created attachment 409622 [details]
Three test cases to demonstrate the problem.
(Reporter)

Comment 3

9 years ago
In developing the three test cases (plus setup), I determined that the problem lies within Startup & Profiles and not Tab Browser.  I thus changed both the Summary and Component.  

When a single SeaMonkey execution involves browsing via more than one profile, only the current profile appears to have complete housekeeping when SeaMonkey is terminated.  Further, switching profiles back and forth fails to initialize completely each new profile instance.  It appears that this problem falls primarily on profiles that are not currently open.  

The attachment indicates observed results.  Expected results are:  

1.  Setting the preference to launch the browser or a profile with a selected home page should indeed cause that home page to be displayed, even if a different page were displayed when the browser was terminated or when the selected profile previously had a different page.  

2.  When a tab is closed within a particular profile, that tab should not display when that profile is again reopened.
Component: Tabbed Browser → Startup & Profiles
QA Contact: tabbed-browser → profile-manager
Summary: Closed Tab Reopens on Switching Profiles → Incomplete Startup/Terminate Housekeeping For Multi-Profile Browsing
(Reporter)

Comment 4

9 years ago
When the profile without full initialization (e.g., to display its home page) is launched, the page actually displayed comes from the cache.  This happens although a version of the page exists in the Internet that is newer than the cached page.  

While developing the test cases in the 2009-11-01 attachment, I determined that this problem is ALWAYS reproducible, not Sometimes.

Comment 5

9 years ago
FWIW, I've been seeing occasional blank homepages in a 2.0 configuration that does not involve any sort of profile switch or tabs.  Just a straight up homepage setting that seems to get forgotten until one re-establishes the setting (even though the correct value is displayed in the pref.)   haven't had a chance to work out repeatability...  My gut says that this is a session restore problem, but that is pure speculation.  Hopefully, your steps will lead to a solution.  I think I've gotten this since running the 2.0.1 RC, but I'm not sure.  Sorry for the vagueness, I just haven't had any time for SeaMonkey lately.
Version: unspecified → SeaMonkey 2.0 Branch
(Reporter)

Comment 6

9 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4

I have not seen this problem recently.  Before upgrading to SeaMonkey 2.0.5, I reran the three test cases in my 1 Nov 2009 attachment.  All three gave the expected (good) results, not the previously observed (bad) results.  

Since I was able to demonstrate the problem consistently with SeaMonkey 2.0, I believe this was a real problem that somehow was fixed between 2.0 and 2.0.4.  Thus, I don't think this is resolved as merely WorksForMe.  I'll leave it to someone else to determine what was the specific fix.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
If you don't know the exact fix, don't use FIXED.
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.