Closed
Bug 675493
Opened 13 years ago
Closed 13 years ago
Port [Bug 655550 - Persisted tab attribute gets lost after restart twice] and one relevant line from [Bug 644998 - Session should not be restorable after "Clear Recent History"]
Categories
(SeaMonkey :: Session Restore, defect)
SeaMonkey
Session Restore
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: misak.bugzilla, Assigned: misak.bugzilla)
References
Details
Attachments
(2 files, 1 obsolete file)
5.48 KB,
patch
|
neil
:
review+
|
Details | Diff | Splinter Review |
1.26 KB,
patch
|
misak.bugzilla
:
review+
|
Details | Diff | Splinter Review |
From parent bugs:
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
See the following steps.
Reproducible: Always
Steps to Reproduce:
1. Execute in JS shell:
> gBrowser.selectedTab.setAttribute("visited", true);
> Cc["@mozilla.org/browser/sessionstore;1"]
.getService(Ci.nsISessionStore)
.persistTabAttribute("visited");
2. Restart Firefox and check the "visited" attribute
3. Restart Firefox again and check the "visited" attribute
The "visited" attribute is restored correctly after step 2, but lost after step 3, is it intended?
and:
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Do a cleaning of -all- temp data of all periods (from an empty tab). Then, you'll see that a restore of a prev. session is available.
Reproducible: Sometimes
Steps to Reproduce:
1. Open a new empty tab.
2. Clean -all- temp data.
3. Sometimes, a prev. session restore is available.
Actual Results:
Disfunction / error.
Expected Results:
All blank.
none
Attachment #549642 -
Flags: review?(neil)
Comment 1•13 years ago
|
||
Comment on attachment 549642 [details] [diff] [review] patch >+ this._lastSessionState = null; r=me on the persisted attribute changes. But this isn't enough for the clear private data changes, because the menuitem will still be enabled.
Attachment #549642 -
Flags: review?(neil) → review+
Assignee | ||
Comment 2•13 years ago
|
||
I decided to push this. http://hg.mozilla.org/comm-central/rev/0726a2df959e Further fix will be introduced shortly.
Assignee | ||
Comment 3•13 years ago
|
||
Attachment #567279 -
Flags: review?(neil)
Comment 4•13 years ago
|
||
Comment on attachment 567279 [details] [diff] [review] hide "restore previous session" menu item after clearing private data > this._forEachBrowserWindow(function(aWindow) { > Array.forEach(aWindow.getBrowser().tabs, function(aTab) { > delete aTab.linkedBrowser.__SS_data; > if (aTab.linkedBrowser.__SS_restoreState) > this._resetTabRestoringState(aTab); > }); > openWindows[aWindow.__SSi] = true; Why not append the disabling code to this existing loop?
Attachment #567279 -
Flags: review?(neil) → review+
Assignee | ||
Comment 5•13 years ago
|
||
Hmm, You right as always. Carrying forward r+
Attachment #567279 -
Attachment is obsolete: true
Attachment #567326 -
Flags: review+
Assignee | ||
Comment 6•13 years ago
|
||
Pushed: http://hg.mozilla.org/comm-central/rev/ef00acb3f67a
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•13 years ago
|
||
Sorry: correct diff is http://hg.mozilla.org/comm-central/rev/a3c4a41ba069
You need to log in
before you can comment on or make changes to this bug.
Description
•