Closed Bug 255123 Opened 20 years ago Closed 19 years ago

Opening URL from another app focuses an existing window before opening a new window

Categories

(Firefox :: Shell Integration, defect)

Product:
Firefox
Component:
Shell Integration
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jellis, Assigned: bugs)

References

Details

(Keywords: qawanted, regression)

Attachments

(2 files, 1 obsolete file)

Patch to set NoActivate in DDE, and also to activate the window when we don't create a new one
5.43 KB, patch
Details | Diff | Splinter Review
Updated patch repsecting loadDivertedInBackground preference
4.31 KB, patch
danm.moz
: review+
bryner
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040810 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040810 Firefox/0.9.1+

When all Firefox windows are minimized, opening an internet shortcut shows the
correct page in a new window, but it also restores a previously minimized window.

Reproducible: Always
Steps to Reproduce:
1. Start Firefox
2. Go to http://www.google.com/
3. Drag the document icon to the left of the url in the location bar to the
desktop (creates .url file for the site)
4. Go to http://www.cnn.com/
5. Minimize Firefox
6. Double-click on the .url file you just created

Actual Results:  
The window showing http://www.cnn.com/ restores and a new window opens showing
http://www.google.com/

Expected Results:  
The window showing http://www.cnn.com/ remains minimized and a new window opens
showing http://www.google.com/
Keywords: regression
Summary: opening internet shortcut (.url file) restores second window restores when all windows minimized → opening internet shortcut (.url file) restores second window when all windows minimized
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0?
will re-consider if either a) a patch appears or b) you can provide some info as
to when and how this regressed!
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
*** Bug 256137 has been marked as a duplicate of this bug. ***
Keywords: qawanted
OK, I did a little back-checking.  I do not this issue in aviary 20040809, but I
do see it in aviary 20040810.

Interestingly, the 20040809 build exhibits bug 254525 but not this bug (255123).
 The 20040810 build exhibits this bug but not bug 254525.  Thus, my guess is
that whatever fixed bug 254525 has caused the regression discussed here.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040809
Firefox/0.9.1+
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040810
Firefox/0.9.1+
Flags: blocking-aviary1.0PR- → blocking-aviary1.0PR?
It's not only about .urls, but also when clicking internet links in an
application (like thunderbird).

FF not only restores minimized window but also brings not-minimized window to
front. This looks *exactly* as if the old window was used to open the new
location. I remember being quite surprised when it happened - it looked as if
old location was replaced with new one, and "back" button didn't work. It took a
while to figure out what happened...


I can confirm that the problem first exists in the nightly from the folder
2004-08-10-08-0.9, it does not exist in 2004-08-09-08-0.9.

I think this would be a reasonable query to find all checkins in that period:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviaryBranchTinderbox&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-08-09+08%3A00%3A00&maxdate=2004-08-10+08%3A00%3A00&cvsroot=%2Fcvsroot

Of which I would think the checkins for the following bugs are possible culprits:

bug 172077
bug 217120
bug 246012

As highlighted by the previous comment, I think that this is should be fixed for
1.0PR. It gives the illusion that the URL clicked is replacing the contents of
an existing window.



bz,roc... 

 based on comment above can you help sort this out?  looks like this regression
might have shipped with a few firefox releases and has low dup count, so I'm not
how critical it is fix by PR, but we should try to get it fixed by final. 
renominate for PR if we have more data on dup count, or if a fix appears.

can anyone figure out if seamonkey has the same bug?
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+
Can this be reproduced on the trunk?
Can it be reproduced on Linux?
Can it be reproduced on Seamonkey?

Saying "yes" to all these questions would help me debug it...
From the description, it sounds like a Windows integration issue, which means bz
and I will have a hard time debugging it since we both only have Linux.
this is very much a dde bug, so unless someone builds mozilla w/ winelib or
whatever it's not going to happen on linux. there are a bunch of ways one could
fix this, i'd probably suggest one which basically nukes the dde references from
mozilla's registry keys.
My criteria for being able to help with a bug are the same as what roc lists in
comment 7.
I have tested with both the latest trunk (20040829) of Seamonkey and Firefox and
the problem does not exist with either.
Just upgraded from 0.9.3 to 1.0 PR (on WinXP SP2), and am observing this
behavior now.  

0.9.3 did not restore or raise any other windows when bringing up a new window,
while 1.0 PR does (if all windows are minimizes, it restores one of them before
bringing up the new window; if some are in their normal state, it raises one of
them to the top before bring up the new window).

