Closed Bug 481850 Opened 16 years ago Closed 16 years ago

Port Bug 480893 (Session Restore, start new session does not follow startup page option) to SeaMonkey

Categories

(SeaMonkey :: Session Restore, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.0b1

People

(Reporter: misak.bugzilla, Assigned: misak.bugzilla)

References

Details

Attachments

(1 file, 2 obsolete files)

Attached patch patch (obsolete) — Splinter Review
After selecting "New Session" from Session Restore dialog, the browser opens my homepage in a new tab, rather than following my configuration to open a blank tab on startup. Reproducible: Always Steps to Reproduce: 1. Set pref to open a blank page on startup. 2. Click New Session from within session restore dialog Actual Results: Opens home page url Expected Results: Opens a blank tab
Attachment #365877 - Flags: superreview?(neil)
Attachment #365877 - Flags: review?(neil)
What happens if the browser is set to restore previous session?
Hmm, good question. In firefox code is simple : - getBrowserWindow().BrowserHome(); + var prefBranch = Cc["@mozilla.org/preferences-service;1"].getService(Ci.nsIPrefBranch); + if (prefBranch.getIntPref("browser.startup.page") == 0) + getBrowserWindow().gBrowser.loadURI("about:blank"); + else + getBrowserWindow().BrowserHome(); So it opens home page for everything but blank pref. It's up to us what to pick - blank or home page. Please advise.
I can't decide. Maybe jag can help me out here ;-)
Well, the patch is missing a case. If the pref is set to 3 (restore previous session) we'll end up doing nothing at all. Which is fine, actually, I think loading nothing so we end up with a blank page is the right thing to do. I'd also do it for case 2 (last page visited) since the user just declined to restore it (and all the other pages) from the previous session. Also, I don't think we need to load about:blank explicitly, so something like this: if (Components.classes["@mozilla.org/preferences-service;1"] .getService(Components.interfaces.nsIPrefBranch) .getIntPref("browser.startup.page") == 1) getBrowserWindow().BrowserHome();
else getBrowserWindow().gBrowser.loadURI("about:blank");
('coz we don't want to leave the user on about:sessionrestore, as Neil pointed out to me)
Attached patch jag's comments addressed (obsolete) — Splinter Review
Attachment #365877 - Attachment is obsolete: true
Attachment #366173 - Flags: superreview?(neil)
Attachment #366173 - Flags: review?(neil)
Attachment #365877 - Flags: superreview?(neil)
Attachment #365877 - Flags: review?(neil)
Attachment #366173 - Flags: review?(neil) → review+
Attachment #366173 - Flags: superreview?(neil) → superreview+
Comment on attachment 366173 [details] [diff] [review] jag's comments addressed >+ getBrowserWindow().gBrowser.loadURI("about:blank"); Nit: I'd prefer .getBrowser(). instead of .gBrowser.
Attached patch for checkinSplinter Review
Carrying forward r+/sr+ from jag/Neil, nit fixed.
Attachment #366173 - Attachment is obsolete: true
Attachment #366188 - Flags: superreview+
Attachment #366188 - Flags: review+
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Component: UI Design → Session Restore
QA Contact: ui-design → session.restore
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: