Closed Bug 310515 Opened 19 years ago Closed 19 years ago

Flash content doesn't load/display if npmozax.dll is present in the plugins folder.

Categories

(Core Graveyard :: Plug-ins, defect, P2)

x86
Windows XP
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.9alpha1

People

(Reporter: stephend, Assigned: Biesinger)

References

Details

(Keywords: regression)

Attachments

(1 file)

Summary: Flash content doesn't load or display.

This regressed between 2005-09-21 and 2005-09-22.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-09-21&maxdate=2005-09-22&cvsroot=%2Fcvsroot

Is this fallout from bug 1156?  Or just a coincidence and caused by something else?

Build ID: 2005-09-21 Firefox trunk (installer) on Windows XP with:
Plugin: Shockwave Flash 8.0 r22

Steps to Reproduce:

1. Download/install any build past 9-22-2005.
2. Download/install Shockwave Flash 8.0 r22.
3. Load http://www.fox.com.

Expected Results:

Almost a full page of Flash content loads.

Actual Results:

Only HTML loads.
Fun times.  They send it all as application/octet-stream instead of the flash
MIME type, and I bet that makes us unhappy.  Sounds like we need to fix bug
309523 somehow... or something.
Blocks: 1156
Depends on: 309523
BTW, meant to mention that this is fine on SeaMonkey, FWIW.
Er...  The behavior shouldn't be different between Firefox and Seamonkey here.
Per HTTP, the Content-Type sent by the server takes precedence. That's what bug
95549 was about. There was talk in that bug of doing something different for
quirks mode--which presumably meant applying some heuristic to divine what
plug-in should be loaded if application/octet-stream is received.
The new flashplayer does not work in Seamonkey 2005092305
oops.. it DOES work, also at the FOX site. For some reason this version tickled
adblock and no flash displayed anywhere.
RE: comment 5 and comment 6: This is probably bug 309044 (Flashplayer 8 "Bad
NPObject as private data!")
Bug 95549 was about <object> while this site uses <embed>.  For <embed> there is
no spec saying how it should behave.
(In reply to comment #4)
> Per HTTP, the Content-Type sent by the server takes precedence. 

But only for <object>, not for <embed>; I did it that way to specifically avoid
problems like this.

Does this site use <object> w/o classid? (And why should this differ between
mozilla and ff??)
The difference for ff might be that we don't try to instantiate the nullplugin
there.

The other possible difference, of course, is that someone has extensions (eg
adblock) installed.  Some versions of adblock are known to be buggy and could
cause issues like this, so if you're using adblock please disable it and retest.
but the nullplugin shouldn't matter here, because we know we support flash. right?
hrm, also, that page works for me in a ffox (debug) build made shortly after the
bug 1156 checkin.
Biesi: can you grab a Firefox stub installer build?  That's the only place I've
found where this fails, for some reason.  The ZIP builds, with plugins copied
from the stub build's folder, work fine.

Also, not all Flash content breaks.  ABC.com and ABCNews.com both have Flash
content that works just fine, even in my stub installer build where FOX.com
breaks.  Very odd.
Attached patch possible patchSplinter Review
ok, notes:
- this bug requires having npmozax.dll present in the plugins folder (the
activex plugin)
- I believe that it doesn't want to handle flash content and therefore fails
Instantiate

However, even if the analysis above is incorrect, this patch is a good thing to
have.
Assignee: nobody → cbiesinger
Status: NEW → ASSIGNED
Attachment #198053 - Flags: superreview?(bzbarsky)
Attachment #198053 - Flags: review?(bzbarsky)
Priority: -- → P2
Target Milestone: --- → mozilla1.9alpha
Attachment #198053 - Flags: superreview?(bzbarsky)
Attachment #198053 - Flags: superreview+
Attachment #198053 - Flags: review?(bzbarsky)
Attachment #198053 - Flags: review+
Summary: Flash content doesn't load or display. → Flash content doesn't load/display if npmozax.dll is present in the plugins folder.
checked in to trunk. not marking fixed yet; stephend, could you retest in
tomorrow's builds?

Checking in content/base/src/nsObjectLoadingContent.cpp;
/cvsroot/mozilla/content/base/src/nsObjectLoadingContent.cpp,v  <-- 
nsObjectLoadingContent.cpp
new revision: 1.2; previous revision: 1.1
done
(In reply to comment #15)
> checked in to trunk. not marking fixed yet; stephend, could you retest in
> tomorrow's builds?
> 
> Checking in content/base/src/nsObjectLoadingContent.cpp;
> /cvsroot/mozilla/content/base/src/nsObjectLoadingContent.cpp,v  <-- 
> nsObjectLoadingContent.cpp
> new revision: 1.2; previous revision: 1.1
> done

I upgraded to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20051004 Firefox/1.6a1, and left npmozax.dll in C:\Program Files\Deer Park
Alpha 2\Plugins, and this still fails.

As soon as I rename npmozax.dll to something else, like say blah-npmozax.dll,
and restart Firefox, the Flash content is rendered again.

The npmozax.dll version is 1.0.0.4, if that matters (doubtful).
> blah-npmozax.dll

wow, seriously? that's really strange...
Depends on: 311674
Should be fixed by the checkin for bug 311674 (when combined with the patch in
this bug).  Please retest in today's builds?
Though today's may not pick up that fix.. should also check tomorrow's if it
doesn't work.
(In reply to comment #19)
> Though today's may not pick up that fix.. should also check tomorrow's if it
> doesn't work.

Yup, this is working just fine now with npmozax.dll in my /plugins folder of
Firefox and SeaMonkey.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051014
Firefox/1.6a1
--and--
SeaMonkey 1.1a;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20051013 Mozilla/1.0

Boris, can you mark this FIXED so I can then mark it VERIFIED?  Thanks...
Fixed (by the earlier patch in this bug, plus patch in bug 311674).
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Verified per comment 20.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: