643327 - Quicktime plugin mp3 crash on new FF4, unique to FF, worked in FF4 Beta 11.

Status: RESOLVED DUPLICATE of bug 637006

(Core Graveyard :: Plug-ins, defect)

Description

[Jim Sontag]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

I have web pages with invisible HTML mp3 objects triggered by mouse events.  These pages have worked with FF since version 1.1.  I started to have trouble with FF 3.6.2. The play was not continuous on some soundtracks.  This problem continued to the current version of 3.6.xx

Last month I downloaded FF 4 Beta 11 and everything worked fine.

Today, FF 4 RC downloaded and it does not work at all!

On the sample page - clicking on any rectangle should play the mp3 file.

It appears FF 4 RC does not even recognize the type=audio/mpeg object anymore! It used to use the Quicktime plug-in.

All other browsers work fine - Safari, Chrome, Opera and IE (with MS media player)

Reproducible: Always

Steps to Reproduce:
1.go to sample web page
2.watch FF crash the quicktime plugin
3.
Actual Results:  
Error message

Expected Results:  
Soundbite should play when user clicks on rectangle

Worked fine with Firefox 4 Beta 11
Nada with FF 4 RC

Comment 1

[Jim Sontag]

Posted related bug on FF 3.6.2 - see 554577

Comment 2

[Matthias Versen [:Matti]]

Error: document.getElementById(g).Play is not a function
Source File: http://sontag.ca/soundboards/SoundBoard.js
Line: 14

Comment 3

[Boris Zbarsky [:bzbarsky]]

That looks like a plugin issue, not a DOM one, no?

That said, that linked-to site works for me in both RC1 and RC2 on Mac...

Comment 4

[Jim Sontag]

(In reply to comment #3)
> That looks like a plugin issue, not a DOM one, no?
> 
> That said, that linked-to site works for me in both RC1 and RC2 on Mac...

It may be only on Windows systems.  I have heard that it works on MAC.  FF 3.6.xx on MAC did not have this problem.  Vista did however.  Unknown if Windows 7 has this problem.

The Play() function should work BTW, if all objects have finished loading.

Comment 5

[Jim Sontag]

The sample page does work as expected with Safari, Chrome and Opera - and (as far as I know) they all make use of the same Quicktime plugin (7.6.9.0).  So I am arguing here that it is not a plugin issue.

Also I have the same problem with 3 different XP systems that I have. As mentioned, it worked fine with FF 4 Beta 11, but not with FF 4 RC 2. RC 2 reports an error that Quicktime has crashed.

Comment 6

[Boris Zbarsky [:bzbarsky]]

I didn't say it was an issue with the plugin.  But it's certainly not a DOM issue, since the DOM code here is the same on all platforms and works on Mac.  Chances are, it's an issue in the plugin code on our side of the NPAPI (or a bug in the Quicktime plugin itself that other browsers just don't tickle).

Quicktime crashing would certainly cause Play() to not work, yes.  ;)

Comment 7

[Jim Sontag]

Wow - I'm impressed with how rapid the response is. :-)

Re: bug in QT itself that other browsers don't tickle

I tested the page with Opera last night and a new message appeared indicating that the QT player was out of date.  

I checked the plugins and I had 2 Quicktime plugins active v 7.6.9.0 and 7.6.7.0(?).  The Opera browser actually blocked the the page load, with an option of proceeding once or updating QT. The page worked fine without an update.

I then selected QT update.  I already had QT 7.6.9.0 installed and it is the latest version BUT this time the QT installer only offered Repair or Uninstall. I selected Repair and the installer removed the QT 7.6.7.0(?) from my system.  The (?) above appears because I'm going from memory.

Boris - this was a long winded way of saying "I think you may be right". A QT bug that FF tickled.

Please - to all readers - I love FF. This issue is giving me heartburn :-(

Comment 8

[Alice0775 White]

If disabled ipc, I can play back "YoCutIt" at least, but I can not play back the other one.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110320 Firefox/4.0b13pre ID:20110320030417

It works on 
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.18pre) Gecko/20110304 Firefox/3.5.18pre ID:20110304030206

Comment 9

[Alice0775 White]

I think there are two problems.

1. If set width and height of object to not 0. Some plug-in is load properly.
    ( i.e. append object{min-width:1px;min-height:1px; } to userContent.css )

2.If disabled ipc, and set width and height of object to not 0,it works properly.

Comment 10

[Benjamin Smedberg]

There is a new NPAPI proposal implemented in Firefox: if a plugin is not visible (for any reason), we call NPP_SetWindow with coordinates 0,0,0,0 to inform the plugin that it does not need to do graphical work such as decoding videos. Firefox is the first browser to implement this new NPAPI proposal.

