new browser windows launch from non-browser apps always load home page

VERIFIED FIXED

Status

VERIFIED FIXED
16 years ago
14 years ago

People

(Reporter: bugzilla, Assigned: iann_bugzilla)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
after some queries, i couldn't find if there was an older existing bug on this.

Comment 2

16 years ago
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).
(Assignee)

Comment 3

16 years ago
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?
(Assignee)

Comment 4

16 years ago
Of course the logic should make even more sense when the browser and mail
applications are split.
(Reporter)

Comment 5

16 years ago
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.
(Assignee)

Comment 6

16 years ago
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?
(Assignee)

Comment 7

16 years ago
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.
(Assignee)

Comment 8

16 years ago
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
(Assignee)

Comment 9

16 years ago
Setting All/All and taking
Assignee: jaggernaut → ian
OS: Linux → All
Hardware: PC → All
(Assignee)

Comment 10

16 years ago
Accepting
Status: NEW → ASSIGNED
(Assignee)

Updated

16 years ago
Attachment #122385 - Flags: superreview?(jaggernaut)
Attachment #122385 - Flags: review?(jaggernaut)

Comment 11

16 years ago
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]).
Attachment #122385 - Flags: superreview?(jaggernaut)
Attachment #122385 - Flags: superreview+
Attachment #122385 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #122385 - Flags: review?(jaggernaut)

Comment 12

16 years ago
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+
(Assignee)

Updated

16 years ago
Attachment #122385 - Flags: approval1.4b?

Comment 13

16 years ago
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+

Updated

16 years ago
Attachment #122385 - Flags: approval1.4b+ → approval1.4+
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
(Reporter)

Comment 15

16 years ago
thanks, ian! vrfy'd fixed with 2003.05.13 comm builds.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.