Closed
Bug 84664
Opened 24 years ago
Closed 24 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•24 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•24 years ago
|
||
*** Bug 85407 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
*** Bug 85615 has been marked as a duplicate of this bug. ***
Comment 12•24 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•24 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•24 years ago
|
||
adding Samir for r=.
Whiteboard: fix in hand → fix in hand, have sr, need r/a
Comment 15•24 years ago
|
||
r=sgehani
Updated•24 years ago
|
Whiteboard: fix in hand, have sr, need r/a → fix in hand, have r, sr, need a
| Assignee | ||
Comment 17•24 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•24 years ago
|
||
Comment 19•24 years ago
|
||
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
Updated•24 years ago
|
Whiteboard: fix in hand, have r, sr, need a → fix in hand, have r, sr, have a
| Assignee | ||
Comment 20•24 years ago
|
||
Oops, forgot to mark this as fixed. The fix was checked in last night, just
before the freeze.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 21•24 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
•