*** Bug 259415 has been marked as a duplicate of this bug. ***
Still seeing this with this nightly: 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040917
Firefox/0.10 (bangbang023)
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
(In reply to comment #14)
> Still seeing this with this nightly: 
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040917
> Firefox/0.10 (bangbang023)

I am also having this bug with v 1.0PR.  I have been using 0.93 until now and
did not have the same problem with that build.  I installed 1.0PR and it does
that same thing at home and at work.  At home I am running XP Pro sp1 and at
work I am running XP Pro sp2.

Thanks much,

cabalist
I have spent a fair amount of time over the last couple of days trying to get to
the bottom of this, but have not had much success. I am fairly confident that
the three bugs mentioned in comment #5 are not the problem. It seems to me that
the next most likely culprit is the check in for bug 253220 - Proper Software
Update. Disabling software updates does not solve it, but I am wondering if this
code is somehow hooked into new window creation and might be causing the
activation of the last viewed window before the new window is launched.
Blocks: 262161
No longer blocks: 262161
The code responsible for opening URLs handed to Firefox is scheduled to undergo
major changes from bug 172962. It has already changed on Windows Aviary builds
made 1 Oct 2004 or later. Linux and Mac will soon undergo similar changes. Trunk
and Seamonkey branches will follow at a later time.

So this whole bug just took a big reset. Update your Windows branch build before
retesting. Linux and Mac experiences don't matter until they've taken their
medicine, too. By the way my Windows build doesn't behave as this bug describes.
On my build, the new window opens and the old window stays minimized, just as
one would expect.
This bug is still present on:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041005
Firefox/0.10.1

Installed  into a clean directory and launched with a new profile. The only
change made after launching was to change the "Open Links from other
applications in:" setting.
Interesting. The CNN window did not unminimize for me, using the 20041005 Aviary
nightly build on WinXP: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.3) Gecko/20041005 Firefox/0.10.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041007
Firefox/0.10
everyone seems to agree and there haven't been any extra dupes
->WFM
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
OK, this is indeed is WFM but under certian conditions.

Steps to reproduce:
 - have firefox as your default browser
 - install new firefox to another directory, or just copy ff's program directory
somewhere else
 - start it, it will ask if it's supposed to become a default browser
 - say YES
*** and there you go, all external links will restore firefox windows

Steps to fix:
 - set IE as your default browser
 - start FF, set as your default browser
*** and there you go, everything is fixed

Tested with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3)
Gecko/20041001 Firefox/0.10

Asking for REOPEN status....
It seems I was *this* close from finding the bug.
After all the looking, I discovered that there are 5 places in windows registry
which are created when FF starts and deleted when FF ends. They go like this:

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\https\shell\open\ddeexec]
@="\"%1\",,0,0,,,,"
"NoActivateHandler"=""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\https\shell\open\ddeexec\Application]
@="Firefox"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\https\shell\open\ddeexec\Topic]
@="WWW_OpenURL"

With my firefox, however, they were NOT created at startup. They were deleted at
exit allright, but they were only *created* if I answered the default-browser
dialog.

Then, I confirmed that it's OK with new profile - reg keys are created as they
should be.

And then, I unchecked "check for default browser" and guess what - problem is
fixed forever. Whatever I try, it works perfectly now, the keys are created.

