open link vs. open link in new window - mirc

NEW
Unassigned

Status

SeaMonkey
UI Design
--
minor
16 years ago
8 months ago

People

(Reporter: MX, Unassigned)

Tracking

Trunk
x86
Windows 95

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020621
BuildID:    2002062109

this *might* be mirc problem, but it works with IE correctly. mIRC, someone
types a url, you right click on it, and have the option of either  opening in a
new browser, or use the one thats always open. With IE this works correctly, but
with mozilla (all builds so far i guess) the browser ALWAYS opens a new window.
It gets cumbersome to have a new window open when you can just reuse the other one.

Reproducible: Always
Steps to Reproduce:
1. run mirc and type in/have someone type a url
2. right click on url
3. choose "open" and it opens a new browser, fine.
4. choose "open" again, and instead of reusing the previous browser, it opens
yet a new one. Again, this behavior does not exist in I.E. or opera if i
remember correctly.

Actual Results:  browsers keep opening a new window.

Expected Results:  browser should reuse (if any) previously opened windows

Note on the status of this bug... i chose "Minor" because it is, but a little note:
Minor: well, its a minor loss of function, but i dont think there is a work around.

Comment 1

16 years ago
IMO, this should be a Mozilla pref (bug 75138), not an mIRC pref.  IE already
has this pref and I don't know why mIRC copies it.

Updated

16 years ago
URL: n/a

Comment 2

16 years ago
This is not a question of prefs.  It is a context menu option.  Do you know if
mIRC uses DDE to open the URL?  and if so, what DDE commands does it issue
differently?  I couldn't find any documentation in MSDN about this issue to
determine if there is an accepted standard for external applications to "Open in
New Window"

Component->XP Apps: GUI Features; dependent on 75138
Assignee: Matti → blaker
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps: GUI Features
Depends on: 75138
Ever confirmed: true
OS: Windows 2000 → Windows 95
QA Contact: imajes-qa → paw

Comment 3

14 years ago
Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). 
If you want this fixed for Firefox, change the Product and Component accordingly
and reassign back to me.
Assignee: firefox → guifeatures
Product: Core → Mozilla Application Suite
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: pawyskoczka → guifeatures

Updated

10 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.