273977 - Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?)

Status: RESOLVED WONTFIX

(Thunderbird :: General, defect)

Description

[Chris Andrichak]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5 (KHTML, like Gecko) Safari/125.9
Build Identifier: 1.0 release

IListen is the only currently developed and supported voice recognition application on Macintosh, and is 
very useful to those of us who cannot type for various reasons.

In iListen you can create custom command sets for applications, and iListen recognizes when and 
application has been started and activates its respective command set. You can create a command set 
for Thunderbird, but iListen does not then recognize when the application has been started and so does 
not ever activate its command set. The iListen developers have this to say:

"We detect that a program is running by a notification from the 
operating system of a "Application Switched" event. We get the 
program's PSN from the event, then from that we get the PSN 
information record. That record has the application's name. We use 
that name to match against the available application-specific command 
sets. If we find a match, then that command set is loaded.

The program name must exactly match the command set name. Now Mac OS 
X likes to hide parts of the name - the extension. So that program 
might really be called "Thunderbird.app", but you see "Thunderbird".

If we can't get a program name because the application does not have 
a PSN (process serial number) or a corresponding PSN information 
record, we can't load the command set."


Mozilla and fireFox have the same problem, but Camino does not.

Reproducible: Always
Steps to Reproduce:
1. create iListen app-specific command set for T-bird
2.start T-bird
3.see that iListen has not activated the command set

Comment 1

[sairuh (rarely reading bugmail)]

I saw this in the MacSpeech-Support mailing list, and since bug 275706 covers
the Firefox equivalent, this should be confirmed.

Josh, would you be able to look at this one?

Comment 2

[Chris Andrichak]

Attachment: Patch - proposed fix - change name of executable file in package

this patch fixes the problem through a regular and distribution clean build (building against the 1.5.0.2 branch, I doubt this code has changed very much in current. Will check.). The resulting application works correctly with iListen.

The list changes are simple, the Makefile changes I suppose could have come later in the Makefile, when it is actually copying all the files into the Macintosh package, but this seemed more appropriate.

Comment 3

[Chris Andrichak]

Attachment: Patch against current branch files

And as I figured, nothing changed in these files before the changes that I made, so the only difference in the diffs are the revision numbers

Comment 4

[Scott MacGregor]

Comment on attachment 217422 [details] [diff] [review]
Patch against current branch files

hopefully this change won't impact our build scripts.

Comment 5

[Josh Aas]

Comment on attachment 217422 [details] [diff] [review]
Patch against current branch files

I know mark isn't sr, but I want him to review this and I can't request another normal review via flags...

I suspect this won't be as safe as it seems.

Comment 6

[Mark Mentovai]

Comment on attachment 217422 [details] [diff] [review]
Patch against current branch files

The app bundle's name is ThunderbirdDebug during a debug build.  I'd be pleased to see that *Debug stuff become extinct, so I won't complain about that as long as someone files a followup bug to kill it.

But there's a bigger problem here.  We don't want to hardcode this, because the app package name is not a constant.  It needs to come out of $(MOZ_APP_DISPLAYNAME).

The |thunderbird| script (from |mozilla.in|) already isn't built on the Mac - good - we should get rid of run-mozilla.sh too.

Comment 7

[Chris Andrichak]

I may be off base with this, but would this change affect anything with talkback? Just noticing some of the Mac talkback problems seem to be related to the executable name.

Comment 8

[Mark Mentovai]