It is possible (likely, even!) that QuickTime is misinterpreting this call to NPP_SetWindow and refusing to set up its scripting environment, or something. I'll get an IPC log in a minute to see if there's anything obviously unusual. This is not something we are likely to fix at the present time, so I recommeng making the objects have a 1x1 size or something equivalent to work around the issue.

Comment 11

[Benjamin Smedberg]

I see quicktime crashing:

 	QuickTimeWebHelper.qtx!6863e5d9() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for QuickTimeWebHelper.qtx]	
 	QuickTimeWebHelper.qtx!6863eb65() 	
 	QuickTimeWebHelper.qtx!6863ed2f() 	
 	QuickTimeWebHelper.qtx!6863f01b() 	
 	QuickTime.qts!66f83161() 	
 	QuickTime.qts!66f2b6f1() 	
 	QuickTime.qts!6702bb80() 	
 	QuickTime.qts!66efaeb2() 	
 	QuickTime.qts!66f2b6f1() 	
>	xul.dll!mozilla::plugins::BrowserStreamChild::DeliverPendingData()  Line 287	C++
 	xul.dll!mozilla::plugins::BrowserStreamChild::Deliver()  Line 230	C++
 	xul.dll!DispatchToMethod<mozilla::plugins::BrowserStreamChild,void (__thiscall mozilla::plugins::BrowserStreamChild::*)(void)>(obj=0x006bdfb8, method=0x639ebfc0, arg={...})  Line 384	C++
 	xul.dll!ScopedRunnableMethodFactory<mozilla::plugins::BrowserStreamChild>::RunnableMethod<void (__thiscall mozilla::plugins::BrowserStreamChild::*)(void),Tuple0>::Run()  Line 197	C++
 	xul.dll!ScopedTaskFactory<ScopedRunnableMethodFactory<mozilla::plugins::BrowserStreamChild>::RunnableMethod<void (__thiscall mozilla::plugins::BrowserStreamChild::*)(void),Tuple0> >::TaskWrapper::Run()  Line 93	C++
 	xul.dll!MessageLoop::RunTask(task=0x006b0150)  Line 344	C++

Comment 12

[Jim Sontag]

