Closed Bug 728672 Opened 13 years ago Closed 13 years ago

IBM/LOTUS Sametime meetingroom JAVA applet fails to start

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(firefox13+ fixed)

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox13 + fixed

People

(Reporter: wgianopoulos, Unassigned)

References

Details

(Keywords: regression)

Since landing of the code for bug 90268, I can not use Firefox to attend Sametime meetings at work. The Applet fails to properly load and start around 90% of the time. I did an HG bisect which identified that checkin as the culprit: The first bad revision is: changeset: 85844:15b00ab7f22d user: Josh Aas <joshmoz@gmail.com> date: Tue Jan 31 16:55:54 2012 -0500 summary: Bug 90268: Change plugin instance ownership from layout to content. r=roc r=bsmedberg
I found that changing dom.ipc.plugins.java.enabled to true in about:config avoids this issue. However, that preference was originally added to fix other issues. See bug 603417 for details.
I neglected to mention this is using Oracle JAVA SE 6 U31. Also, you can test this by visiting http://sametime.udayton.edu/stconf.nsf/WebTestMeeting?ReadForm and clicking the test my browser button. ( you need to allow popups from that site to do the test) You should enter the test meeting successfully every time. I tested to do the bisect by doing the test my browser then after successfully getting into the meeting, closing the pop-up and trying again. If it works 5 times in a row I called that good. A single success does NOT indicate you cannot duplicate the issue.
OH, this was with the normal 32-bit official nightly with 32-bit JAVA plug-in.
Sending over to Josh and tracking for FF13.
Assignee: nobody → joshmoz
tracking-firefox13: ? → +
The meeting seems to load just fine on Mac OS X. Bill - you're on Windows right? This bug may have the same root cause as bug 726734, even though they don't seem very similar. We should test with the patch over there.
It loads fine on windows if you have IPC enabled for Java. Since IPC is only disabled by default for JAVA on Windows, I would not expect this to be reproducible under Mac Os X.
That all said I guess I could try that patch to see if it fixes my issue.
I'm doing a try server run now, you/I can test with one of those builds.
Great. that will save me the trouble of doing my own build (which I can't start now because my normal nightly builds I provide are still in progress.
I'm having a tough time reproducing this with the current Nightly build on Windows 7 with the latest Java plugin from Oracle. I thought I saw the problem once, but I'm not sure. I've never seen anything fishy with my repro attempts with the patched build. Bill - let me know how your test goes.
OK. Like I said originally it was an intermittent issue. and required having dom.ipc.plugins.java.enabled st to true, which is the default. I hd decided trying to launch the meeting being successful 5 times in a row to indicate the issue did not exist.
It will really take me until tomorrow to give a definitive answer when I am back on the company network trying to attend sametime meetings on our corporate network.
I can't reproduce this, hopefully it is gone or fixed by bug 726734. Were you able to test today, Bill?
Assignee: joshmoz → nobody
I can no longer reproduce this using today's mozilla-central Nightly build.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Bill - would you mind verifying whether this is fixed on Aurora 13 as well? If not, this bug may require further investigation to identify the changeset that fixed it on nightlies.
OK. I can probably find time to do this on Friday.
(In reply to Alex Keybl [:akeybl] from comment #16) > Bill - would you mind verifying whether this is fixed on Aurora 13 as well? > If not, this bug may require further investigation to identify the changeset > that fixed it on nightlies. I just tested on the latest Aurora nightly and cannot reproduce the issue there either.
(In reply to Bill Gianopoulos [:WG9s] from comment #18) > (In reply to Alex Keybl [:akeybl] from comment #16) > > Bill - would you mind verifying whether this is fixed on Aurora 13 as well? > > If not, this bug may require further investigation to identify the changeset > > that fixed it on nightlies. > > I just tested on the latest Aurora nightly and cannot reproduce the issue > there either. Thanks! Marking as such.
status-firefox13: --- → fixed
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.