If I had a backup of my broken profile I could pinpoint the differences - but I
don't have it :(( . So I just can't reproduce it anymore and I can't help
squashing the cause anymore :(
(In reply to comment #20)
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041007
> Firefox/0.10
> everyone seems to agree and there haven't been any extra dupes
> ->WFM

Where are you coming from?  A bunch of people say they still see the bug and you
post it WFM?

Radek, could you be a little more clear about the steps you took to get rid of
the bug on your system?  If it requires you to uncheck "check for default
browser" then that is a bug.
Reopening. I downloaded the latest nightly as a zip file (Mozilla/5.0 (Windows;
U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041008 Firefox/0.10). Unzipped the
file to a new directory, launched firefox, set it as my default browser, went
into advanced preferences, set "Open links from other application in" to "a new
window", minimized firefox, double-clicked a URL file on my desktop, and the
previous window was un-minimized before a new window was created and loaded with
the URL.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I can confirm the behaviour described by Radek. If you set IE as your default
browser and then set it back to firefox again the problem goes away. I exported
sections of my registry before and after.

Before I had this:

[HKEY_CLASSES_ROOT\HTTP\shell]

[HKEY_CLASSES_ROOT\HTTP\shell\open]

[HKEY_CLASSES_ROOT\HTTP\shell\open\command]
@="C:\\DOCUME~1\\DAVIDB~1\\DESKTOP\\FIREFOX\\FIREFOX.EXE -url \"%1\""

and after this:

[HKEY_CLASSES_ROOT\HTTP\shell]

[HKEY_CLASSES_ROOT\HTTP\shell\open]

[HKEY_CLASSES_ROOT\HTTP\shell\open\command]
@="C:\\DOCUME~1\\DAVIDB~1\\DESKTOP\\FIREFOX\\FIREFOX.EXE -url \"%1\""

[HKEY_CLASSES_ROOT\HTTP\shell\open\ddeexec]
@="\"%1\",,0,0,,,,"
"NoActivateHandler"=""

[HKEY_CLASSES_ROOT\HTTP\shell\open\ddeexec\Application]
@="Firefox"

[HKEY_CLASSES_ROOT\HTTP\shell\open\ddeexec\Topic]
@="WWW_OpenURL"

Does anyone understand this well enough to know whether this could be the problem?
that is the problem
Whiteboard: DUPEME
OK I'm back after all. Whatever made my Firefox fix it, it was temporary.
The problem also happens to me with new profile (but possibly, not in the
session right after new profile was created).

What's more funny, the ddeexec registry keys are created now, but not all of
them. The missing one is "NoActivateHandler"="" value. Everything is created but
not this single String.

I now 100% confirmed that adding this string to registry under "https" part WILL
fix the problem for buzilla links from thunderbird (which are https). This will
work until I close the browser. ddeexec keys will be deleted at close, and this
particular key will not be recreated.

Just to be clear, before yesterday, NONE of thses registry keys was created. A
simple config change (unchecking "check for default" and then checking it back)
made Firefox to create ALL of them correctly. A couple of hours later, ALL BUT
ONE are created correctly.
I backed up profile when it was working but restoring this profile now doesn't
change anything. This is not caused by any profile setting.
(In reply to comment #27)

> What's more funny, the ddeexec registry keys are created now, but not all of
> them. The missing one is "NoActivateHandler"="" value. Everything is created but
> not this single String.

This is the same for me. I too have the problem back and that value is missing.
Here is what I think happens:

1) No browser running, firefox is default. Only the command sub-tree exists
under HKCU\HTTP\shell\open

2) Set IE as default through "Set program access and default". This replaces
HKCU\HTTP\shell\open with those for IE, and even when IE is not running has the
ddeexec sub-tree. This includes:
HKCU\HTTP\shell\open\ddeexec "NoActivateHandler"=""

3) Start firefox, and set as default browser, this replaces those parts of
HKCU\HTTP\shell\open that refer to IE with values for firefox. However,
NoActivateHandler remains. At this point URLs launch without reactivating the
window.

4) Close down firefox - it deletes all of HKCU\HTTP\shell\open\ddeexec including
the NoActivateHandler bit.

5) Start firefox, and it adds in HKCU\HTTP\shell\open\ddeexec without the
NoActivateHandler bit.

It looks like bug 246078 was the one that broke this, as this is where we start
deleting the ddeexec tree on exit. This is the checkin:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/components/shell/src&command=DIFF_FRAMESET&file=nsWindowsShellService.cpp&rev1=1.3.2.1.2.3&rev2=1.3.2.1.2.4&root=/cvsroot

I will put a patch together that adds the NoActivateHandler key to those that we
set at launch.
It turns out I can see this bug when using a properly registered default browser
which I was a little surprised to discover I don't normally do. So now that I
can see the problem too, I concur with David. Mostly. By the way:

27: >Just to be clear, before yesterday, NONE of thses registry keys
    >[was] created

Yes, a change which modified this behaviour but didn't cause this bug was
checked in on the 7th. So only 20041008 builds or later are interesting at this
point.

It's trivial to add NoActivateHandler keys to Firefox's set of running DDE keys,
and yes that fixes this bug. However we can't take that simple fix because doing
so will cause a new regression. Launch an internet shortcut from the desktop
with a default Firefox browser already running:

URL treatment         current                  NoActivateHandler

new window      extant window activated *   extant window unaffected
new tab         window activated            window activated
reuse window    window activated            window unaffected *

* - incorrect behaviour
no asterisk - correct

