i'm not sure if this would be taken care of by the most recent fix to bug 201177. if yes, go ahead and dup this! with my new navigator window pref set to open a blank window, i noticed that opening a new navigator window from any app other than the browser will load the home page instead. 1. in Navigator prefs, set new window to open a blank page. 2. in a non-browser window (mailnews, composer, nim), open a new browser window: either via accel+N or File - New - Navigator Window menu option. expected: the new window should be blank. actual results: the new window loads my home page.
after some queries, i couldn't find if there was an older existing bug on this.
Hrm... So I believe Ian's view on this was that browser windows opened from other apps should be treated as a browser window launched from startup. Except I think in retrospect it would perhaps be closer to what the user expects if it's just treated as a new browser window open. Then there's the grey area of "launching mozilla with --mail and then opening a browser window". Should that (first browser window for this session) be treated as startup or as "new window"? Depending on the answer to the previous question, we may have another problem to solve. If we go with adhering to the "new window" pref, we may have to add some logic to detect whether this was the first browser window opened since upgrading. If so, we should display the "first time since upgrade override page" (a.k.a. "what's new?") that we currently get from handler.defaultArgs (instead of home, blank or previous).
The first option is "Display on Navigator Startup" which to me is the first time a browser window is opened be it from mail or other non-browser part of mozilla. If we want to have New Navigator Window from mail behave the same as New Window from a browser window then perhaps we need to rename this first option in some way to reflect that it is on application startup if navigator is configured to start on application startup. On the technical side I presume that wintype is null if the function is called from startup rather another part of mozilla?
Of course the logic should make even more sense when the browser and mail applications are split.
addendum: all subsequent (non-initial) new browser windows launched from non-browser apps load the home page, not a blank page. i can understand the grey area where the initial launch might follow the "navigator startup" pref. my own preference would be to follow the "new navigator window" pref, though, for initial browser windows.
I think I see the bug you're talking about, even if you have other browser windows open, if you open a new window from the mail window it opens the new window using the navigator startup pref instead of the new window pref. We can tackle this a few ways: a) Check for other browser windows being open and if so follow the new window pref b) Check for whether being called from browser startup or a non-browser window and use navigator startup pref or new window pref respectively. jag: any preferences?
Created attachment 122380 [details] [diff] [review] Patch v1.0 for Option a Patch replaces check for being called from a browser window to checking if another browser window already exists.
Created attachment 122385 [details] [diff] [review] Patch v1.1 for Option a Changes document.firstChild to document.documentElement as advised to by Caillon on irc (don't rely on broken behaviour...and it should be faster)
Attachment #122380 - Attachment is obsolete: true
Setting All/All and taking
Assignee: jaggernaut → ian
OS: Linux → All
Hardware: PC → All
Status: NEW → ASSIGNED
Comment on attachment 122385 [details] [diff] [review] Patch v1.1 for Option a sr=jag Note that when no browser window is open we will still treat "open browser window" as startup, not new window, even for the second time (e.g. open browser, open mail, close browser, open browser [-> as startup]).
Comment on attachment 122385 [details] [diff] [review] Patch v1.1 for Option a I thought for a second that you could use getTopWin() but that's in utilityOverlay.js so it wouldn't be obvious :-/
Attachment #122385 - Flags: review?(neil.parkwaycc.co.uk) → review+
Comment on attachment 122385 [details] [diff] [review] Patch v1.1 for Option a a=asa (on behalf of drivers) for checkin to 1.4b.
Attachment #122385 - Flags: approval1.4b? → approval1.4b+
Checking in tasksOverlay.js; /cvsroot/mozilla/xpfe/communicator/resources/content/tasksOverlay.js,v <-- tasksOverlay.js new revision: 1.52; previous revision: 1.51 done
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
thanks, ian! vrfy'd fixed with 2003.05.13 comm builds.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.