622830 - Cisco WebEx plugin uses Carbon event model and is therefore incompatible with 64-bit Firefox

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[keith]

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8) Gecko/20100101 Firefox/4.0b8

The Webex Java Client does not load when running FF4b8 in 64 bit mode on OS X 10.6.5.  To recreate join a test meeting at the URL above.  (You don't have to put in a valid email) 

If FF4b8 is forced to start in 32 bit mode then everything works fine.   Same URL works fine in Safari.



Reproducible: Always

Steps to Reproduce:
1.  Start FF4B8 in 64bit mode (default)
2.  Try to join a Webex meeting (http://www.webex.com/lp/jointest/)
3.  Fails
4.  Start FF4b8 in 32 bit mode.
5. Try and join Webex and it works fine.

Comment 1

[Matthias Versen [:Matti]]

The problem could be that you don't have a 64bit java installed and we don't do OOPP java that would allow 32/64 ,mixed operation

Comment 2

[keith]

Attachment: Jav 64bit and 32 bit are enabled

Java 64bit and 32 bit are indeed installed.

Comment 3

[keith]

Also, this just isn't just happening with by system.   In joining Webex conferences over the past few days others have been complaining about the same.  Common denominator is FF4b8.

Now that FF4 is installed natively as a 64 bit app won't it be a problem when it goes general deployment and Java apps break in the browser?

Also, I am running the default Java updates from Apple.  Nothing really special in my setup.

Comment 4

[keith]

Also, this could extend beyond Webex.  Not sure as that was the only embedded Java app I have tried.

Comment 5

[Benjamin Smedberg]

Blocking for investigation, although I'm pretty sure we know Java works *some* of the time ;-)

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I haven't yet confirmed this.  But in my tests on OS X 10.5.8 (32-bit only) I've discovered the Java applet only runs if WebEx hasn't already been installed.  To fully remove WebEx (and re-run the test) you need to delete the following:

~/Documents/WebEx/
~/Library/Application Support/WebEx Folder/
~/Library/Internet Plug-Ins/WebEx.plugin/
~/Library/Preferences/Webex Browser Preferences

Comment 7

[Steven Michaud [:smichaud] (Retired)]

And note that WebEx does *not* use Java (and is not a Java app or applet).  The Java applet (a signed applet) is what installs it.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

I've confirmed this report (testing on OS X 10.6.5).

In 64-bit mode (the default), the signed Java applet that installs
WebEx downloads and runs, but for some reason fails to install WebEx.
In 32-bit mode it works just fine.

This bug may be related to bug 563891 and bug 573180.  See bug 620773
comment #5.

Comment 9

[Benjamin Smedberg]

Hrm, I wouldn't expect that to be related. Why do you think so?

Comment 10

[Steven Michaud [:smichaud] (Retired)]

At the moment I'm just following 620773 comment #5, which claims both
bugs only happen in 64-bit mode.

Comment 11

[Simon Kornblith]

I certainly didn't mean to imply that bug 563891 and bug 573180 occur only in 64-bit mode in my comment on bug 620773; I can reproduce them in 32-bit mode as well.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

This bug has nothing to do with Java:  The only Java code here is the
installer (a signed Java applet), which works just fine.

In fact it's caused by a bad interaction between 64-bit Firefox and
the WebEx plugin that gets installed (by the signed applet installer)
to ~/Library/Internet Plug-Ins/:  The WebEx plugin uses the Carbon
event model (and is compiled 32-bit).  But Firefox is unable to run
Carbon-event-model plugins out-of-process.  And in order for 64-bit
Firefox to be able to load 32-bit plugins, it must run them
out-of-process.  Catch 22.

As best I can tell, there's nothing we can do about this.  So we'll
need to add a relnote telling Cisco WebEx users to install and use
this program in 32-bit mode.

We should also contact Cisco and try to persuade them to make their
WebEx plugin support the Cocoa event model on OS X.  But we can't
expect them to be able to accomplish this overnight.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

> This bug may be related to bug 563891 and bug 573180.  See bug 620773
> comment #5.

This bug, which has nothing to do with Java, is completely unrelated to bug 563891 or bug 573180.

Comment 14

[Josh Aas]

Ugh. Blocking2.0-, I will find a way to get in touch with Cisco about this.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

Attachment: Debugging patch (*not* a fix)

It's actually quite difficult to see what causes this bug, even using
my debug build.

If you test only in 64-bit mode, every time you run the test you see
the signed Java applet installer run and install the WebEx plugin to
~/Library/Internet Plug-Ins/.  Then the installation (mysteriously)
fails just after that point.

If you run in 32-bit mode with the default settings, everything works
fine.

But you do see the problem if you run in 32-bit mode and add the
following boolean setting in about:config (set it to "true").  This
causes the WebEx plugin to run out-of-process even in 32-bit mode.

dom.ipc.plugins.enabled.i386.webex.plugin

Now the signed Java applet installer only runs the first time you run
the test.  And every time you run the test (including the first time)
you see the WebEx plugin fail to load because it only supports the
Carbon event model.

A tryserver build made with this debugging patch will follow in
several hours.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

> If you test only in 64-bit mode, every time you run the test you see
> the signed Java applet installer run and install the WebEx plugin to
> ~/Library/Internet Plug-Ins/.  Then the installation (mysteriously)
> fails just after that point.

I've figured out what's going on here, and why it doesn't happen in
32-bit mode:

The WebEx plugin's mimetype info is only available in an old-fashioned
resource (Content/Resources/WebEx.rsrc), and not in the plugin's
Content/Info.plist file.  Which means that
nsPluginFile::GetPluginInfo() in nsPluginsDirDarwin.cpp can only read
this information when the parent process is running in 32-bit mode.
Which in turn means that the WebEx plugin gets added to the list of
invalid plugins (in nsPluginHost::ScanPluginsDirectory()) in 64-bit
mode (though not in 32-bit mode).

Another thing to bring up with Cisco when you talk with them, Josh.

(Even after the WebEx plugin is installed to ~/Library/Internet
Plug-Ins/, it doesn't show up in about:plugins in 64-bit mode.  It
does show up in 32-bit mode, though.)

Comment 17

[Steven Michaud [:smichaud] (Retired)]

Attachment: Better debuging patch (still *not* a fix)

Tryserver build made with this patch:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-409ab3c96c04/try-osx64/firefox-4.0b10pre.en-US.mac64.dmg

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Note that presently when I try to join WebEx conferences running 64-bit Firefox on OSX I:

 - do not see anything asking me to restart in 32-bit mode
 - end up crashing (see bug 633452 comment 1)

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Josh tells me that there are two issues here:

1. The Cisco WebEx plugin uses an old format (OSX Resource File) to communicate MIME types; Firefox requires a plist, which is why we don't show the "restart in 32 bit mode" infobar.

2. They're using the carbon NPAPI event model, which is why it doesn't work in 64-bit mode.

Hopefully we can get the Cisco guys to change to using a plist, at least, for the short term.

Comment 20

[Steven Michaud [:smichaud] (Retired)]

Another thing to check:

Apple just released new Java updates for OS X 10.5 and 10.6.  Install the appropriate one and test again, to see if this makes any difference.

All of my tests today have been with Java for Mac OS X 10.6 Update 4 (the latest update for 10.6).

Comment 21

[Steven Michaud [:smichaud] (Retired)]

Ignore comment #20 -- wrong bug :-(

Comment 22

[Daniel Holbert [:dholbert]]

This may have become WORKSFORME at some point during the past 6 years, but now, I believe the CiscoWebEx plugin is no longer supported, per bug 1091835 comment 1.  So I think this is probably WONTFIX.

Comment 23

[Daniel Holbert [:dholbert]]

(Please correct me if I'm misunderstanding / if this is still usefully tracking an open issue that progress can be made on.)