(In reply to comment #9)
> I think there are two problems.
> 
> 1. If set width and height of object to not 0. Some plug-in is load properly.
>     ( i.e. append object{min-width:1px;min-height:1px; } to userContent.css )
> 
> 2.If disabled ipc, and set width and height of object to not 0,it works
> properly.

Hugs and Kisses Alice - your suggestion works! I'm not sure what IPC is or whether it is disabled or not, but a 1x1 object size works, although it does leave fly poop on the display ;-)

I have updated the sample pages so there are 3 page variations - 0x0, 1x1, and 200x16.  I also dressed up the HTML so it degrades properly if no plugin is found or it has been disabled.

The visible controls (Loser3.html) show that, with a 0x0 dimension, some sound objects load in FF, others do not.

Please note that the sound objects worked properly in FF 4 Beta 11, but not in FF RC.  And this has been a problem if FF 3.6.xx for over a year. And I believe this only applies to Windows systems.

Comment 13

[Jim Sontag]

Correction to above: The visible controls (Loser3.html) show that, with a 200x16 dimension, some sound objects load in FF 3.6.xx, others do not.

Comment 14

[Benjamin Smedberg]

Related to topcrash bug 637006, perhaps.

Comment 15

[Jim Sontag]

(In reply to comment #14)
> Related to topcrash bug 637006, perhaps.

Thank-you for that; I think you are right. It inspired me to do a search of my own. Here is the complete list:

bug 643327 - (this)
bug 637006 - Wind 7 topcrash (related)
bug 559564 - Wind XP FF 3.6
bug 570064 - Wind 7, Quicktime
bug 510125 - Wind Vista, mp3, 18 months old

I have a test case:

http://sontag.ca/soundboards/Losers2.html

that is perhaps the best demonstration of the problem because the sound controls are visible.  Load the page with FF 3.6.xx and watch what happens. Loading of the mp3 files are interrupted, but resume if the mouse-pointer flies over the right pixels on the control. This does not happen with other browsers.

Clicking on a rectangle should play the complete soundbite. In FF 3.6.x, quite often it does not. The same page works fine in Firefox 4.x because it is visible. The size of the control can be reduced to a 1x1 pixel and the still works - provided you don't mind a bit of fly-**** on your page.

http://sontag.ca/soundboards/Losers1.html

But if the size of the control is set to 0x0 pixels - Firefox 4 FAILS! This same page worked in FF 4 B11.

http://sontag.ca/soundboards/Losers.html

All of the above pages work in Chrome, Safari and Opera (on my Wind XP/updated, Quicktime/updated systems) which all use the same QT plugin (I believe).  They should also work with IE (I digress, that's not important).

So I have this theory that is a Firefox problem and that the answer is soooo close that a solution is at hand.

Please fix this! I, for one, am desperate for a solution. I love Firefox; really do; do all my development with it; always have.

But now I have a message on my personal website that suggests to viewers that Firefox will not work, and they use another browser (any other browser) instead.  This is deeply embarrassing and painful for me.

I'll create a new page (which may be ready by the time you read this) that has no IE cruft in it.

http://sontag.ca/soundboards/Losers3.html

Cheers
Jim

Comment 16

[:Felipe Gomes (needinfo for replies!)]

Hi Jim, thanks for the investigative work. It seems that there are two different problems found:

- playback of mp3 files in FF 3.6 is unreliable. It appears that this problem is gone and doesn't happen in FF4. Is that correct? (ignore the case with 0x0 dimensions). If yes then this part is a non-issue and we can mark those bugs as resolved.

- when controls are set to 0x0 they don't work in FF4. Do you see the "plugin crashed" yellow banner every time that this happens? If yes then this is simply a dup of bug 637006.


There's a simple solution for you to use in your site while this bug is not fixed. Instead of setting the dimensions to 0x0, just use CSS to hide the controls with the visibility property, e.g.:

<object type="audio/mpeg" data="BringItOnDown.mp3" style="visibility: hidden">

(or some variation of it)

Comment 17

[Jim Sontag]

Thanks Felipe - I plan to change the model for those silly soundboards but in the meantime I have all these existing pages that use a 0x0 setting. Sigh - cut and paste HTML. If I wasn't a windows user, I could just use just grep.  Even then I could still use cygwin/grep but I recently moved everything over to a CMS, so it gets more complicated.

Others are in the same boat as me.  I have managed to get the existing pages working in every other browser of significance except Firefox - and even then, the most current release candidate of Firefox.

I'm just asking what made QT crash in FF 4RC and not in FF B11? If this was determined, then a solution might be at hand to the 3.6.xx problem too. It's so close.

Comment 18

[Jim Sontag]

Attachment: FF4 RC Quicktime crash - 14 embedded 0x0 mp3 objects

Screen shot of FF4 RC / Quicktime crash from
http://sontag.ca/soundboard/Losers3.html

Comment 19

[Jim Sontag]

(In reply to comment #18)
> Created attachment 521137 [details]
> FF4 RC Quicktime crash - 14 embedded 0x0 mp3 objects
> 
> Screen shot of FF4 RC / Quicktime crash from
> http://sontag.ca/soundboard/Losers3.html

Sorry, the link should be:

http://sontag.ca/soundboards/Losers.html

Comment 20

[Boris Zbarsky [:bzbarsky]]

Jim, comment 10 explains exactly why you only see the problem in Firefox.  The problem is, nevertheless, due to a bug in Quicktime, and will start happening with all the other browsers once they catch up with the new NPAPI functionality.

Comment 21

[Benjamin Smedberg]

http://hg.mozilla.org/mozilla-central/annotate/8618a149ea2e/dom/plugins/PluginInstanceChild.cpp#l940 added a quirk for quicktime so that we do not send it the 0,0,0,0 setwindow call. This was added in bug 626016 to fix a problem with quicktime not working at all if it was invisible.

Comment 22

[Jim Sontag]

@Benjamin - reply to https://bugzilla.mozilla.org/show_bug.cgi?id=575064#c16  
@Boris

The problem first appeared to me at or around Firefox 3.6.2 - forgive the lawyer speak, but I am going from memory.

IIRC, about the same time, the *plugin-container* appeared. I think this is the IPC Alice referred to. I disabled that a long time ago for 2 reasons...

1) it was an occasional resource hog (50% - WTF?)
2) I could not figure out what it might be useful for

The above problem persisted for me in the current version of FF until FF 4 Beta 11. Then everything worked! 

Then, with the OFFICIAL release of Firefox 4 (today), everything stopped working (sorry to exaggerate here, but I'm currently **** off).

I'm no expert here, and with all due respect, because you know more about this than I do, but isn't *the job of a browser is to render the HTML as served*?

Quicktime works with every browser (except IE, but there is a workaround) but the latest version of Firefox does not!  Alice (thank-you once again) identified exactly which build of FF broke it (again) for me.

https://bugzilla.mozilla.org/show_bug.cgi?id=637006#c5

Have we seriously looked at IPC? Is this causing the problem? I cannot accept for an answer that *Firefox is leading the pack here*, and once every other browser catches up, it will be revealed that QT is the one at fault.

Regards
Diogenes, cynic by default

Comment 24

[Jim Sontag]

My apologies for the last comment.  Reading it now, I'm a little embarrassed - it was over the top. I really, really appreciate everybody's effort here. I promise not to throw any more hissy fits. <:}