493375 - plugins won't load [@ nsPluginFile::LoadPlugin]

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090516 Minefield/3.6a1pre ID:20090516041819

regressed with todays nightly

the plugin is there , but no flash is displayed.

Comment 1

[Peter van der Woude [:Peter6]]

no plugin content is displayed at all

Comment 2

[Emanuel Hoogeveen [:ehoogeveen]]

Confirmed also in Vista x64 with SP1, tested with Flash and the windows media player 11 plugin.

Comment 3

[Peter van der Woude [:Peter6]]

probably caused by bug 488181

Comment 4

[Isaac702]

Well it appears that this doesn't only affect Windows platforms.
Confirmed on Linux x86_64.

Comment 5

[pal-moz]

(In reply to comment #3)
> probably caused by bug 488181

regress after Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090515 Minefield/3.6a1pre ID:20090515165914
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/ : (Last modified) 15-May-2009 18:35 	 

http://hg.mozilla.org/mozilla-central/rev/7cd22106e8d9

Comment 6

[Josh Aas]

Plugins load just fine for me on x86_64 Linux and Mac OS X with builds that I made from current code containing my patch from bug 488181. Plugins load just fine for me with the latest nightly on x86_64 Windows Vista too.

Comment 7

[Josh Aas]

Do plugins load with a fresh profile?

Comment 8

[(not currently active) Ted Mielczarek]

I can reproduce this on my normal profile, but if I create a new profile plugins work fine. I thought maybe it had to do with using an older build first, so I created a profile with FF3 and then used it with trunk, but it still worked. I also have Flashblock installed, so I tried installing that in the new profile, but plugins still worked. I have a few other addons installed, so it's possible it's something else.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090516 Minefield/3.6a1pre

Comment 9

[(not currently active) Ted Mielczarek]

I tried in safe mode on my usual profile and it's still broken, so it's at least not an enabled extension breaking anything.

Comment 10

[IU]

SIMPLER SOLUTION: Delete pluginreg.dat from your profile folder and restart Minefield.

Comment 11

[Bill Gianopoulos [:WG9s]]

the issue seems to be some kind of timing/race condition in the plug-in load.
I actually get 3 separate conditions.

1.  the plug-in loads and works correctly.
2.  The plug-in fails to load.
3.  Firefox crashes.

All with the same build and the same profile.

The crash seems to be easiest to reproduce when the computer is busy doing something else (like doing a Firefox build)

Crash reports are here:

bp-6b86926f-064f-4924-8e2b-db6262090516
bp-9b1eb806-c2cf-452c-9f14-afc6a2090516

Comment 12

[Bill Gianopoulos [:WG9s]]

(In reply to comment #11)
> the issue seems to be some kind of timing/race condition in the plug-in load.
> I actually get 3 separate conditions.
> 
> 1.  the plug-in loads and works correctly.
> 2.  The plug-in fails to load.
> 3.  Firefox crashes.
> 
> All with the same build and the same profile.
> 
> The crash seems to be easiest to reproduce when the computer is busy doing
> something else (like doing a Firefox build)
> 
> Crash reports are here:
> 
> bp-6b86926f-064f-4924-8e2b-db6262090516
> bp-9b1eb806-c2cf-452c-9f14-afc6a2090516

I neglected to mention this is all with the same plug-in on the same webpage.  The plugin which I see this with is the Move Streaming Media Player.

Comment 13

[Josh Aas]

Attachment: fix v1.0

The problem is that on Windows and Linux the file name and full path fields in pluginreg.dat now store what you'd expect because of my patch in bug 488181. pluginreg.dat files written out prior to my patch store the full path in the file name field and nothing in the full path field. The solution is to bump the current and minimum versions for pluginreg.dat to reflect the new contents of the fields.

Comment 14

[Bill Gianopoulos [:WG9s]]

(In reply to comment #10)
> SIMPLER SOLUTION: Delete pluginreg.dat from your profile folder and restart
> Minefield.

If the format of the pluginreg.dat file changed, then the version should have
been bumped to prevent this issue.

If the format did not change, then there is something else going on here.

That said, I have NOT been able to reproduce any issues including the crashes since removing my pluginreg.dat file.

Comment 15

[(not currently active) Ted Mielczarek]

Comment on attachment 377864 [details] [diff] [review]
fix v1.0

Sounds reasonable.

Comment 16

[Josh Aas]

Attachment: fix v1.1

This should work better, can read back to pluginreg.dat v0.9.

Comment 17

[Josh Aas]

I backed out bug 488181. Fix here isn't good enough.

Comment 19

[WildcatRay]

(In reply to comment #17)
> I backed out bug 488181. Fix here isn't good enough.

What does this mean for those of us who deleted the pluginreg.dat files in our profiles. Should we delete it, again, before applying today's nightly update? Thanks.

Comment 20

[Josh Aas]

(In reply to comment #19)
> What does this mean for those of us who deleted the pluginreg.dat files in our
> profiles. Should we delete it, again, before applying today's nightly update?

I'd delete it again to be safe.

Comment 21

[WildcatRay]

(In reply to comment #20)
> (In reply to comment #19)
> > What does this mean for those of us who deleted the pluginreg.dat files in our
> > profiles. Should we delete it, again, before applying today's nightly update?
> 
> I'd delete it again to be safe.

Others have already beaten us to it. In fact, someone tried and had the browser crash on them. After deleting the "updated" pluginreg.dat file, everything returned to normal. Also, others restored their older copy.

Thanks, again, Josh.

Comment 22

[Morton A. Goldberg, DVM]

Crash confirmed.

Tried to play a YouTube video <http://www.youtube.com/watch?v=wsMCwhJJfqo> with today's nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090517 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090517043923) and it crashed instantly. Restarted and tried again with same result. Quit, deleted pluginreg.dat, and restarted. Tried the same YouTube video again. It played normally.

Comment 23

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

Carrying over blocker nomination from dupe; I think it probably would block, so setting to + (though this is fixed, so yay!) But the fix hasn't been checked in (there's no m-c checkin comment), so boo?

If the fix was checked in, and done before August 13th (when we branched), could someone set the status-1.9.2 to beta1fixed?

Comment 24

[Benjamin Smedberg]

http://hg.mozilla.org/mozilla-central/rev/8fce20dd0cbe was the re-landing of bug 488181 with this fix included

Comment 25

[Marcia Knous [:marcia]]

Verified fixed on the trunk using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20090914 Minefield/3.7a1pre as well as the latest Win XP nightly. Also verified with Namoroka nightlies. Adding keyword.