Clicking URLs from within Mac OS X native apps, brings Web App to front

VERIFIED FIXED in Firefox 15

Status

Firefox Graveyard
Webapp Runtime
P1
normal
VERIFIED FIXED
5 years ago
a year ago

People

(Reporter: Dan Horner, Assigned: Gavin)

Tracking

unspecified
Firefox 15
x86
Mac OS X
Bug Flags:
in-moztrap -

Details

(Whiteboard: [blocking-webrtdesktop1+], [qa!])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
Additional info: 

When I close Checkers, clicking on URLs from native mac apps correctly brings Nightly to the front.
This sounds similar to bug 716689, should we reopen it? Is this bug a dup of that bug? A dependency?

Updated

5 years ago
Priority: -- → P1
Whiteboard: [blocking-webrtdesktop1+]
Target Milestone: --- → M1
Component: Desktop Runtime → Webapp Runtime
Product: Web Apps → Firefox

Updated

5 years ago
Target Milestone: M1 → Firefox 15

Updated

5 years ago
blocking-kilimanjaro: --- → ?
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?
Try to reproduce this bug in today's mozilla-central nightly.  It may have been fixed by bug 748389.
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!
(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

5 years ago
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.
see also bug 302925
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.
Created attachment 625824 [details] [diff] [review]
don't specify CFBundleSignature in web app bundles
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #625824 - Flags: review?(smichaud)
Attachment #625824 - Flags: review?(dwalkowski)

Comment 11

5 years ago
Given that wiki entry, I'd probably try changing CFBundleSignature to ???? (four question marks) instead of omitting it.
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
Attachment #625824 - Flags: review?(smichaud) → review+
see also bug 323288

Comment 14

5 years ago
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

5 years ago
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)
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

5 years ago
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.

Updated

5 years ago
Attachment #625824 - Flags: review?(dwalkowski) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/7b352f6f047f
https://hg.mozilla.org/mozilla-central/rev/7b352f6f047f
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Whiteboard: [blocking-webrtdesktop1+] → [blocking-webrtdesktop1+], [qa+]
Verified on OS X 10.7.
Status: RESOLVED → VERIFIED
Whiteboard: [blocking-webrtdesktop1+], [qa+] → [blocking-webrtdesktop1+], [qa!]

Updated

5 years ago
Flags: in-moztrap?(jsmith)
blocking-kilimanjaro: ? → +

Updated

5 years ago
QA Contact: desktop-runtime → jsmith

Updated

5 years ago
Flags: in-moztrap?(jsmith) → in-moztrap-
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.