Closed Bug 84664 Opened 23 years ago Closed 23 years ago

Double-clicking mozilla.exe should open new window

Categories

(Core :: XUL, defect, P2)

x86
Windows ME
defect

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.
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
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+
Keywords: nsbeta1nsbeta1+
*** Bug 50424 has been marked as a duplicate of this bug. ***
Yes, I'll fix this ASAP (today or tomorrow).
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).
Keywords: patch, review
Whiteboard: time:.5days → fix in hand
*** Bug 85407 has been marked as a duplicate of this bug. ***
*** Bug 85615 has been marked as a duplicate of this bug. ***
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 
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.
adding Samir for r=. 
Whiteboard: fix in hand → fix in hand, have sr, need r/a
r=sgehani
Whiteboard: fix in hand, have sr, need r/a → fix in hand, have r, sr, need a
--> morse
Assignee: law → morse
Patch has suffered some bitrot, although it was created only seven days ago!

Attaching identical patch but without the bitrot.
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
Whiteboard: fix in hand, have r, sr, need a → fix in hand, have r, sr, have a
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
*** Bug 87106 has been marked as a duplicate of this bug. ***
verified win2k 2001062708
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: