Closed Bug 531552 Opened 15 years ago Closed 14 years ago

Firefox opens two windows when opening external links

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla2.0b9
Tracking Flags:
Tracking Status
blocking2.0 --- -
status1.9.2 --- .9-fixed

People

(Reporter: brndnsh, Assigned: smichaud)

References

Details

(Keywords: regression, verified1.9.2, Whiteboard: [read comments 94, 50 & 65 before commenting])

Attachments

(4 files, 4 obsolete files)

fix v1.2
12.19 KB, patch
BenWa
: review+
Details | Diff | Splinter Review
1.9.2 fix v1.4
12.94 KB, patch
Details | Diff | Splinter Review
Simplified trunk patch
12.79 KB, patch
jaas
: review+
jaas
: approval2.0+
Details | Diff | Splinter Review
Simplified trunk patch with debug logging
20.09 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4

Firefox 3.6b builds open two windows when clicking external links.  In Firefox 3.5 (and everything before it), clicking external links would result in one window being created with the page displayed in a tab.

Reproducible: Always

Steps to Reproduce:
1. Quit Firefox completely.
2. Click an external link from a program like Adium, Mail, etc.
Actual Results:  
Two windows are created, one with your home page, one with the link you clicked.

Expected Results:  
Only one window should open with the external link, and the homepage should not be loaded.

This behavior is present without any extra configuration in at least 3.6b3 and 3.6b4.
Version: unspecified → 3.6 Branch
I can confirm this on Namoroka:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b5pre) Gecko/20091203 Namoroka/3.6b5pre

I can also confirm this is a regression since Firefox 3.5.  In 3.5.5, a new tab is opened beside any tabs restored from the previous session.

Related: Launching Firefox with a URL in terminal works as expected (does not open a new window)
Status: UNCONFIRMED → NEW
Component: General → Shell Integration
Ever confirmed: true
Keywords: regression
QA Contact: general → shell.integration
I can confirm this as well on Firefox 3.6 beta 5 on Mac OS X 10.6.2, this did not happen on Firefox 3.5.x.
I can confirm this on FF3.6b5 on OSX 10.5.8. NOTE: It only occurs on the initial launch of FF from an external link (e.g., email); if FF is already opened this does not occur.

The actual link is opened in the first window and a second blank window then covers the first window.
Forgot to note my "Home Page" is blank which is consistent with what was reported by  Brandon Shea initially.
I've the Firefox 3.6 just release today and I have the same problem
Regression range
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=65c8a88b98db&tochange=07682d87fcdf

Probably regressed by
http://hg.mozilla.org/mozilla-central/rev/3304d08b9dc3
Remove Carbon Apple Event code, replaced with standard Cocoa suite and some custom Cocoa handlers. b=363747 r=smorgan sr=roc
Component: Shell Integration → Widget: Cocoa
Depends on: 363747
Product: Firefox → Core
QA Contact: shell.integration → cocoa
Version: 3.6 Branch → Trunk
FYI, this is broken on latest trunk (20100122 3.7a1pre).

This was kinda tricky to initially test because some reason setting the default browser from Safari to Minefield.app kept switching to MinefieldDebug.app no longer have built. It then seemed like it basically went down the list of my installed Firefoxes (Minefield, 3.6 Namoroka, 3.6, 3.5 Shiretoko, 3.5..).

So to find the regression range, I had to rename all my existing Firefox apps to confuse the default picker (?) and then download *and* launch the to-test Minefield.app then quit and point the default browser to the just-launched Minefield.app.

I also turned off the profile manager and had it default use the last profile. 1) switching versions seems to eat the launched link. 2) showing the profile manager also seems to eat the launched link.
It might be worth trying the following, just to narrowing down the cause:

Does it also happens if you open a local file by right-clicking and choosing "Open with..." ?

Does playing with the "browser.link.open_newwindow" settings make any difference?


1 = Open links, that would normally open in a new window, in the current tab/window.

2 = Open links, that would normally open in a new window, in a new window

3 = Open links, that would normally open in a new window, in a new tab in the current window
See also bug 512129.
Opening a file from the hard drive has the same effect.  Two windows are opened, and the second opens the desired file.

I remember playing with the browser.link.open_newwindow preference when I first discovered this bug, but it didn't help.
Hardware: x86_64 → x86
Summary: Firefox 3.6b opens two windows when opening external links → Firefox 3.6 opens two windows when opening external links
Josh, do you want to deal with this?  Or shall I?
I thought I should add the following. I get the same behavior as stated in the original report by Brandon Shea. However, I just tried experiments using local .htm and .html files. They failed to open at all. When I rt-clk and select Open With and choose Firefox, then if Firefox is not running, it will open to my default home page, and if it is already running it will do nothing, but stay open to where it is. If I drag the same files to Firefox, they will display fine.

I am running Mac OSX 10.6, and Firefox 3.6. I uninstalled and reinstalled Firefox before I ran these tests. I have also tried with a fresh profile and get the same double window experience.

Hope this helps.
I'm pretty sure I know what the problem is, I'll take this.
Assignee: nobody → joshmoz
Hi guys,

Got the same problems (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 ) :

Problem #1
 - Close Firefox (if opened)
 - Open any external link (Thunderbird, Adium, whatever...)
 - Firefox starts and show your link, but in the meantime there's another Firefox window in the background with your homepage.

Problem #2
 - Close Firefox (if opened)
 - Open a HTML file on your computer with Firefox
 - Firefox starts and show your homepage but not your local file (note : no 2nd window problem here)

Regards,
M@tt
Originator's bug report and all other comments (INTEL Mac) also reprodicable on Mac PPC (PowerBook G4, OSX 10.5.8), precisely as represented, with one (only) exception:
 Mathieu Debieuvre's (Comment 19) Problem #2 is not reproducible on this platform/OS.
In the old apple event handling code, for kAEGetURL, we manually looked up a window by enumerating by z order via nsIWindowMediator.

http://mxr.mozilla.org/mozilla1.9.1/source/xpfe/bootstrap/appleevents/nsAEGetURLSuiteHandler.cpp#184

In the new code, we use nsICommandLineRunner and have it run with a "-url" argument. This should work, and it does after app startup.

I traced the failure to handURIToExistingBrowser, which is a js function in nsBrowserContentHandler.js. This calls getMostRecentBrowserWindow, which calls getMostRecentBrowserWindow in nsBrowserGlue.js. That calls getMostRecentWindow on nsIWindowMediator. The problem is that the window mediator returns NULL.

nsWindowMediator::GetMostRecentWindow does find data (nsWindowInfo) for a most recent window, but it fails when calling GetDOMWindow with "info->mWindow". That function, near the top of nsWindowMediator.cpp looks like this:

nsresult
GetDOMWindow(nsIXULWindow* inWindow, nsCOMPtr<nsIDOMWindowInternal>& outDOMWindow)
{
  nsCOMPtr<nsIDocShell> docShell;

  inWindow->GetDocShell(getter_AddRefs(docShell));
  outDOMWindow = do_GetInterface(docShell);
  return outDOMWindow ? NS_OK : NS_ERROR_FAILURE;
}

I don't know why this would fail early on and I need to work on other stuff today so I'm documenting my debugging progress here.

We could add back all the manual code for finding a window and properly opening the URL in response to the apple event but we'd essentially be duplicating the command line code, which shouldn't be necessary. I think it would be good to find the bug in the command line code rather than plug in the old code to solve the problem.
Almost certainly we've opened the browser window, but we haven't actually loaded browser.xul into it yet, so it doesn't have a DOM. I believe that loading happens asynchronously.
I think the fallback code here is why this used to work:

http://mxr.mozilla.org/mozilla1.9.1/source/xpfe/bootstrap/appleevents/nsWindowUtils.cpp#560

That handles the case where we couldn't get a DOM window.
issue still exists in final version of 3.6. merely clarifying. keep up the good work fellas!

ps - i like how opening a new tab opens it just to the right of the one your currently on. love it!
Is Bug 542308 related to this bug?
> Is Bug 542308 related to this bug?