("Activated" means the window is brought to the foreground, which also means
that it's restored if it was minimized.)

Going on the assumption that the desktop shortcut should be activated/focused,
the trivial NoActivateHandler patch merely shifts the problem from one case to
another; net gain zero. Of course some folks would prefer the shortcut's window
remain in the background. But that's enhancement bug 263553 and pending that
bug's resolution, we should consistently focus the shortcut's window.
(In reply to comment #30)
> It's trivial to add NoActivateHandler keys to Firefox's set of running DDE keys,
> and yes that fixes this bug. However we can't take that simple fix because doing
> so will cause a new regression. Launch an internet shortcut from the desktop
> with a default Firefox browser already running:
> 
> URL treatment         current                  NoActivateHandler
> 
> new window      extant window activated *   extant window unaffected
> new tab         window activated            window activated
> reuse window    window activated            window unaffected *
> 
> * - incorrect behaviour
> no asterisk - correct

OK, so how about checking this setting and creating the key or not, depending on
current configuration?
The only new "regresson" is trivial: changing this setting would require a
restart for Proper Full Effect, hardly any big deal.
Radek, if your categorization of the new "regression" as trivial is a prelude to
discounting it, I'll have none of it. The new single-window regression would be
the mirror equivalent of the multi-window regression this bug was written to
address, and therefore no less important. Though I concur that neither is very
important.

The alternative to adjusting the NoActivateHandler key depending on the value of
the pref for handling external URLs is manhandling window activation internally,
and that's always ugly. So yes, some treatment of the NAH key seems like the
right solution.

Addressing the details, I suppose I could live with adjusting the key only at
startup. Working under the assumption that most people won't tweak that pref
very often, it's probably a decent enough fix. However it wouldn't be that much
trouble to be a pref observer and adjust the keys at runtime as the pref
changes. Though while that wouldn't be much trouble, I'm not sure it's worth the
effort.

Blake? Ere? (Though the patch we're discussing technically would be in browser,
it's really an xpfe and Windows widget issue.)
Whiteboard: DUPEME
This is an alternative to dynamically changing the registry. In the case that a
new window is not being created this patch explicitly activates the existing
window. I am open to feedback on better ways to activate the window.
I'm all for David's approach with the patch. Always tell Windows to not activate
and do it ourselves if necessary. Clean and simple, right?
Shouldn't the code in openURL in browser.js decide which window to activate?
(In reply to comment #35)
> Shouldn't the code in openURL in browser.js decide which window to activate?

It would seem like an ideal place to do it. How do I activate a window from js?
(In reply to comment #36)
>How do I activate a window from js?
You're a special case because you want to activate the web page you're just
about to load, so in that case content.focus(); should do the trick.
Definitely a neater solution. The only concern might be that this a Windows
specific problem being fixed in code common to all platforms. Either patch
works for me.
I don't much like the first patch, since it leaks the knowledge of pref values
into a place I'd like to keep them out of, making the OPEN_DEFAULTWINDOW value
less useful.

But the browser.js patch seems fine. It would be good to hear from some Linux
and Mac guys but I expect no trouble. I think you do want to add one tweak:
focus the content window in the OPEN_CURRENTWINDOW case only if
!gPrefService.getBoolPref("browser.tabs.loadDivertedInBackground"), just as in
the OPEN_NEWTAB case. With that change the new-tab and current-tab cases behave
similarly, so I can't see anyone complaining.

Cool; it looks like you don't need to manhandle window focus after all. That's
refreshing. My bad for being alarmist.
Here's a new patch updated based on your comment. I am going to have limited
access to email/internet for the rest of the week. So, if any changes or
updates are needed I am unlikely to be able to get to them until the weekend.
Attachment #161718 - Attachment is obsolete: true
Who do I need to ask to get this patch reviewed?
http://www.mozilla.org/hacking/code-review-faq.html
(In reply to comment #41)
> Who do I need to ask to get this patch reviewed?
Attachment #161778 - Flags: review?(firefox)
Renominating: this bug has steps to reproduce and a patch now.
Flags: blocking-aviary1.0- → blocking-aviary1.0?
Summary: opening internet shortcut (.url file) restores second window when all windows minimized → Opening URL from another app focuses an existing window before opening a new window
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Flags: blocking-aviary1.0- → blocking-aviary1.0?
ben already minused this after it was re-nominated.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
I had thought that because of the changes in the way new windows were done this
would only affect users who changed their preferences away from the default.
However, I found a new case where this problem shows itself. In the default
state of opening external links in the most recent window and when the download
manager is the last focussed window, then when an external URL is launched the
download window is activated, the content is loaded in the background in the
last active browser window. However, this browser window is not activated, it
stays minimsed.
Blocks: 263553
I've just switched to 1.0 and the problem still occurs. Is there any easy way to
work around the problem?
(In reply to comment #47)
> Is there any easy way to work around the problem?

Alas, no, because FF actually deletes all the DDE keys and re-inserts them on
startup, so even if you fix up your registry manually, it'll revert when you
restart FF.

*** Bug 268899 has been marked as a duplicate of this bug. ***
*** Bug 273733 has been marked as a duplicate of this bug. ***
This bug now exists on the trunk. Is there any chance that someone could review
the patch for check-in on the trunk?
(In reply to comment #51)
> This bug now exists on the trunk. Is there any chance that someone could review
> the patch for check-in on the trunk?

needs aviary landing keyword
Flags: blocking-aviary1.1?
Blocks: 226826
Comment on attachment 161778 [details] [diff] [review]
Updated patch repsecting loadDivertedInBackground preference

I have mixed feelings about this patch.

(1) It's (mostly) Windows-only, and this is an XP bug. Certainly you can't
close this bug after checking in this patch, though it'll be fixed on Windows.

2) It can move focus from the URLbar to the content area. Yes that part of the
patch was written to address my own comment 30, but it's a little suboptimal.
However I asked Brian "Focus" R. about this and he said "eh?" Let's make him
superreview.

If/when you check this in obviously the browser.js patch will no longer apply
as is. Add those two lines at the end of the |try| clause, just before the
corresponding |catch|.

Formatting gobbledygoo:

I can't tell what whitespace nonsense is responsible for half the lines changed
in nsWindowsShellService.cpp. It would be annoying were unwelcome tab
characters introduced.

Please do take one space out of the long browser.js line (perhaps
"if(!gPrefService...)) to make it fit an 80 character line. Yup, that's still a
requirement.
Attachment #161778 - Flags: superreview?(bryner)
Attachment #161778 - Flags: review?(firefox)
Attachment #161778 - Flags: review+
(Oh, the bug was written against Windows-only. Well, feel free to close it after
a fix for only Windows, then. Feh.)
Gosh I'm embarrassing myself. Part of this patch changes cross-platform
behaviour, while the compensating part of it is Windows-only. It's arguably a
minor thing so I'm not going to reverse my +review, but my botheration level is
increasing. Off to superreview.
*** Bug 279626 has been marked as a duplicate of this bug. ***
*** Bug 281197 has been marked as a duplicate of this bug. ***
*** Bug 282039 has been marked as a duplicate of this bug. ***
*** Bug 284087 has been marked as a duplicate of this bug. ***
Attachment #161778 - Flags: superreview?(bryner) → superreview+
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Patch is checked in on the trunk (and only the trunk at time of writing). Since
this bug and all eight duplicates are all Windows-only bugs, I suppose I'll
close it. Note the Linux (and I expect, OS X) equivalent is bug 226826.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
Blocks: 172962
*** Bug 285809 has been marked as a duplicate of this bug. ***
*** Bug 291338 has been marked as a duplicate of this bug. ***
*** Bug 291361 has been marked as a duplicate of this bug. ***
Does anyone know when this fix will propagate into an official 1.0.x build, or
even a nightly build based on the 1.0.x series?
(In reply to comment #64)
> Does anyone know when this fix will propagate into an official 1.0.x build, or
> even a nightly build based on the 1.0.x series?

It won't. This fix will be in Firefox 1.1.
*** Bug 262978 has been marked as a duplicate of this bug. ***
This seems to have regressed, is anyone else seeing this as broken again?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050819
Firefox/1.0+
(In reply to comment #67)
> This seems to have regressed, is anyone else seeing this as broken again?
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050819
> Firefox/1.0+

Are you sure you're not seeing: 
Bugzilla Bug 263553 keep browser in background (unfocused, unactivated) as new
tabs are opened into it

or:
Bugzilla Bug 56690 Allow opening link in a new background window (behind current
window)

Are these all closely related in the code? Is there an extension which could fix
these problems? 
(In reply to comment #68)
> Are you sure you're not seeing: 
> Bugzilla Bug 263553 keep browser in background (unfocused, unactivated) as new
> tabs are opened into it
> 
> or:
> Bugzilla Bug 56690 Allow opening link in a new background window (behind current
> window)
> 
> Are these all closely related in the code? Is there an extension which could fix
> these problems? 

No, it's neither of those. I have "Open links from other applications in:" set
to "a new Window". And before the new window is opened the previously active
browser window is brought to the front, and then the new window is shown.
*** Bug 299403 has been marked as a duplicate of this bug. ***
*** Bug 261728 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.

Attachment

General

Creator:
Created:
Updated:
Size: