Closed Bug 84664 Opened 24 years ago Closed 24 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: 24 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: