Tim O' Reporter
	Description • 18 years ago

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a2) Gecko/20060512 Firefox/1.5 iTunes
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a2) Gecko/20060512 Firefox/1.5

When opening a URL from another application, e.g. NetNewsWire, the URL loads in Bon Echo, but the window doesn't come to the front or even restores, if minimized, as FF 1.5 did.

Also, clicking the window content doesn't bring it to front, only clicking the title bar works.

Reproducible: Always

Steps to Reproduce:
Click a link in an external app.
Bon Echo window doesnt come to front or restores from the dock.
Click window content - no result
Click title bar - window comes to front

	Tim O' Reporter
	Comment 1 • 18 years ago

btw, this behavior was present in certain pre-FF1.5 builds as well.

	Mark Mentovai Assignee
	Comment 2 • 18 years ago

This positively sounds like an interaction with Java.  If BonEcho had loaded Java prior to your attempting to load a URL from an external application, you could have experienced this bug.  I'm duping this to bug 344150 - if your bug was not Java-related, please reopen.

*** This bug has been marked as a duplicate of 344150 ***

	Steven Michaud [:smichaud] (Retired)
	Comment 3 • 18 years ago

My hunch is that this is (at most) only partially a Java problem.

Reporter, your BonEcho build is rather old.  Please try again using a
current 1.8 branch nightly build.

Here's what I found with the 20060718 BonEcho (1.8 branch) nightly,
testing on OS X 10.4.7:

If BonEcho is already running and all of its windows are minimized, a
URL opened from another application opens in a new tab in one of those
windows, but the window doesn't get un-minimized.  This happens
regardless of whether Java is running (regardless of whether you've
loaded at least one Java applet during your browser session).

But if BonEcho is already running and has been "hidden", the URL opens
in a new window (if no windows were open before BonEcho was hidden) or
in what was the front-most window before BonEcho was hidden (if one or
more windows were open), and that window gets displayed and becomes
front-most.  Once again, Java makes no difference.

The "other application" I used was TextEdit:  I typed in a URL,
control-clicked on it and chose "Open URL".

> Also, clicking the window content doesn't bring it to front, only
> clicking the title bar works.

This is the only part of your report that might be Java-related, but I
wasn't able to reproduce it.  If you aren't able to reproduce it with
a recent BonEcho nightly, I think we can count that part of your
problem (whatever it was) as fixed.

	Mark Mentovai Assignee
	Comment 4 • 18 years ago

> If BonEcho is already running and all of its windows are minimized, a
> URL opened from another application opens in a new tab in one of those
> windows, but the window doesn't get un-minimized.

It doesn't?  Uh-oh.  It does for me.  I saw the bit about not activating without clicking the title bar and lumped it in with the similar Java bugs.

	Steven Michaud [:smichaud] (Retired)
	Comment 5 • 18 years ago

I just redid my tests with a freshly downloaded copy of the latest 1.8
branch nightly (2006-07-19-03-mozilla1.8), using a fresh profile (I
renamed ~/Library/Application Support/Firefox and
~/Library/Application Support/FullCircle) -- I got exactly the same
results.

Have you (Mark) tried using a fresh profile?

Does it make a difference which "other application" you use to open a
URL in BonEcho?

	Steven Michaud [:smichaud] (Retired)
	Comment 6 • 18 years ago

Here's something very interesting:

I get the same results as you (Mark) if the copy of Firefox/BonEcho
that I have running (with all its windows minimized) _isn't_ the one
the OS has marked as the "default web browser" -- the window in which
I open a URL (from TextEdit) gets un-minimized.

But it _doesn't_ get un-minimized if the copy of Firefox/BonEcho I
have running _is_ the "default web browser".

Bizarre!

	Mark Mentovai Assignee
	Comment 7 • 18 years ago

How are you setting a specific installation as the "default web browser?"  LaunchServices only allows registration by bundle ID - I have "org.mozilla.firefox" registered for the "http" scheme, which corresponds to 16 (yup, that's right, count 'em) bundles.

(As reported by lsregister -dump.)

	Steven Michaud [:smichaud] (Retired)
	Comment 8 • 18 years ago

> How are you setting a specific installation as the "default web
> browser?"

By trial and error -- whichever one gets launched when no other copy
is running (for example when I try to open a URL from TextEdit) is the
one that I've picked :-)

It's usually quite difficult to change your pick from one copy of
Firefox/BonEcho to another.  But once the OS has decided to open a
particular copy, it seems to keep picking that one until you (somehow)
persuade it to do otherwise.

Here's what I usually have to do to change the "default web browser"
from one copy of Firefox/BonEcho to another:

1) Change the "Default Web Browser" setting in Safari (usually by
   choosing Select and selecting it's location on your hard drive)
2) Dragging the copy that was previously "Default Web Browser" to the
   Trash (temporarily).
