Last Comment Bug 755355 - Clicking URLs from within Mac OS X native apps, brings Web App to front
: Clicking URLs from within Mac OS X native apps, brings Web App to front
Status: VERIFIED FIXED
[blocking-webrtdesktop1+], [qa!]
:
Product: Firefox Graveyard
Classification: Graveyard
Component: Webapp Runtime (show other bugs)
: unspecified
: x86 Mac OS X
: P1 normal
: Firefox 15
Assigned To: :Gavin Sharp [email: gavin@gavinsharp.com]
: Jason Smith [:jsmith]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-15 09:54 PDT by Dan Horner
Modified: 2016-03-21 12:39 PDT (History)
9 users (show)
jsmith: in‑moztrap-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
don't specify CFBundleSignature in web app bundles (1.13 KB, patch)
2012-05-21 16:53 PDT, :Gavin Sharp [email: gavin@gavinsharp.com]
dwalkowski: review+
smichaud: review+
Details | Diff | Splinter Review

Description Dan Horner 2012-05-15 09:54:56 PDT
Running Nightly, with Firefox 13.0 (GA) selected as default browser in Safari's preference pane. Web App 'Checkers' also open and running in background.

When I click a URL from a native app (e.g. Colloquy, Adium, Skype), instead of launching in my default browser  - which it can't as Nightly is running, not Firefox - it brings Checkers to the front, not another browser.
Comment 1 Dan Horner 2012-05-15 09:56:52 PDT
Additional info: 

When I close Checkers, clicking on URLs from native mac apps correctly brings Nightly to the front.
Comment 2 Jason Smith [:jsmith] 2012-05-15 10:10:34 PDT
This sounds similar to bug 716689, should we reopen it? Is this bug a dup of that bug? A dependency?
Comment 3 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-05-21 15:07:02 PDT
I don't understand how this could be happening - AFAIK Mac uses the bundle IDs to track this kind of stuff, and the Web App runtime has a unique bundle ID (set to the web app's origin apparently: http://hg.mozilla.org/mozilla-central/annotate/38c9289bdf6d/browser/modules/WebappsInstaller.jsm#l579).

Dan, can you reproduce this consistently?
Comment 4 Steven Michaud [:smichaud] (Retired) 2012-05-21 15:27:29 PDT
Try to reproduce this bug in today's mozilla-central nightly.  It may have been fixed by bug 748389.
Comment 5 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-05-21 16:20:32 PDT
I think that's unlikely, since that bug only changed the bundle version of Firefox.app, which I don't think is relevant here - this bug is OS X finding a web app bundle and focusing it, that was OS X (via our discovery code) finding the wrong Firefox bundle to use for launching. But there's a lot about this bug that doesn't make sense to me, so maybe I'm just confused!
Comment 6 Jason Smith [:jsmith] 2012-05-21 16:23:26 PDT
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #5)
> I think that's unlikely, since that bug only changed the bundle version of
> Firefox.app, which I don't think is relevant here - this bug is OS X finding
> a web app bundle and focusing it, that was OS X (via our discovery code)
> finding the wrong Firefox bundle to use for launching. But there's a lot
> about this bug that doesn't make sense to me, so maybe I'm just confused!

Note - We did have a bug in the past involving this with the extension, so there definitely is a possibility that we still have the same problem here in the mozilla central implementation.
Comment 7 Dan Walkowski 2012-05-21 16:29:13 PDT
Bill and I, while talking about how this couldn't possibly be happening, discovered how it is happening.  We (Mozilla) are still including the legacy application identifier code 'MOZB' in the Info.plist of all our various Firefox releases, as well as the webapps.  When the OS isn't sure which app you mean, it appears to be falling back to using that identifier to choose.

We were able to replicate Dan Horner's bug, repeatably. And then made it disappear repeatedly, by removing:

	<key>CFBundleSignature</key>
	<string>MOZB</string>

from the Info.plist generated for all webapps.

