Closed
Bug 84664
Opened 23 years ago
Closed 23 years ago
Double-clicking mozilla.exe should open new window
Categories
(Core :: XUL, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: mdeslaur, Assigned: morse)
References
Details
(Keywords: regression, Whiteboard: fix in hand, have r, sr, have a)
Attachments
(2 files)
With mozilla already open, double-clicking mozilla.exe a second time should pop up a new browser window. This was working in 0.9, but not in 0.9.1.
reporter are you using -turbo?
Assignee: asa → law
Component: Browser-General → XP Toolkit/Widgets
QA Contact: doronr → sairuh
Whiteboard: DUPEME
I "broke" this with recent DDE changes. It is easy to distinguish the requests that must go to an already-open window versus ones that ought not. I'm nominating this for RTM.
Keywords: mozilla0.9.2,
nsbeta1
Whiteboard: DUPEME → time:.5days
ok
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Summary: Double-clicking mozilla.exe should start new instance → Double-clicking mozilla.exe should open new window
Updated•23 years ago
|
QA Contact: sairuh → jrgm
nav triage team: Gotta fix this. Bill, can you get to this before you go on vacation? Marking p2, mozilla0.9.2
Priority: -- → P2
Target Milestone: --- → mozilla0.9.2
nav triage team: Forgot to add nsbeta1+
I added a PRBool "newWindow" flag to to implementation methods within nsNativeAppSupportWin.cpp. "newWindow" is always PR_TRUE *except* for requests that come in via XTYP_REQUEST WWW_OpenURL DDE requests. So, we always will open a new browser window except in cases where the request comes via that route (e.g., Adobe Acrobat or other DDE clients).
Comment 10•23 years ago
|
||
*** Bug 85407 has been marked as a duplicate of this bug. ***
Comment 11•23 years ago
|
||
*** Bug 85615 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
Nit: + // If caller requires a new window, then don't use an existing one. + if ( newWindow ) { + break; + } if ( !med ) { break; } Consolidate these? Either way, sr=blake
Comment 13•23 years ago
|
||
Yeah, I debated that. My conclusion is that the compiler will do the re-write and to leave it as a separate check more accurately reflects the evolution of the code. It matches the rest of that do{}while block as a separate check, too. So I think I'll leave it that way, at least until the next time it has to be tweaked.
Comment 14•23 years ago
|
||
adding Samir for r=.
Whiteboard: fix in hand → fix in hand, have sr, need r/a
Comment 15•23 years ago
|
||
r=sgehani
Updated•23 years ago
|
Whiteboard: fix in hand, have sr, need r/a → fix in hand, have r, sr, need a
Assignee | ||
Comment 17•23 years ago
|
||
Patch has suffered some bitrot, although it was created only seven days ago! Attaching identical patch but without the bitrot.
Assignee | ||
Comment 18•23 years ago
|
||
Comment 19•23 years ago
|
||
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Blocks: 83989
Updated•23 years ago
|
Whiteboard: fix in hand, have r, sr, need a → fix in hand, have r, sr, have a
Assignee | ||
Comment 20•23 years ago
|
||
Oops, forgot to mark this as fixed. The fix was checked in last night, just before the freeze.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 21•23 years ago
|
||
*** Bug 87106 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•