3) Open a URL from another application, to see if the "right" copy
   gets picked.
   a) If it has, drag the copy from step 2 out of the Trash.
   b) If it hasn't, keep fiddling.

(What Safari displays as the current "default web browser" often isn't
the one that the OS actually picks to load a URL.)

	Mark Mentovai Assignee
	Comment 9 • 18 years ago

How incredibly heinous!  Excellent find.  I'm able to reproduce this according to your procedure - sometimes.  I can reproduce on the trunk and 1.8 branch.  At first, I thought that the 1.5.0.4 release was immune, but then I saw the bug there a couple of times, and now I can't reproduce it there again.  Go figure.

I notice that when the app is the default handler and the window does raise on its own, I can't type into text fields.  That smells like bug 294476, but I don't think we're experiencing raw 294476 here.  I bet we're not getting the kEventWindowExpanded event, probably for the same reason that the OS isn't raising the window for us.  I haven't done any debugging to figure out if that's really the case yet, it's just a hunch.

Tim, if you can find a regression window before I get a chance to debug this, it would be most helpful.

	Mark Mentovai Assignee
	Comment 10 • 18 years ago

(The "regression" keyword was added when I couldn't reproduce in 1.5.0.4 - I'm not positive this is a regression, though.)

	Mark Mentovai Assignee
	Comment 11 • 18 years ago

The text input problems are occurring because when the app is brought into the foreground and the window is raised (or should be raised?) from this state, the hidden window is deactivated after the target window is activated!  This causes the TSM state (and other things) to get entirely messed up.  Here's the event sequence:

Minimize browser window:
toplevel kEventWindowActivated
toplevel kEventWindowCollapsing

Click on a URL in another application:
hidden   kEventWindowActivated
toplevel kEventWindowDeactivated
hidden   kEventWindowDeactivated
toplevel kEventWindowActivated
hidden   kEventWindowDeactivated  # the problem - why do we get this twice?
toplevel kEventWindowExpanded

My patch in bug 344006 (attachment 228701 [details] [diff] [review]) will fix the unresponsive keyboard problem.  It'll also fix bug 344150, so I'm starting to think that it's a good idea and we should take it.

I don't know if that patch fixes the inability to raise windows - what this bug is really about - because I can't reproduce (again).  How frustratingly slippery.

	Mark Mentovai Assignee
	Comment 12 • 18 years ago

The only way I am able to reproduce this bug is when the browser is the active application with all windows collapsed to the Dock, and you manage to get another application to request a URL without ever making the browser the inactive application.  This occurs on all branches.  Could this be what everyone is seeing?

To reproduce: open TextEdit, type http://google.com into a new document, and select the text.  Leave this window visible on the screen.
Open the browser with a single window, and minimize that window to the Dock.
Without switching to another application, right-click (or command-click) the selected text in TextEdit, and choose the "Open URL" command.

Expect: collapsed browser window to expand, link opens in a new tab
Observe: browser window remains collapsed in the dock

	Mark Mentovai Assignee
	Comment 13 • 18 years ago

Bug 344006 won't fix failure to raise, but it will fix the text input problems (comment 9, comment 11).

	Mark Mentovai Assignee
	Comment 14 • 18 years ago

This fixes the issue according to the steps to reproduce in comment 12.  I imagine it also fixes other potential bugs where windows might fail to expand from the Dock when they're supposed to become visible.

	Steven Michaud [:smichaud] (Retired)
	Comment 15 • 18 years ago

> The only way I am able to reproduce this bug is when the browser is
> the active application with all windows collapsed to the Dock, and
> you manage to get another application to request a URL without ever
> making the browser the inactive application.  This occurs on all
> branches.  Could this be what everyone is seeing?

Yes, this is what I just saw.  I tested with Firefox 1.5.0.4 and the
2006-07-19-03 BonEcho nightly on OS X 10.4.7.

I figure that last night I just didn't notice that I hadn't made
TextEdit active.

	Josh Aas
	Comment 16 • 18 years ago

Comment on attachment 229987 [details] [diff] [review]
Raise/expand/restore/uncollapse collapsed windows on Show

+    if (::IsWindowCollapsed(mWindowPtr))
+      ::CollapseWindow(mWindowPtr, PR_FALSE);

I'd rather you didn't pass gecko true/false to carbon functions. Otherwise looks good.

	Mark Mentovai Assignee
	Comment 18 • 18 years ago

Checked in on the trunk.

	David Baron :dbaron:
	Comment 19 • 18 years ago

Comment on attachment 229989 [details] [diff] [review]
As checked in

a=dbaron on behalf of drivers.  Please check in to MOZILLA_1_8_BRANCH and mark fixed1.8.1 after doing so.

	Mark Mentovai Assignee
	Comment 20 • 18 years ago

Checked in on MOZILLA_1_8_BRANCH before 1.8.1b2.