Gavin, as this key is ancient, and has been superceded by CFBundleIdentifier, it should probably be removed from all builds of Firefox form now on, permanently.
Comment 8 Bill Walker [:bwalker] [@wfwalker] 2012-05-21 16:47:08 PDT
see also bug 302925
Comment 9 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-05-21 16:51:04 PDT
OK, we can certainly do that. Is there any documentation about it being deprecated?

https://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/TP40009249-SW8

doesn't mention anything, and I noticed that most of my other apps still specify it.

http://cocoadev.com/wiki/CFBundleSignature suggests that it somehow still impacts behavior.

I guess to start we could stop specifying it in the web app bundles.
Comment 10 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-05-21 16:53:40 PDT
Created attachment 625824 [details] [diff] [review]
don't specify CFBundleSignature in web app bundles
Comment 11 Wevah 2012-05-22 03:17:55 PDT
Given that wiki entry, I'd probably try changing CFBundleSignature to ???? (four question marks) instead of omitting it.
Comment 12 Steven Michaud [:smichaud] (Retired) 2012-05-22 09:14:30 PDT
Comment on attachment 625824 [details] [diff] [review]
don't specify CFBundleSignature in web app bundles

This looks fine to me.

We probably don't want to do this with Firefox itself, if only because whatever problems it triggers might take a very long time to shake out.  As best I can tell keeping a CFBundleSignature in FF's Info.plist doesn't cause any actual harm.

> Given that wiki entry, I'd probably try changing CFBundleSignature to ????
> (four question marks) instead of omitting it.

Without doing extensive testing, I simply don't know what to say about this.  I'd guess that setting CFBundleSignature to ???? is equivalent to omitting it.

I searched in the /Applications directory on FF 10.7.4 for Info.plist files that had CFBundleSignature set to ???? or missing altogether.  I found quite a few matches for each.

Here are the commands I used.  Watch for line breaks.

To find Info.plist files whose CFBundleSignature is ????:
find /Applications -name Info.plist -exec grep -H -C 1 CFBundleSignature \{\} \; | grep \?\?\?\?

To find Info.plist files that don't contain a CFBundleSignature:
find /Applications -name Info.plist -exec grep -H -c CFBundleSignature \{\} \; | grep 0
Comment 13 Bill Walker [:bwalker] [@wfwalker] 2012-05-22 10:51:22 PDT
see also bug 323288
Comment 14 Dan Walkowski 2012-05-22 10:55:34 PDT
It -might- be the case that BundeSignature still has some relationship to tagging files that belong to an app.  Just to be the most cautious, let's leave MOZB in Firefox.

However, having it in the generated webapp Info.plist files is definitely wrong, and it must be removed.  It is unneeded, and the BundleID is all we need there.
Comment 15 Dan Walkowski 2012-05-22 10:57:44 PDT
No, we do not want to put random characters into the BundleSignature.  They are all valid, and they might match some other application.  We should just remove it from all webapps generated on the Mac.  

And leave everything as-is in Firefox. (MOZB)
Comment 16 Steven Michaud [:smichaud] (Retired) 2012-05-22 11:12:09 PDT
By the way, I don't think ???? is just random characters, or that it matches all possible signatures.

As I remember it, when you create a new app in XCode (and don't explicitly set the CFBundleSignature) you get an Info.plist file with CFBundleSignature set to ????.  This, together with the evidence I gave in comment #12, suggests that setting CFBundleSignature to ???? is the same as omitting it.
Comment 17 Dan Walkowski 2012-05-22 11:27:37 PDT
I think those are just people who forgot to change it from the Xcode default.  Any 4 chars are as valid as any others in the signature.  Even unprintable ones.  At this time, it appears to only be used for optional document association.  For apps with no documents, any string there is likely ignored.
Comment 18 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-05-22 14:06:36 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/7b352f6f047f
Comment 19 Ed Morley [:emorley] 2012-05-23 05:05:38 PDT
https://hg.mozilla.org/mozilla-central/rev/7b352f6f047f
Comment 20 Jason Smith [:jsmith] 2012-05-24 18:20:21 PDT
Verified on OS X 10.7.

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