Not really Talkback specifically, but some of the things that Tinderbox does identify which product is being built by the binary name from tinder-config.  If the executable name changes from thunderbird-bin/firefox-bin to something variable, tinderbox will need a new way to know which product is being built on the Mac.  That change would need to be in tinderbox before landing anything that changes the binary name.  (Cc preed so he's in the loop.)

Talkback doesn't require anything special here, except the main executable in the symbol archive needs to have the same name that it does in the bundle.  Since the symbol archive is produced by tarring up all of the Mach-O files, this will be handled automatically.

Comment 9

[Chris Andrichak]

Attachment: Patch that uses MOZ_APP_DISPLAYNAME for executable

Getting the executable name from the variable at mark's suggestion, the make file now swaps it into the plist file also.

There is currently duplication in the makefile (MOZ_APP_DISPLAYNAME - APP_NAME) I will file a follow-up bug to fix the debugging package name and that would be fixed there - one will take from the other.

Comment 10

[David :Bienvenu]

Comment on attachment 220339 [details] [diff] [review]
Patch that uses MOZ_APP_DISPLAYNAME for executable

you need to request reviews  of people - bugzilla should really complain about that!

Comment 11

[Chris Andrichak]

Sorry, I thought I was just carrying the names from the last patch.

Comment 12

[Chris Andrichak]

bug 336057 Filed to follow up on the debug issue

Comment 13

[Mark Mentovai]

Comment on attachment 220339 [details] [diff] [review]
Patch that uses MOZ_APP_DISPLAYNAME for executable

This comment isn't necessary:

+# Executable should match package filename - bug 273977

That's what cvs blame is for.  The new behavior is clear enough from the conditions in the Makefile, and this isn't some sort of weird unexpected change that warrants putting a bug ref directly in the comment.

I'm OK with trying this

Comment 14

[Chris Andrichak]

Attachment: Patch that uses MOZ_APP_DISPLAYNAME for executable- without makefile comment

Patch is the same as the previous except for the deletion of the comment line in the makefile (based on comment #13)

Comment 15

[Asaf Romano (gone)]

What's the parallel Fx bug#?

Comment 16

[Chris Andrichak]

(In reply to comment #15)
> What's the parallel Fx bug#?
> 

bug 275706 is the parallel for Firefox

Comment 17

[Chris Andrichak]

My external drive with all my build stuff on it died a little while ago so I have not been able to work on this (among other distractions). I was trying to build a release version for testing purposes but never got to it.

One thing I tried but did not work - taking an actual release download of Thunderbird 1.5 and just modifying the files inside the package in the same way that the build changes described here would (since they are very simple, modifying a line inside the plist file and renaming the actual binary). When I do this the Thunderbird application won't even launch. Any ideas?

Comment 18

[Mark Mentovai]

LaunchServices caches some things from the Info.plist file.  If you change the main executable name, you need to touch the app bundle's root directory (Thunderbird.app) to invalidate the cache.

Comment 19

[Chris Andrichak]

Thanks, that worked great.
Okay, that was my ultimate aim. I am now satisfied that this patch will work correctly in production, so if someone wants to check it in, please be my guest...

Comment 20

[Scott MacGregor]

fixed on the trunk. Thanks a lot for the patch Chris!

Comment 21

[Nick Thomas [:nthomas] (UTC+12)]

Could this bug have caused the bustage for hilo and boxset on the Thunderbird tinderbox ? The last line of the build log is:
  Error: binary not found: thunderbird-bin  

Does there need to be some tinderbox reconfiguration for new executable name ?

Comment 22

[Mark Mentovai]

Yes (see comment 8).

Comment 23

[Scott MacGregor]

bah, I'm being more dense than usual. I've backed out the patch until I have time to look into comment 8.

Comment 24

[Chris Andrichak]

Any chance at getting the tinderbox issues fixed relating to this patch? It would be nice to have this checked in for version 2.0.

Comment 25

[Chris Andrichak]

CHecking again to see if anyone can take a look at this on the tinderbox side.

I can deal with this on my local copy by changing the files, but then software update does not work correctly which is a minor bummer.

Comment 26

[Nick Thomas [:nthomas] (UTC+12)]

If I'm following this correctly, then BinaryName has to change in tinder-config.pl (eg [1]). That's much easier to do now all these configs are in public CVS.

But, in the tinderbox code there are a bunch of places that assume the application name is lower case [2] and that will change with the patches here. So a case insensitive regexp would be needed.

[1]
http://lxr.mozilla.org/mozilla/source/tools/tinderbox-configs/thunderbird/macosx/tinder-config.pl#175
http://lxr.mozilla.org/mozilla/source/tools/tinderbox-configs/firefox/macosx/tinder-config.pl#181
plus whatever branches attachment 220468 [details] [diff] [review] also lands on.

[2] http://mxr.mozilla.org/mozilla/search?string=BinaryName&find=%2Ftools%2Ftinderbox%2F&findi=&filter=&tree=mozilla

Comment 27

[Chris Andrichak]

Attachment: first attempt at a patch for the tinderbox perl scripts

Don't have any way to test this. Just a guess really.
- change the binaryname in the tinder-config.pl files
- make the regex matches for the binaryname case insensitive in the build-seamonkey-util.pl script

Comment 28

[Nick Thomas [:nthomas] (UTC+12)]

Chris, that looks like a good start to me, but the formatting of the diff needs to be improved. Please pull the files from CVS (if you haven't already) and modify them directly, then make a CVS diff using "cvs diff -u4". 

Once you attach that diff to the bug, ask for review by using the Details link in the attachments table, setting the review dropdown to ?, and the reviewer box to [e-mail]

Comment 29

[Chris Andrichak]

how do I pull the 'source' dir from CVS? is there a certain tag? it doesn't come with 'all' or in the source tarball.

Comment 30

[Chris Andrichak]

Attachment: tinderbox perl scripts v2, cvs diff version

similar to previous patch, but files pulled from CVS (that only took me a few hours to figure out for the tools...), so the version is upped a bit and the diffs are better

Comment 31

[Chris Andrichak]

Attachment: same as previous, minus the firefox tinder config

a bit overzealous on the previous patch, this bug doesn't pertain to changing the binaryname for firefox (although it would enable it to some degree). That is in bug 275706

Comment 32

[Robert Helmer [:rhelmer]]

Comment on attachment 255177 [details] [diff] [review]
same as previous, minus the firefox tinder config

I'm not really sure what the ramifications of changing this might be, maybe bsmedberg knows?

Comment 33

[Benjamin Smedberg]

I understand that this fixes things, but this really seems like something that iListen should be fixing, not us: the binary name can be anything (e.g. for all xulrunner-based apps it is "xulrunner"). Are they complaining that ProcessInfoRec.processName is returning "thunderbird-bin"? Or that ProcessInfoRec.processAppSpec is /path/to/Thunderbird.app/Content/MacOS/thunderbird-bin?

http://developer.apple.com/documentation/mac/Processes/Processes-24.html#MARKER-9-24

The tinderbox changes make me feel only a little queasy, which is about par for the course on tinderbox changes. But without more info, I'd argue this should be WONTFIX.

Comment 34

[Chris Andrichak]

I don't know the exact tech details, but I would say that their complaint is that the process name doesn't match the package name. (I don't work for them) iListen lists its special application command sets by the package name (If I create one for thunderbird, I pick it using a file picker, and it is called "Thunderbird"). This then doesn't match the process name which is thunderbird-bin.

Comment 35

[Benjamin Smedberg]

It may be unusual for them not to match, but it's supported: that's why Info.plist has an executable setting. I'm not excited about changing it in mozilla apps... this patch is insufficient because it will leave ugly files around during automatic update, and that is hard to fix given our use of multiple brandings and Debug options.

I would strongly encourage the iListen developers to do the right thing and look at the bundle name, not the executable name (if that's what they mean).

Comment 36

[Scott MacGregor]

I tend to agree with bsmedberg's comment 35

Comment 37

[Chris Andrichak]

I asked MacSpeech about this - 

----------------------------------
Chris:

All we can tell you is that iListen has absolutely no problem addressing thousands of other applications. It is unlikely our developers will risk breaking what works now for thousands of other applications to support two applications that do not conform to Apple's guidelines. Being "supported" and adhering to Apple's guidelines are two different things. And, from strictly an Applescript perspective, what they are doing is explicitly NOT supported. AppleScript deals with application ("executable")names, not the bundle name, and iListen conforms to AppleScript guidelines!!


Best Regards,


The MacSpeech Team
----------------------------------

Comment 38

[Chris Andrichak]

Additionally - I don't know what the technically correct answer is here, I'm just the messenger to  some degree, but I can say they are correct about one thing - in my experience also tbird and firefox are the only apps that have this problem with iListen. 

Comment 39

[Mark Mentovai]

I do think it's wrong that the present generation of Firefox and Thunderbird don't call their executables Firefox and Thunderbird, but it's totally bogus for anything to require that the executable name match the name of its app bundle on disk.  CFBundleExecutable exists specifically to support instances where the user renames the bundle.  For instance, I'm running both "Firefox 2.0.0.2.app/Contents/MacOS/firefox-bin" and "Camino 1.1b.app/Contents/MacOS/Camino" right now.

Comment 40

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Any update on this bug?

Comment 41

[Chris Andrichak]

Well, I'm not actively using iListen at the moment (fortunately I don't need it anymore), and I don't have the latest version anyway, so I couldn't say for sure if this is still a problem. My inclination is to mark this WONTFIX with the caveat that we can reopen later if somebody really needs it - obviously all the work is here...