No.  It doesn't have the same regression range.
(Following up comment #27)

On second thought:  Though bug 542308 isn't related, whoever fixes this bug should keep it in mind.
The reason this works in Firefox 3.5.x is not what I expected. It isn't the fallback code I mentioned in comment 23, it is that the Apple event gets handled before the command line service runs for the first time. The Apple event handler opens a new window with the requested URL and then the command line service doesn't do anything, so that the Apple event handler essentially overrides the default command line handler which would normally open the default home page.
I am experiencing this bug on all of my machines.

Macbook Pro running 10.6.2, FF 3.6
iMac running 10.6.2, FF 3.6
Macbook Pro (unibody) 10.6.2, FF 3.6

The steps other's have described are the steps I follow to reproduce the bugs (close firefox, open a link from external program like Thunderbird opens two firefox windows).

Hoping this gets fixed soon.  It's very annoying.
There is a related issue about third party opening of Firefox that ignores or loses the third party URL when a plugin update occurs.  The ticket on this has been closed; but, the problem still occurs.  I get a second page when opening from a third party with either the third party URL or plugin update URL's; but, not both.
blocking2.0: --- → ?
Kind of surprised this bug is still around. Quitting FF completely and clicking any external link one window with the user's start page and another window in the background with the external link. Please, if there's anything I can do to help, let me know.
I think when I was debugging this I ended up with a different theory than I wrote out in comment 29. I think we open the first Firefox window asynchronously then we process the Apple event so soon after it starts loading that we don't recognize it as a browser window to load a second tab in. We'd either have to process Apple events later or find a way to load a URL in the XUL window earlier.
This also occurs on PPC platforms.  I mentioned earlier that when third party openings (requested URL's from an another program) are initiated that the third party reference is lost when a plug-in update is made.  In that particular case, only one window appears with the plug-in update opening a new tab rather than new window for the plug-in; but, no tab or window for the third party URL.  If there is no plug-in update, the third party URL opens a new window instead of a new tab.
This also happens on PPC (PB G4), 10.5.8, opening external links from Entourage 2004 e-mails.  when external link is clicked, if no window is open in Firefox, it will open two--one with the home pages, and a separate window with the external link.

cmd-click or right-click within the browser to open new link in tab works fine (opens the link in a new tab in the same window, as expected).  Only happens when opening external links.

new bug that did not exist in previous version.  only on FF3.6
Also not fixed in 3.7 a2

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a2) Gecko/20100228 MozillaDeveloperPreview/3.7a2

Appears to be common to OSX10.6

If Firefox is already open then clicking external link works correctly - problem only occurs when FF is not open.
C'mon after two months you just tell that is don't fix and a method for don't have this problem, but I'm really hates this bug and I can imagine that is not important. I love FF but more day I pass with this bug, I want go with Safari... Because I hate open an email or a RSS from mail and two stupid windows appears...
This still isn't fixed in 3.6.2pre. This is insane. It's the most major bug in the browser on the Mac platform, and it's a simple regression. What gives?
Blocks: 363747
No longer depends on: 363747
Hardware: x86 → All
(In reply to comment #43)
> C'mon after two months you just tell that is don't fix and a method for don't
> have this problem, but I'm really hates this bug and I can imagine that is not
> important. I love FF but more day I pass with this bug, I want go with
> Safari... Because I hate open an email or a RSS from mail and two stupid
> windows appears...

See comment 42, leave FF running.
(In reply to comment #45)
> (In reply to comment #43)
> > C'mon after two months you just tell that is don't fix and a method for don't
> > have this problem, but I'm really hates this bug and I can imagine that is not
> > important. I love FF but more day I pass with this bug, I want go with
> > Safari... Because I hate open an email or a RSS from mail and two stupid
> > windows appears...
> 
> See comment 42, leave FF running.

Not that I want to start a huge discussion about this, but leaving FF running constantly is NOT a "fix" for this issue. It's a poor solution for many of us.

I too is very disappointed that this issue has not yet been resolved. I know (or sincerely hope) that the great FF-crew is working on a permanent solution - however, I'm beginning this speculate that more and more Mac-users are switching to Safari until this problem has been resolved. The big task ahead would be to make them switch back.

Just my 2 cents on this :)
(In reply to comment #46)
> (In reply to comment #45)
> > (In reply to comment #43)
> > > C'mon after two months you just tell that is don't fix and a method for don't
> > > have this problem, but I'm really hates this bug and I can imagine that is not
> > > important. I love FF but more day I pass with this bug, I want go with
> > > Safari... Because I hate open an email or a RSS from mail and two stupid
> > > windows appears...
> > 
> > See comment 42, leave FF running.
> 
> Not that I want to start a huge discussion about this, but leaving FF running
> constantly is NOT a "fix" for this issue. It's a poor solution for many of us.
> 
> I too is very disappointed that this issue has not yet been resolved. I know
> (or sincerely hope) that the great FF-crew is working on a permanent solution -
> however, I'm beginning this speculate that more and more Mac-users are
> switching to Safari until this problem has been resolved. The big task ahead
> would be to make them switch back.
> 
> Just my 2 cents on this :)

I absolutely agree. This "extra window" is annoying, and it is also a fact that, contrary to other OS X browsers, it is not possible to close all windows in FF yet leaving the application running. This is a serious drawback when you scroll through active windows in OS X. This must somehow be related to this bug, but I have no technical background to back me up, though. When an application does something as unexpected as that, many people stop trusting it per se.
(In reply to comment #47)
> (In reply to comment #46)
> > (In reply to comment #45)
> > > (In reply to comment #43)
> > > > C'mon after two months you just tell that is don't fix and a method for don't
> > > > have this problem, but I'm really hates this bug and I can imagine that is not
> > > > important. I love FF but more day I pass with this bug, I want go with
> > > > Safari... Because I hate open an email or a RSS from mail and two stupid
> > > > windows appears...
> > > 
> > > See comment 42, leave FF running.
> > 
> > Not that I want to start a huge discussion about this, but leaving FF running
> > constantly is NOT a "fix" for this issue. It's a poor solution for many of us.
> > 
> > I too is very disappointed that this issue has not yet been resolved. I know
> > (or sincerely hope) that the great FF-crew is working on a permanent solution -
> > however, I'm beginning this speculate that more and more Mac-users are
> > switching to Safari until this problem has been resolved. The big task ahead
> > would be to make them switch back.
> > 
> > Just my 2 cents on this :)
> 
> I absolutely agree. This "extra window" is annoying, and it is also a fact
> that, contrary to other OS X browsers, it is not possible to close all windows
> in FF yet leaving the application running. This is a serious drawback when you
> scroll through active windows in OS X. This must somehow be related to this
> bug, but I have no technical background to back me up, though. When an
> application does something as unexpected as that, many people stop trusting it
> per se.

I must correct myself: When pressing Cmd+W shortcut in OS X 10.5.8 the last window of Firefox will not close. After I received an email saying elements in my last post was nonsense I did some testing and I can actually close the window with its' button, but still not with the above mentioned shortcut. I therefore uphold that it is not working properly.
The comment "leave Firefox open" is a little hard following system shutdown and then opening from a third party following startup.  That "leave Firefox open" is not an acceptable solution, especially from a system cold start or restart.  Also leaving Firefox open means having a Firefox window always present when Firefox is in use or not.  Not all system sessions require the use of Firefox; thus, need Firefox taking up valuable display space.
Having said that, this is the range of behaviors I get:  When Firefox is already open with no window, a third party reference opens a single window; Start-up from a third party call that is not redirected to plug-in update opens pages in two windows; and Start-up from a third party redirected to plug-in update does not open a second window upon completion of updating plug-ins (all plug-in updates that have a URL open pages in new tabs and not new windows when the "open in new tab" is selected in preferences; but, loses the URL somewhere between start-up and updating the plug-in).  In the last behavior, whether a page or tab opens can not be determined following the updated plug-ins because the third party URL is lost.
Find the sequence that handles these three items at start-up and most likely you will find the source of the problem for the two page and lost URL.
Folks, spamming this bug with additional "me too", "why isn't this fixed", "the workaround is not a workaround", etc. comments isn't going to get the bug fixed any faster.

In fact, such comments work in the opposite direction: developers have to spend time reading more bugmail (none of it helpful for their debgging), and the bug's web page becomes larger and larger and it becomes harder and harder for developers to find the comments they've made with their analysis and debugging.  

Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

If you want to express your desire to see this bug fixed, click on the little "vote" link near "Importance" at the top of the bug, and cc yourself, but please don't comment unless you have specific code-level debugging information to share.  Thanks!
Reproduced on 10.5 Intel MacBookPro.

Further notes:
If I change my "When Firefox starts:" settings, I get different results that seem significant... in all cases, I am triggering from an external URL:

If I choose "My Homepage" -- I get that as the front window and my link appears in the window in the back.

If I make it "open tabs from last session", it SEEMS (it gets a little convoluted) that the tabs go to the BACK window and the front window is blank, and the new external URL is a peer tab to those

If, after having a failed external URL open, I intentionally close the "back window" (this may be where I just confuse myself), and put multiple tabs into the FRONT window, then restart the application (triggered again with an external URL) -- it SEEMS that the tab recovery happens in the front window and my new link is in the back window.

BOTTOM LINE: it is differentiating between front window and new "pop-under" window, and it can be manipulated with the startup preferences pane.


NOTE TO 'WHY ISN'T THIS FIXED' PEOPLE:
Please refrain from commenting on the "frustration" level of the bug -- those comments are added only to motivate the developers to "really fix it" -- they are working on it and can't locate the resolution yet.  

Suggestions regarding leaving FF open are only intended as a short-term balm to ease the pain -- this bug WILL BE FIXED -- the developers see it, know it's a priority, and are chasing it... all user suggestions are just to help while we all wait for the fix.

Filling this channel with noise about user experience only makes communication less open because they can't use THIS channel to discuss the answer.  So, be patient and shhhhh :)
Just adding for confirmation - this bug was Not fixed in the latest Firefox release 3.6.2.
Reproduced on:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.3a4pre) Gecko/20100322 Minefield/3.7a4pre
Still existing on v3.6.3


Shame :(
blocking2.0: ? → final+
When opening a link from Thunderbird (and Firefox not running), I only get the home page window, not the link one.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

In response to the last part of comment 51, is the last part of comment 21 still valid? Because complaining about the delay is more reasonable if there is already a known fix, that is not even a new kludge but simply a code regression. A better solution may eventually be developed, but for every release in the meantime, this fix would be better than the bug.
(In reply to comment #54)
> Still existing on v3.6.3
> 
> 
> Shame :(

For me as well.
(In reply to comment #59)
> (In reply to comment #54)
> > Still existing on v3.6.3
> > 
> > 
> > Shame :(
> 
> For me as well.

As has been said before, these comments don't make things go faster. Do what I did instead, use Safari, at least until they fix this.
(In reply to comment #60)

After 15+ years with Netscape/Mozilla (have the t-shirt, the beachball, etc.), finally gave in and made the new faster Google Chrome 5 beta (with integrated and more secure Flash) my default browser today.  Still using Thunderbird, though....

Thought I'd post a few error console entries for just loading this bugzilla page from a fresh start.  I'd have posted all of them, but there's no ability to save them to a file, nor copy and paste them all, so it's one at a time:


Error: Warning: unrecognized command line flag -foreground

Source File: file:///Applications/Firefox.app/Contents/MacOS/components/nsBrowserContentHandler.js
Line: 708

bugzilla.mozilla.org : potentially vulnerable to CVE-2009-3555
[6 times]

Warning: Expected declaration but found '*'.  Skipped to next declaration.
Source File: https://bugzilla.mozilla.org/skins/standard/yui/calendar.css
Line: 7
[5 times]

Warning: Unknown property 'zoom'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/skins/standard/yui/calendar.css
Line: 7

Warning: Unknown property '-moz-opacity'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/skins/standard/yui/autocomplete.css
Line: 7

Warning: Error in parsing value for 'white-space'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/skins/standard/global.css
Line: 278
Line: 279
Line: 280

(heavy sigh)
(In reply to comment #46)
> however, I'm beginning this speculate that more and more Mac-users are
> switching to Safari until this problem has been resolved. The big task ahead
> would be to make them switch back.


I get this with Firefox on Tiger (10.4.11) but not with Firefox on Leopard (10.5.8). I put up with it because I just don't like Safari.
Just to report still a bug in 3.6.4 Build3  :( - also to note on mac at home for some unknown reason it just does not open the link at all really annoying although i do have my browser open almost all the time these days - but on mac at work as above opens link and new windows annoying but not as bad.
To keep the developers updated, I downloaded FF3.6.3 (Mac) yesterday, installed it, and today had exact same problem:

- clicked on link (in Mail)
- Firefox opens a window with that page in a window, and very quickly afterward, opens second window with my homepage in it.
- Attempting either clicking on the 2nd (homepage) window, or trying Command-W, is not responded to by Firefox until after the homepage window has loaded. 
- I get the spinning beachball, cursor arrow, beachball, then about the second or third time the cursor arrow returns, Firefox will finally allow me to close that #$%&* extra window.

Mac OS X 10.4.11, PowerMac G4 (450MHz, 1.25GB RAM). Had earlier in FF 3.6.x's history also downloaded 3.6 (Maybe without any more number than that), same problem with my PowerBook G3 (500MHz, 1GB RAM, Mac OS X 10.4.11). 

(Now I remember why I downgraded to FFox 3.5.x after trying FF 3.6 earlier on...)

Firefox is supposed to be at 3.6.3 now, and not a pre-release candidate or such, which makes it more frustrating. I would feel less so if it were in beta still - but it isn't. Not putting down the developers, who I'm sure are at least as frustrated with this bug as are end users. But please, get it fixed, okay?
(In reply to comment #64)
> To keep the developers updated

We're updated, we know what the problem is, how to reproduce it, and we'll let people know here when something has changed. The only thing that needs to be posted in this bug from here on out is a patch or an improved technical explanation of what is going on in our code. I appreciate people wanting to help, but at this point, the other comments are just making the technical discussion here harder for developers to follow.
Whiteboard: [read comments 50 & 65 before commenting]
Reproduced on Mac OS X 10.6.4
Noticed this bug mostly when 3.6.x hit, running 10.5.8. And only when FF was closed and invoked by an external link, i.e., Web Doc, eMail Link, I get one sometimes two windows/pages and the URL is not propagated into the address bar and acted upon. The open page(s) are blank. When FF active this is not an issue. And not an issue with 3.5.x. Although since installing/using later releases I have noticed their issues presenting in earlier versions. Especially after running Minefield.
Reproduced on Mac OS X 10.6.4 with Firefox 3.6.4

:/
I've had this problem for a while now and it is extremely annoying.  I have found something interesting - when launching a site from the command line, everything works as it should:

Example:

/Applications/Firefox.app/Contents/MacOS/firefox-bin http://www.cnn.com

Only one window opens, which means that it may be a bug involving the way the link interacts with the app, rather than firefox itself.
Email from Will Dunhaven:

Since you DO NOT SEE "FIXED" anywhere it is not fixed. Likely won't happen until Firefox 4

Quit wasting our time and learn to read the status.

----------

Is this someone from Firefox? Not very nice.
I had an experience that COULD be of interest for solving this bug:

When I launch a new TextEdit document via Launchbar 5 there are actually two windows opening (OS X 10.5.8) as empty, unsaved documents.
This behaviour is exactly like with Firefox: If the application is running prior to requesting a new document from external application (in this case: LaunchBar 5) two windows open. If the application is already running when, only one window opens, as expected.

Hope this can be of help.
Hi again, this cannot be a rare problem.  I have performed a clean install on my mac and the problem is still there (with only firefox installed and nothing else besides updates).  It's so frustrating!
This bug has not been fixed (at least for my config) with the release of 3.6.6 - still the original poster's problem persists.

I'm on 10.6.2 with Mac Pro
(In reply to comment #72)
> Email from Will Dunhaven:
> 
> Since you DO NOT SEE "FIXED" anywhere it is not fixed. Likely won't happen
> until Firefox 4
> 
> Quit wasting our time and learn to read the status.
> 
> ----------
> 
> Is this someone from Firefox? Not very nice.



@ Will:

Apologies for the newbie mistake - I thought I was being helpful.

Nice attitude though Will. That's sure to inspire new people to contribute to the development of Firefox not.

Kev
To reiterate comment 65 with added emphasis:

The ONLY thing that needs to be posted in this bug from here on out is *a patch* or *an improved technical explanation* of what is going on in our code.

Comments 66-78 do not do any of that. If you cannot read or follow basic English instructions, you may find you are unable to use Bugzilla at all.

Please DO NOT COMMENT in this bug unless you have a PATCH or DETAILED TECHNICAL EXPLANATION of what the current code is doing incorrectly. (If you think you have the latter but do not have the former, you probably don't have either one. Anyone with the technical know-how to explain the problem in the code can very likely also fix it.)

Thank you.
(In reply to comment #79)
> To reiterate comment 65 with added emphasis:
> 
> The ONLY thing that needs to be posted in this bug from here on out is *a
> patch* or *an improved technical explanation* of what is going on in our code.
> 
> Comments 66-78 do not do any of that. If you cannot read or follow basic
> English instructions, you may find you are unable to use Bugzilla at all.
> 
> Please DO NOT COMMENT in this bug unless you have a PATCH or DETAILED TECHNICAL
> EXPLANATION of what the current code is doing incorrectly. (If you think you
> have the latter but do not have the former, you probably don't have either one.
> Anyone with the technical know-how to explain the problem in the code can very
> likely also fix it.)
> 
> Thank you.

No prob. Back to Safari on 350 of my machines.
This is insane!

Are you telling us that we (the very users that keep Mozilla in business) have to wait until Firefox 4.0 to see a fix for this issue? This is completely unacceptable.

Furthermore, this has been an issue for the past few releases, so why wasn't it addressed in a previous update?

Like Google and the other "big" conglomerates, you want to be the big kid on the block, however, you seem to forget about the little kids that helped you gain your status. This is why people switch to the Safari's, Opera's, and Omniweb's. They listen to the people who put them where they are, and do not wait three years to put a fix in place.

Every time you release a new candidate, I am always the first one to get excited and think, "OK, this is THE one," only to be let down every time.

Bye Bye Firefox . . . 

Bryan
Response from Will:

If you keep FF running in the background two windows don't open. That tells me you are just too anal.

----

My Response:

I like you; You're silly!

If you actually believe that I, or anyone else for that matter, are thinking about whether or not Firefox is open in the background while we work, than you my friend need to have your head examined. I am surprised by your responses to the individuals on this board, especially as an employee representing Mozilla. If I were to act in this manner at my place of employment, which happens to be tech support, I would be terminated immediately. 

Do me a favor, if you are going to respond in an unprofessional manner, I would rather you do not respond at all.

Regards,
Bryan
Who is this Will Dunhaven? Does the Firefox team share his opinions? If so, his insults will be the sole reason I don't switch back to Firefox if this ever gets fixed.
ok I WILL!! POST THIS HERE and I hope it is as annoying to you as it has  been for me to change 200 macs from firefox to safari 5! and all the staff that have been at my throat to make EVERYTHING the way it was.
maybe you need to show the "little" people some kind of progress report and
cut all your tall poppy ****.
my solution would be to stop making firefox for mac if you can't be bothered making it work a top priority!!
from a former firefox fan and user
Lest this become a flamewar, Will Dunhaven is a guy who things saying "I don't know what the answer is, that's why you're stupid" shows how smart he is.

The issue with this bug is that it's likely with the communications between the MacOSX windowing framework and FF, it's not internal to FF itself, so people here are a little at sea.  MacOSX works in ObjectiveC, a stylized form of C that is fully functional, in some ways quite elegant, but in other ways a little "into itself" for some C devs.

What we have is basically the cool biker code (FF) isn't understanding the frilly Frenchman code (MacOSX) or vice versa ... and as a result, FF is getting confounded and delivering bizarre windowing.

As you can see, most of the Devs in FF are likely Windows or Linux people -- so they don't "feel the pain" and thus are focusing on other things.

Most likely, it's something relatively mundane like FF is referencing the window with 0 and MacOSX is interpreting it as -1 (that's completely fictional, don't discuss) ... and the result is bizarre behavior.

I'd gladly pay $100 to the person who fixes it, if it's done in the next update prior to 4.0.

Malcolm Mead
I bet this bug would have been fix ages ago if this was happening on windows. the dev team would have been falling over themselves to address the public with updated progress.
but hey if they would rather neglect mac users then fine, but I ask this if you want to be a TRUE cross platform app doesn't mean equality for all or are you all just as bias as Microsoft?
and I've tried firefox-4.0b2pre.en-US.mac.dmg still the same on my home iMac 10.6.4
On Firefox 3.5.10 no problem using OSX. No 'Double-Windows'. Use it and be happy. It works like a charm. On my macs even better as safari. Still enjoying all the Addons i miss on safari anyway...
http://www.mozilla.com/en-US/firefox/all-older.html

But PLEASE no flamewars on the developers. Support them, if possible. But grumbling does not help.
Tob74,

Thanks for the tip! I just reverted back to 3.5.10 per your suggestion, and it works like a charm.

I wonder what changed after this particular version that is causing the double window issue? Oh well, I am just happy for the workaround.

Regards,
Bryan
Bryan,
I'm wondering the same thing?
maybe it finding what changed in firefox will give a path to a solution.
but hey, The "DEVS" know all? right?
they would've tried this already?
As a Firefox developer, I implore everyone to stop commenting on this bug, and instead to follow Bugzilla etiquette, which can be found at https://bugzilla.mozilla.org/page.cgi?id=etiquette.html .

This bug is marked as blocking Firefox 4 final, meaning a fix will be found before Firefox 4 goes out the door, possibly sooner. Commenting here only slows us down.
@ Joe,
http://support.mozilla.com/en-US/forum/1/563509
If this wasn't closed we would have a place to talk about it but for some reason it has been marked as solved??. and no devs even bother to comment/give an update on status on these forums any way so HERE is the only place we have to air our thoughts, comments etc and actually see what is going on.
So maybe you devs need to address the end users to keep them up to speed.

Joe said "This bug is marked as blocking Firefox 4 final, meaning a fix will be found
before Firefox 4 goes out the door, possibly sooner."
I bet it's not holding up the Windows and Linux firefox 4 release is it.
All devs need to be a little less arrogant towards the end users as they are the ones using your product and ultimately keeping firefox mac alive.
(In reply to comment #91)
> I bet it's not holding up the Windows and Linux firefox 4 release is it.

Just do what Joe asked and instead follow Bugzilla etiquette, which can be found at https://bugzilla.mozilla.org/page.cgi?id=etiquette.html .

All the releases are always together as I know so ??? from where this statement???
@ Maaren,
Address the end user on a forum or somewhere end users can comment and hear from me and others no more!
http://support.mozilla.com/en-US/forum/1/563509

Why is that such a hard thing for you lot to do?

you talk about Bugzilla etiquette, which can be
found at https://bugzilla.mozilla.org/page.cgi?id=etiquette.html.
BUT!!! you seem to forget the little thing called Common Etiquette http://en.wikipedia.org/wiki/Etiquette.
Anyone reading this bug should be absolutely certain that the developers understand that this is a problem. There is no point whatsoever in posting comments like "still not working" or "fix this or I'll go back to Safari". This website is a tool for developers, not a general user feedback and venting forum. Access to post here is a privilege, not a right.

Those who are working on a product which you have the benefit of using free of charge do not deserve your abuse. Badgering people will not get this fixed faster. I have already disabled one person's Bugzilla account for misbehaviour and refusing to follow polite requests to cease in this bug. Please don't be the second person.

As for "updates": you will know this bug is fixed (in the latest development release) when it is marked as such. If it is not marked as such, it is not fixed. It's that simple.

Enough.

Gerv
Whiteboard: [read comments 50 & 65 before commenting] → [read comments 95, 50 & 65 before commenting]
Hail to the developers! May we be eternally grateful for their hard work.

I have just ditched Firefox in favour of Safari.

Can't stand kowtowing to people who freely give of their time for the benefit of the community. Pah! Let us pay and then we are entitled to moan as we please rather than be subject to a censorial policy.
Account disabled.

Gerv
Whiteboard: [read comments 95, 50 & 65 before commenting] → [read comments 94, 50 & 65 before commenting]
At the risk of having my account disabled, which at this point I actually would not mind, it must be pointed out that this bug constitutes a serious security concern.  Code (a window) is running without user control.  It is even more of a security concern since the code (with and without bug) is publically available so figuring how to exploit it would be easier.

I have stopped running FIrefox on all 5 of my Mac OS X computers and have switched to Safari and I strongly advise others to do the same.  And the Firefox devs should issue the same warning to all Mac Firefox users.

This is not a criticism of the Firefox devs, who I appreciate.  At one time I only did my banking online and it would not work under Safari so Firefox saved me a lot of trouble.   However, there is no room for loyalty in computer security.
When Firefox is running in the background (no open window but still running) desktop url icons, when opened, do NOT cause another window to open (in Mac OS X)
Added information that I did not see in previous posts.  I inadvertently hit the open from application twice before Firefox opened and ended up with three windows, two of which were from the request from application and one from the home page.
Still as a workaround for the problem of double opening windows in Firefox 3.6: With release of Firefox 3.6.7 today also 3.5.11 was released. Incl. all security patches.
http://www.mozilla.com/en-US/firefox/all-older.html

In OS X is Firefox 3.5.11 the first choice. Its safe, fast as 3.6 and concerning to the extensibility the right choice (regarding Safari etc.)
First Reported: 2009-11-28
The only response I got when submitting my report (see Bug 580899), is that I submitted a duplicate report, and to see Bug 531552.
Does this mean that nothing is being done to resolve it?
(In reply to comment #103)
> First Reported: 2009-11-28
> The only response I got when submitting my report (see Bug 580899), is that I
> submitted a duplicate report, and to see Bug 531552.
> Does this mean that nothing is being done to resolve it?

Pretty much..
(In reply to comment #104)
> (In reply to comment #103)
> > First Reported: 2009-11-28
> > The only response I got when submitting my report (see Bug 580899), is that I
> > submitted a duplicate report, and to see Bug 531552.
> > Does this mean that nothing is being done to resolve it?
> 
> Pretty much..

Josh can give an update, but this bug is marked blocking2.0: final+ which means it is a blocker for Mozilla 2.0 and Firefox 4.

/be
I'm close to being able to work on this again. As Brendan noted this is a Mozilla 2.0 blocker, so it will get attention soon one way or another. Hopefully the solution can be backported to Firefox 3.6.
Attached patch fix v1.0 (obsolete) — — Splinter Review 
This seems to work but I've only done limited testing so far so I'm holding off on review.
Attached patch fix v1.1 (obsolete) — — Splinter Review 
Includes a fix for 64-bit builds, use an AE processing API that doesn't require a 32-bit-only event conversion.

This fixes the URL case but doesn't fix the local document case. Working on it.
Attachment #460637 - Attachment is obsolete: true
Attached patch fix v1.2 — — Splinter Review 
Includes fix for the local file case.
Attachment #460652 - Attachment is obsolete: true
Attachment #460711 - Flags: review?(smichaud)
Sorry for the dumb question if it is one, but what does all this V1.1 and V1.2 etc stuff mean to me in layman's terms?
I'm just making it possible to reference patch revisions. It doesn't mean anything beyond simple labeling.
Attached patch 1.9.2 fix v1.2 (obsolete) — — Splinter Review 
Backport to 1.9.2 branch.
blocking2.0: final+ → betaN+
At the risk of being shot dead by the comment police...

*ahem*

woot.
Attachment #460711 - Flags: review?(b56girard)
Attachment #460711 - Flags: review?(b56girard) → review+
Attachment #460987 - Flags: review?(b56girard)
Attachment #460711 - Flags: review?(smichaud)
pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/db7e931c4410
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 460987 [details] [diff] [review]
1.9.2 fix v1.2

>+    EventRecord eventRecord;
>+    ::ConvertEventRefToEventRecord(carbonEvent, &eventRecord);
>+    ::AEProcessAppleEvent(&eventRecord);
>+    ::ReleaseEvent(carbonEvent);

I can't see why we would convert EventRef to EventRecord instead of doing it like on trunk. The documentation for ConvertEventRefToEventRecord doesn't confirm that a valid EventRef can always be converted without error, we should check the error return unless we are sure this is true.
'AEProcessEvent' is 10.5+ and the 1.9.2 branch is 10.4+. 'AEProcessEvent' was added by Apple because 'ConvertEventRefToEventRecord' is not available for 64-bit, so we use 'AEProcessEvent' on trunk for 64-bit compat and to avoid the conversion.

As for error checking, we should do that. I took that code from the 1.9.1 branch, we've never seen an error there as far as I know.
Attached patch 1.9.2 fix v1.3 (obsolete) — — Splinter Review 

        Attachment #460987 -
        Attachment is obsolete: true

        Attachment #461603 -
        Flags: review?(b56girard)

        Attachment #460987 -
        Flags: review?(b56girard)

        Attachment #461603 -
        Flags: review?(b56girard) → review+

    
    

    
  
Comment on attachment 461603 [details] [diff] [review]
1.9.2 fix v1.3

This patch comes with some risk but it fixes a pretty serious bug. We should definitely take this on the 1.9.2 branch, the sooner the better.

        Attachment #461603 -
        Flags: approval1.9.2.9?

    
    

    
  
Woah...

Does this mean it's fixed?

HOORAY!!!

    
    

    
  
Comment on attachment 461603 [details] [diff] [review]
1.9.2 fix v1.3

a=LegNeato for 1.9.2.9

        Attachment #461603 -
        Flags: approval1.9.2.9? → approval1.9.2.9+

    
    

    
  
backed out from 1.9.2 branch

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/369cee8ed17f

I tested this against the 10.6 SDK, NSInteger does not exist on the 10.5 SDK.

          status1.9.2:
          .9-fixed → ---

    
    

    
  
The problem is the 10.4 SDK, not the 10.5 SDK. NSInteger exists in the 10.5 SDK.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        1.9.2 fix v1.4
        — 
          — Splinter Review
      

    


  
use "int" instead of "NSInteger" for 10.4u SDK compat

pushed to mozilla-1.9.2

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/68b777734004

        Attachment #461603 -
        Attachment is obsolete: true

    
  

          status1.9.2:
          --- → .9-fixed

    
    

    
  
Backed out from mozilla-central to see if this is the cause for bug 584273.

http://hg.mozilla.org/mozilla-central/rev/faa353db92a2
http://hg.mozilla.org/mozilla-central/rev/dfd4d8582ef3
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
  
Summary: Firefox 3.6 opens two windows when opening external links → Firefox opens two windows when opening external links

    
    

    
  
I running firefox 4 b2 on mac (10.6) and have the continued issue should I try the patch ?

    
    

    
  
ahem sorry but when I click onto the "patches" on-top I get a diff instead .. I got here via a regular google search so this is not a closed dev section .. patch for me is either a .command terminal script, .pkg installer, or patched Firefox binary. Where is any of the above? A link with a download that actually helps would be very appreciated. Appreciating your work I don't think I am asking for too much. Thanks guys.

    
    

    
  
PS: forgot to mention, yes I read last comment #94 requested to be read, and yet, this bug has been known since at least the date it has been filed, 2009-11-28, which is 3/4 of a year, and this is s.th. which worked before just fine in 3.5.x so the correct code is known. Also please look here: http://support.mozilla.com/tiki-view_forum_thread.php?forumId=1&comments_parentId=563509 closed and marked as "solved". Please click onto "See solution! This problem has been solved", read and you will be very very surprised ....
Again: thank you for trying to help in a practical way. Just post a link to something usable (which I KNOW at least one of you have coded after 3/4 of a year) and you are creating happy instead of annoyed campers .. :-|

    
    

    
  
I think I get this (or similar) event, except that I get THREE tabs opened in a new window.  I'm running an old web editor program called Arachnophilia (4.0, Build 5310), which links to the selected browser for preview.  Opening all the other major browsers works one way or another.  But opening Firefox (3.6.8, and several previous versions) gives me a new window each time, with these specific items (and I don't know what specifies them):

Tab 1:  http://www.files.com/  which comes up.
Tab 2:  http://www.mozilla.com/en-US/firefox/firefox.exe   which always gives "404 page not found".
Tab 3:  The current page being tested (ONLY THIS tab should open).

Thanks for your work on this, guys.

    
    

    
  
Don't want to jump to conclusions; however, the latest release, 2.6.9, appears to fix this bug. I tested it (only) once so far, and FF opened correctly with only one window, the correct one from the link in my external document ... or I have expired and gone to a place where everything works perfectly. I will continue to strenuously test.

    
    

    
  
I just checked this using FF3.6.9 on three different links in Thunderbird with FF not running and only one window opened and it was the correct one all three times.

    
    

    
  
I'm impressed. The fix seems to work for me. I shut down Firefox and then clicked on the link that brought me here in the Apple Mail and voila, only one Firefox window opened! Thank you, thank you to the people who did this.

    
    

    
  
Sorry, all (mea culpa), I failed to note that after the FF 3.6.9 restart, the default "new in this FF version" window declared my Adobe Flash Player plug-in needed to be updated. I updated the plug-in prior to testing FF for this bug fix. So, maybe, one or both were required to result in my findings (comment 134).

I think it would be helpful for some to just one or the other (browser or the plug-in) and report their findings.

    
    

    
  
(In reply to comment #137)
> I think it would be helpful for some to just one or the other (browser or the
> plug-in) and report their findings.

I installed the FF update but didn't update Flash.  When opening a link from the Dock, I only get one window with the correct link.  When testing a page from Dreamweaver, I also only get one window with the correct link.

Nice work, folks!

    
    

    
  
I can confirm that this bug is fixed in 3.6.9

    
    

    
  
(In reply to comment #129)
> Backed out from mozilla-central to see if this is the cause for bug 584273.
Did we see this regression on the 1.9.2 branch?
Keywords: verified1.9.2

    
    

    
  
(In reply to comment #140)
> (In reply to comment #129)
> > Backed out from mozilla-central to see if this is the cause for bug 584273.
> Did we see this regression on the 1.9.2 branch?

The regression did not show up on the 1.9.2 branch because it was 64-bit only and the 1.9.2 branch does not have 64-bit support.

    
    

    
  
Further to Comment 133 - I'm still getting the problem [THREE tabs opened in a new Firefox window using Arachnophilia (4.0, Build 5310)] in FF 3.6.9 which I downloaded last night.  (The Flash plug-in was updated a few days ago, prior to #133.)  Since the two-windows problem has apparently been resolved, then I might be talking about a different issue.  I don't believe it to be a quirk in Arach because the other browsers don't open additional tabs AND the two first tabs opened in FF are both Mozilla pages.

Tab 1:  http://www.files.com/   - comes up as a normal page.
Tab 2:  http://www.mozilla.com/en-US/firefox/firefox.exe   - always gets
"404 page not found".
Tab 3:  My local page page being tested ("previewed" by Arach)   - only this tab should open.

Nor can I find the URL specs for these tabs stored anywhere that I can see.  They're definitely not my "home" page - I just go to a blank screen.

    
    

    
  
Further to Comment 142 (and 133):
I just noticed for the first time that I got two FF windows open when I clicked an external link (to THIS forum, in fact) from Thunderbird 3.1.3 (installed a few days ago).  Sorry, I don't click external links that often (whereas I work with Arachnophilia every day) so I can't say for sure it happened before.  I probably thought it was just a transient thing, but it happens now for sure.

ABOUT FF:  Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9

ABOUT TB:  Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3

    
    

    
  
This particular bug is considered confirmed fixed in Firefox 3.6.9 at this point. If you're having a problem with Firefox 3.6.9 or any other software based on the equivalent 1.9.2 branch code please open up a new bug.

    
    

    
  
I don't see what comment 143 sees. Using TB 3.1.3 and FF 3.6.9 only one window opens and it is the correct one. I have checked this on 17 different emails with FF not running and all is good.

NOTE: if you have FF set to open the profile manger first to select a profile, it will open your home page and not the link page.

    
    

    
  
TB 3.1.2 clicking external link (to this page) gives proper behavior on Mac Book Pro/Snow Leopard to FF/3.6.9

Also confirm that external calls from Quicksilver third party app launcher work correctly.

Thanks for all the Fish, fixers -- you rock.

God Bless Mozilla and Open Source.

    
    

    
  
Excellent - thank you very much.

    
    

    
  
Comment 143 resolved:  Duh, I always double-click links out of habit, and usually a double-click is treated as a single click if the context is similar.  But it looks like a double-click in TB opens two FF windows, single click opens one.  So I'll vote with Josh/144 and Robert/145 that the issue is resolved.

    
    

    
  
Sorry to bug you again but when right-clicking on a .htm(l) in the Finder and
choosing "Open with..." while FF is not running doesn't open a first blank
window and another one with the right-clicked file showing anymore but it still
opens the first blank window alone: need to drag'n'drop the file from the
Finder into that blank FF window (for instance).
Using FF 3.6.9 in OS 10.4.5.
I need this behavior since I'm testing on several browsers (double-clicking on
a .htm(l) file opening Safari by default).

Regards,
L.

    
    

    
  
Restoring cc'es that rb@memsys.nl removed.
Status: REOPENED → ASSIGNED

    
    

    
  
Please fix it on next firefox 4 beta too.

    
    

    
  
(In reply to comment #111)
> Created attachment 460711 [details] [diff] [review]
> fix v1.2

Josh, is this patch still up2date? Would be nice to see it landing on trunk.

    
    

    
  
Note above

blocking2.0: 	betaN+

Which as I understand means is planned to be fixed on one of the FF4 beta's, i.e., beta 8 or later since it not fixed on beta 7.

    
    

    
  
This is marked as a blocker, we just haven't got to it yet. We're not landing the patch as-is because it causes a performance regression in x86_64 builds.

    
    

    
  
Just updated to 3.6.13 - No Joy

    
    

    
  
Renominating.

It was pointed out to me that unintentionally opening extra windows is an issue for accessibility.

Aside its annoying and confusing, and shell integration issues particuarly annoy me. I stub my toe on this one about once a day.
blocking2.0: - → ?

    
    

    
  
We are planning to fix this, and hopefully for Firefox 4 final, but this will not block a release.
blocking2.0: ? → -

    
    

    
  
firefox for Mac and linux are dying fast !!! due to the lack of interest by you lot to address any issue on any system other than Windows... hence the mass migration to safari and chrome.. even ubuntu will be moving to chrome. and apple is looking to block firefox for mac due to the number of complaints by users about this issue. their recommendation is to uninstall all versions of firefox and use safari or chrome. 

note to devs.. the way you have handled this issue has done irreparable damage and I hope you wake up and realise you can not treat end users like **** just because you all think you are superior to others in some way! shame on you for the contempt you treat people with.

    
    

    
  
Account disabled. Abusing developers is not constructive input.

Gerv

    
    

    
  


  
Here's a simplified version of Josh's trunk patch that (in my limited
testing) fixes this bug on the trunk (in Minefield, which will become
FF4).

My simplification allowed me to remove the calls to ReceiveNextEvent()
and AEProcessEvent(), and to stop [MacApplicationDelegate
handleAppleEvent:withReplyEvent:] from handling the kAEOpenDocuments
event.  I have reason to hope these changes will avoid the performance
problems reported at bug 584273.  But I have no way of testing this,
short of actually landing my patch and seeing what happens.

I've already done some testing (which I'll describe in a later
comment).  But I need help from you guys to make sure my
simplifications haven't broken Josh's patch in some subtle way.

Here are two tryserver builds made with a slightly earlier version of
my patch (which should, for the purposes of fixing this bug, be
functionally equivalent to my current patch).  Please test them
against all the ways you have to reproduce this bug, and let us know
your results.

Build with fix:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/smichaud@pobox.com-dbeaf0ccd221/try-osx64/firefox-4.0b9pre.en-US.mac64.dmg

Build with fix and debug logging:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/smichaud@pobox.com-c44320ea8f96/try-osx64/firefox-4.0b9pre.en-US.mac64.dmg

I'll post new (current) tryserver builds when they become available
(probably in 5-6 hours).
Assignee: joshmoz → smichaud

        Attachment #499315 -
        Flags: review?(joshmoz)

    
    

    
  


  
Here's my patch from comment #160 with debug logging.

    
    

    
  
Here's how I tested.

It can be difficult to test for this bug if you have multiple copies
of Minefield on your hard drive(s):  Even if you make "Minefield" your
default browser, the OS arbitrarily picks one of your copies and
always runs that.  Here's one way around this problem:

1) "Install" one of my test builds somewhere on your computer (I used
   my Desktop).

2) Run the following command from Terminal (without the line breaks)
   to rebuild your Launch Services database:

   /System/Library/Frameworks/CoreServices.framework/ \
   Frameworks/LaunchServices.framework/Support/lsregister \
   -kill -r -domain local -domain system -domain user

   Be careful with this command -- used incorrectly it might make your
   system unbootable.  For more information see
   http://hints.macworld.com/article.php?story=20031215144430486.

3) Double-click on the test build you installed in step 1.  If
   prompted, choose Minefield as your default browser.  Then quit the
   test build.

   The OS should now always choose the test build from step 1 in the
   tests that follow ... until you double-click on some other copy of
   Minefield and/or Firefox.

Here are the tests I ran:

A) Double-click on a local *.html file (I used one on my Desktop).

B) Open a Terminal session and enter the following command:

   open http://www.mozilla.org http://www.mozilla.com http://www.apple.com

   This should open each of these URLs in a separate window.

C) Test using a word processor or text editor (I tried TextEdit and
   TextWrangler).

   1) Open a window in your word-processor or text editor.

   2) Type a URL in the window (e.g. http://www.mozilla.org).

   3) Right-click on the URL and choose "Open URL" (or the
      equivalent).

D) Test using an email client (like Thunderbird).

   1) Run your email client and load a message containing a URL -- for
      example one of the messages about this bug sent to you by
      bugzilla-daemon@mozilla.org.

   2) Click on the URL.

    
    

    
  
Comment on attachment 499315 [details] [diff] [review]
Simplified trunk patch

Clever, hope it clears up the Ts deviation!

        Attachment #499315 -
        Flags: review?(joshmoz) → review+

    
  

        Attachment #499315 -
        Flags: approval2.0+

    
    

    
  
Comment on attachment 499315 [details] [diff] [review]
Simplified trunk patch

Landed on trunk:
http://hg.mozilla.org/mozilla-central/rev/72d9ec027cba

We'll need up to a week before we know whether or not this patch re-regresses bug 584273.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED

    
    

    
  
With this patch it works great for me by using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110105 Firefox/4.0b9pre ID:20110105030550

Can we get at maximum 5 other confirmations from users who also experienced this problem? Please download the latest Minefield build for the test:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Thanks!
Target Milestone: --- → mozilla2.0b9

    
    

    
  
I just downloaded and installed Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110107 Firefox/4.0b9pre and can confirm it works!

    
    

    
  
Can confirm that the bug is fixed in 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110107 Firefox/4.0b9pre

    
    

    
  
confirm bug is fixed in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20110107 Firefox/4.0b9pre

    
    

    
  
Thanks for your feedback, no more are necessary. Marking this bug as verified fixed.
Status: RESOLVED → VERIFIED
Depends on: 633941

    
    

    
  
VERIFICATION REQUEST: Will this be fixed for PPC (PowerBook) G4? I cannot tryout the latest beta because it's intel only. If Mozilla no longer intends to support my platform, they really should announce it.

Please note, in the issue headers, Bugzilla references this issue discussion for all Mac OS X platforms.

    
    

    
  
Firefox 4 is Intel only, not only the beta. There will be no PPC support.

    
    

    
  
(In reply to comment #172)
> VERIFICATION REQUEST: Will this be fixed for PPC (PowerBook) G4? I cannot
> tryout the latest beta because it's intel only. If Mozilla no longer intends to
> support my platform, they really should announce it.

Which version of Firefox are you using? It doesn't seem to be Firefox 3.6.x, because it has already been fixed in Firefox 3.6.9.

    
    

    
  
Not sure about what you are calling "fixed" but FF 3.6.13 (when not running) still opens a blank window when right-clicking on a .HTM(L) file in the Finder.

Regards,
L.

    
    

    
  
(In reply to comment #175)
> Not sure about what you are calling "fixed" but FF 3.6.13 (when not running)
> still opens a blank window when right-clicking on a .HTM(L) file in the Finder.
> 
> Regards,
> L.

This bug is about clicking on a link in some app like email, not right clicking on a file in the Finder. See the OP from Brandon Shea.

I can verify that it was fixed in 3.6.? and is definitely not an issue in FF4b7/b11.

    
    

    
  
ah, the problem therein lies with a different bug issue that was deemed a duplicate of this bug; cannot open a htm(l) file in finder by contextual menu, or by double-clicking it.

Both bugs appeared at the same time; therefore, were flagged as the same issue.

One has been fixed, the other not.

So, us PPC users (I'm probably the last) will have to settle for 3.5.10 (no glitches, but no longer supported by many updated add-ons), or use the latest 3.X (one known glitch left - won't be fixed), because 4.X is intel only.

There, in a nutshell.

    
    

    
  
(In reply to comment #177)
> ah, the problem therein lies with a different bug issue that was deemed a
> duplicate of this bug; cannot open a htm(l) file in finder by contextual menu,
> or by double-clicking it.
> 
> Both bugs appeared at the same time; therefore, were flagged as the same issue.
> 
> One has been fixed, the other not.

Then that bug should be un-duped and re-opened. Which bug was it?

    
    

    
  
That "bug" doesn't exist in FF4. Since Apple has dropped support for PPC and is now on OSX 10.6.6 and has virtually dropped support for 10.4, it is unlikely that any application developers will worry about bugs that apply to obsolete HW and OS's.

Time to move on.

    
    

    
  
My sincerest apologies...
Please see comments 17 & 18, this bug.

    
    

    
  
my comment referring to PPC was #20

    
    

    
  
would love to move on; no job, no funds.

    
    

    
  
(In reply to comment #180)
> My sincerest apologies...
> Please see comments 17 & 18, this bug.

(In reply to comment #181)
> my comment referring to PPC was #20

I don't see any reference to a duplicate bug in any of those three comments.

Meanwhile, my question in comment 178 remains unanswered: which specific other bug *currently on file* in Bugzilla was incorrectly marked as a duplicate of this one? There are about 25 bugs marked as dupes of this one and none of them talk about the Finder or contextual menus (I looked).

re: comment 179: If the ultimate resolution to that bug is WONTFIX, that's fine, but right now it's incorrectly resolved and I'd like to fix that.

TLizard: If the issue you're describing is not actually on file in Bugzilla, please *do* file it as a new bug, and add my address to the CC list.

    
    

    
  
> I don't see any reference to a duplicate bug in any of those three comments.
> 
> Meanwhile, my question in comment 178 remains unanswered: which specific other
> bug *currently on file* in Bugzilla was incorrectly marked as a duplicate of
> this one? There are about 25 bugs marked as dupes of this one and none of them
> talk about the Finder or contextual menus (I looked).
> 
> re: comment 179: If the ultimate resolution to that bug is WONTFIX, that's
> fine, but right now it's incorrectly resolved and I'd like to fix that.
> 
> TLizard: If the issue you're describing is not actually on file in Bugzilla,
> please *do* file it as a new bug, and add my address to the CC list.

Chris,
Apologies, again; my previous "apologies" comment should have actually stated that I had initiated a bug fix request for all the issues that have been fixed, including the lack of opening a html page from Finder, but it was flagged as a duplicate of this bug. I reviewed the previous comments before commenting (#20). All issues reported were the same as mine, except I was on a PPC (PowerBook, G4, OS X 10,5.8). So I commented to ensure my platform was not left out of the fixes. I have forgotten the bug number I originally initiated.

I will do as you ask: I will initiate another Bug report, and I will refer to comments #17, #20, #175, mentioning the specific issue for PPC was not resolve in FF 3.6.13.

OR, I will initiate a new Bug resolution without mentioning this Bug or the previous comments cited in the previous paragraph. Your choice.

Or I can

    
    

    
  
(In reply to comment #184)

> Chris,
> Apologies, again; my previous "apologies" comment should have actually stated
> that I had initiated a bug fix request for all the issues that have been fixed,
> including the lack of opening a html page from Finder, but it was flagged as a
> duplicate of this bug.

*Which* bug was flagged as a duplicate of this bug?

    
    

    
  
(In reply to comment #185)
> (In reply to comment #184)
> 
> > Chris,
> > Apologies, again; my previous "apologies" comment should have actually stated
> > that I had initiated a bug fix request for all the issues that have been fixed,
> > including the lack of opening a html page from Finder, but it was flagged as a
> > duplicate of this bug.
> 
> *Which* bug was flagged as a duplicate of this bug?

I do not recall, and I didn't store the number anywhere. It was over a year ago. And when I perform a Bugzilla filter request on my e-mail, I get no results, at all. So I can't tell you.

    
    

    
  
Chris,

Do you think my issue should be listed in
"Shell Integration" (Areas where Firefox integrates with the host desktop environment. Please use the "Theme" component for any Theme-related issues. Please use the "Core" product for other OS integration problems.)?

OR in "General" (For bugs in Firefox which do not fit into other more specific Firefox components)?

I'm motivated toward the former.

    
    

    
  
For future reference, you can see all the bugs you've ever filed in Bugzilla with this link:

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&emailreporter1=1&email1=tle.bull%40gmail.com&emailtype1=exact

(Obviously that link is specific to TLizard; anyone else interested in looking up their own bug history should substitute their own %-escaped e-mail address.)

I've found the bug in question and re-opened it. Thanks for your patience.

    
    

    
  
Oops. Meant to mention that it was bug 574016, though anyone following the link in comment 188 would see that clearly.

    
    

    
  
As a followup to the recent post by Lara, I believe this bug is not completely fixed. If I right click on a file with an htm or html extension and try to open it, FF launches but stays at my homepage, without opening the page requested. This is from a "cold" launch of FF. If FF is already running, then the requested file opens as expected. 
Both Safari and Chrome do this as expected from a "cold" launch.

I am using Mac OS X 10.6.6 and Firefox 4.0b11.

I thought this bug had been tested and resolved, but apparently not completely. So to whom it may concern, can someone please reopen this bug if not done so already? (I'm not a developer)

Regards,
Marshall

    
    

    
  
(In reply to comment #191)

> So to whom it may concern, can someone please reopen this bug if not done so
> already? (I'm not a developer)

I think that might actually be bug 553437, which I just confirmed. Still happens in Minefield.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110221 Firefox/4.0b12pre ID:20110221030349

    
    

    
  
Zandr: both comment 191 and bug 553437 sound like bug 633941, to which bug 553437 should probably be forward-duped.

    
    

    
  
This bug is still present or exists again with Firefox 45.0.1 (and some prior versions) on OS X 10.11.4.

Firefox 45.0.1 builds open two windows when clicking external links. 

Reproducible: Always

Steps to Reproduce:
1. Quit Firefox completely.
2. Click an external link from a program like Mail, etc.

Actual Results: Two windows are created, one with your home page, one with the link you clicked.

Expected Results: Only one window should open with the external link, and the homepage should not be loaded.

Notes:
- It only occurs on the initial launch of FF from an external link (e.g., email); if FF is already opened this does not occur.
- my "Home Page" is blank

    
    

    
  
In reply to LTorunski from comment #194:

What email program are you running?  I'm wondering if the problem is actually with Thunderbird (or a simlar Mozilla-based email package).  My Windows settings are set to use a double-click to activate links and icons.  Works fine for everything -- I get one instance of whatever I click.

But see my Comment #148:
> I always double-click links out of habit, and usually a double-click is treated 
> as a single click  if the context is similar.  But it looks like a double-click 
> in TB opens two FF windows, single click opens one.

Nothing has changed here.  Double-click from a link in TB opens two FF windows, exactly as you say.  Double-click with FF running opens two tabs in the current FF window.  (In other words, double-clicking two items gives me one window with one tab, and a second window now with three tabs.)

The fact that my system works normally with regard to clicks (and FF seems to work OK otherwise in that regard) makes me wonder that the source of the click -- Thunderbird in this case -- is the culprit.

    
    

    
  
In reply to Marshall from comment #191:

I'm running Windows 7/32 (Pro).  When I right-click an HTM file, it opens once-only in FF from a cold start.  Right-clicking a second file opens a new tab in the window -- in other words, normally.

And additional to my Comment 195:  A single-click of an email link in TB opens FF once, which is consistent with a double-click being treated as two single discrete clicks in TB.

    
    

    
  
(In reply to Dan Pernokis from comment #195)

> In reply to LTorunski from comment #194:
> What email program are you running?  I'm wondering if the problem is
> actually with Thunderbird (or a simlar Mozilla-based email package).  My
> Windows settings are set to use a double-click to activate links and icons. 
> Works fine for everything -- I get one instance of whatever I click.

I'm using Mail from Apple on my MacBook Pro. And a single click on the link opens two windows.

    
    

    
  
(In reply to LTorunski from comment #194)
> This bug is still present or exists again with Firefox 45.0.1 (and some
> prior versions) on OS X 10.11.4.
> 
> Firefox 45.0.1 builds open two windows when clicking external links. 
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Quit Firefox completely.
> 2. Click an external link from a program like Mail, etc.
> 
> Actual Results: Two windows are created, one with your home page, one with
> the link you clicked.
> 
> Expected Results: Only one window should open with the external link, and
> the homepage should not be loaded.
> 
> Notes:
> - It only occurs on the initial launch of FF from an external link (e.g.,
> email); if FF is already opened this does not occur.
> - my "Home Page" is blank

I have had this exact issue for a couple of years (from at least FF version 35.x onwards). I've tried running with all extensions disabled and even created a new profile. I believe this bug was never truly fixed.

    
    

    
  
Still present Firefox 50.1.0 (first time for any version on this machine: Mountain Lion to Sierra 10.12.1, Homebrew).

Any external link from a local file or script opens two windows (Home page and link).

If Firefox is already running only new tab opens with URL.

Reproducible: Always

    
    

    
  
Per comment #144, this bug was fixed (and confirmed fixed) for over 6 years ago. Any new/remaining issue should go in a new/separate bug.

    
    

    
  
I'm running FF 50.1.0 as well, and I'm still having the issue clicking from Thunderbird:  Without FF running, a single click opens one window in FF, a double-click opens two windows (not tabs) of the same page.  Once FF is running, a single click opens one tab in the current window, a double-click opens two tabs (of the same page) in that window.  I've just learned to be careful with it, and usually just click once in TB.  But when I click two, I get two.

Double-clicks on anything else on my computer always results in one instance of it -- as it should with my Windows 7 configuration of how to handle clicks -- including FF!  Double-clicking .htm files in Explorer opens FF and loads a single instance, launching FF or creating a single tab if already running.  And clicking or double-clicking a link from a page in FF opens in the same tab (or creates a new tab if specified in the URL).

I've said previously (Comment #195) that the source of the click may have a bearing on what FF hears.  My TB always does this, LTorunski's Apple MacPro does too (Comment #197), yet several other people -- including myself right here -- say links do correctly give only single instances.

So what "deep" configuration info should we be providing that might help solve this apparent duality?

    
    

    
      
  

    
    

    
      
  

    
    

    
  
NOTE:  This bug has been re-filed as recommended in Comment 200 and Comment 203.   See Bug 1370445.

    
    

    
  
This bug filed first in November 2009 prevails. FF 62.0.2, macOS High Sierra 10.13.6, new virgin user profile, no add-ons.

It is described well at https://support.mozilla.org/en-US/questions/735508, there posted July 2010.

The steps outlined at https://support.mozilla.org/en-US/questions/1199189#answer-1062931 do NOT solve this bug in regards to .webloc shortcuts opened via double click in macOS Finder. These .webloc files were created via drag & drop from the address bar into Finder

This bug was assigned to Steven Michaud [:smichaud] who retired, so it needs to be re-assigned, and hopefully fixed.

Is the macOS Mozilla coder community really that tiny?

Anyways, thank you, folks.

    
    

    
  
Still present in Firefox 73.0.1.


Any external link from a local file or script opens two windows (Home page and link). If Firefox is already running only new tab opens with URL.


Reproducible: Always



    
    

    
  
(In reply to Csaba E. Simon from comment #206)




Still present in Firefox 73.0.1.


Any external link from a local file or script opens two windows (Home page and link). If Firefox is already running only new tab opens with URL.


Reproducible: Always




Please file a new bug.



    
    

    
      
  

    
    

    
      
  

    
    

    
  
Please file a new bug.


This bug is very old, and is Mac-specific. What you're seeing is probably new and unrelated.



    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: