91095 - Default plugin is bypassed when 'code' attribute missing in 'applet' tag

Status: VERIFIED FIXED

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

Description

[Tim Johnson]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2001062815

When I attempt to use the https://mil401k.metlife.com/IBM/ website, I get a pop
up message which says the "plugin downloader plugin" could not be found, and I
should go to www.netscape.com  to get it. I've been all over there, I've done
Google searches, I've done a Mozilla search, and I cannot find where I can get
this plugin.

I see this problem on the Mozilla .0.9.2 build.

Can you tell me where I can get this plugin downloader plugin and solve this
problem?

Thanks,

Tim


Reproducible: Always
Steps to Reproduce:
1.Go to the referenced URL
2.Dismiss the security warning pop-up if enabled.
3.The referenced plugin downloader plugin pop-up will appear.

Actual Results:  I can log in, but none of the rendering that's susposed to
appear is done, because I can't install the required plugin.

Expected Results:  Allowed me to install the required plugin(s)

I have the same problem with Netscape 6.1 PR. No word from them about where to
get this plugin downloader plugin either.

Comment 1

[Francisco León]

This is really weird.
Confirming on linux too, today's branch build
Marking NEW, moving to Plugins
Marking ALL/ALL

Comment 2

[Francisco León]

Reassigning bug to default owners

Comment 3

[av (gone)]

This is more likely a build problem. Somehow, the default plugin doesn't get 
into distribution. Cc'ing leaf.

Comment 4

[timeless]

bad... fwiw my beonex w32 installer builds (based on 092 branch) do install 
npnul32.dll

Ok, i'm using this mirror:
http://www.ibiblio.org:80/pub/packages/infosystems/WWW/clients/mozilla/mozilla
/releases/mozilla0.9.2/

zipinfo -1 mozilla-win32-0.9.2-talkback.zip | grep npnul
bin/plugins/npnul32.dll
zipinfo -1 mozilla-win32-0.9.2-MathML-SVG.zip | grep npnul
bin/plugins/npnul32.dll
gtar -tf mozilla-i386-pc-solaris2.8-0.9.2.tar | grep null
mozilla/plugins/libnullplugin.so
mozilla/libnullplugin.so
gtar -tf mozilla-sparc-sun-solaris2.6-7GTK-0.9.2.tar |grep null
mozilla/plugins/libnullplugin.so
mozilla/libnullplugin.so
gtar -tf mozilla-sparc-sun-solaris2.8-0.9.2.tar | grep null
mozilla/plugins/libnullplugin.so
mozilla/libnullplugin.so
^why the plugin appears twice is beyond the scope of this bug, but is probably 
a bug.

Ok, i've just picked what i would think are the most obvious (and know to be 
the easiest) builds (to test), all of them appear to have a null plugin.  Could 
you guys please indicate the exact archive (installer?) filenames (url) so i 
can inspect them?

Comment 5

[Francisco León]

I have build 2001071704, i have the nullplugin in my linux machine, and if i go
into a webpage that requests a plugin, i get the window "this page contains
information....click OK to download plugin" so a missing file is not an issue!
Somehow that webpage is confusing the plugin

Comment 6

[av (gone)]

OK, I see it now. It does behave as there is no default plugin installed, while 
there actually is. Investigating. Component back to plugins.

Comment 7

[av (gone)]

Attachment: Simplified to one line test case

Comment 8

[av (gone)]

It exhibits such a behaviour first time after you start Mozilla, to see it again 
you will need to restart.

Comment 9

[Francisco León]

I dont know much about the "downloader plugin", but i would think if a mime type
is not known to mozilla (like that ibm plugin), then it does not find a match
and the plugin becomes useless, as if it was not there. So mozilla complains
there isn't a plugin, while it should say that it does not know what to do with
that types of files

Comment 10

[av (gone)]

If we have a plugin for a specific mime type installed then Mozilla knows about 
this mime type. All installed plugins are scanned during a start up and Mozilla 
queries them about mime types they can handle and builds the internal list of 
mime types and corresponding plugins. The default plugin (aka plugin downloader 
plugin, aka null plugin) takes over when we hit a page which requires a plugin 
with unknown mime type. The job of the default plugin in such a case is to draw 
a puzzle piece and inform user about the situation and offer ways to resolve it, 
such as redirect to somewhere where he can get the required plugin. The default 
plugin is a part of normal installation (npnul32.dll). If for some reason it is 
missing and we experience the situation with unknown mime type then Mozilla pops 
up the dialog box that the default plugin is missing (calling it that terrible 
plugin downloader thing). And what we actually see in this bug. But the default 
plugin _is_ present so we should not see that message, we should rather see the 
default plugin in action. This is what this bug about to my understanding.

By the way, this particular page wants Java plugin installed. And see it with or 
without Java in my installation, which is even more strange.

Comment 11

[Francisco León]

Are you saying that url is wanting to open a .jar file?
Seems too weird?
->HelpWanted?

Comment 12

[av (gone)]

--> OJI, rephrasing summary, patch is coming.

Comment 13

[av (gone)]

Attachment: fix -- first try

Comment 14

[av (gone)]

Ed, I think you have much more knowledge in this realm than I do. Stepping 
through the debugger I found that for <applet> tag, if there is no 'code' 
attribute specified we don't set |fullURL| when we do InstantiatePlugin() in 
nsObjectFrame::Reflow(). Then (if we don't have Java plugin) we try to launch 
the default plugin but its instantiating code doesn't allow us to do that if the 
url is not set returning error which to outside code is a signal that we don't 
have the default plugin, in turn causing the message box saying just that. In 
the patch above I just set the |fullURL| to be |baseURL| in case it cannot be 
obtained otherwise. Not sure this is right way to go though. Please have a look.

Comment 15

[edburns]

Ok, I'll take a look.

Comment 16

[edburns]

After applying your patch, I see that the default plugin gets created, but I 
don't see it in the page.

Comment 17

[edburns]

The width and height of the applet are 0.  There is another bug that prevents 
the default plugin from displaying if the width and height are less than 
something like 60 by 60.  

In other news, This applet won't work with the HTML as written.

I may need to dummy something else up.

Pushing back to 0.9.5.

Comment 18

[shrirang khanzode]

SPAM: reassigning all OJI bugs to new OJI QA, pmac ( 227 bugs)

Comment 19

[edburns]

Ressign to Joe Chou, as I am no longer working officially on OJI.

Comment 20

[Tim Johnson]

I see this bug is continually pushed out. I seen several other have reported
this problem on the Netscape 6.1 news group, and I would think it's rather
common since I understand it occurs whenever a plugin is missing.

Is there a work-around for this until a real fix is made? It's stopping me from
using either Netscape 6.1 or Mozilla at my financial institution at the URL I
originally reported. Thanks, Tim.

Comment 21

[Peter Lubczynski]

Comment on attachment 42769 [details] [diff] [review]
fix -- first try

r=peterl

Comment 22

[Peter Lubczynski]

Andrei, doesn't your patch fix this?

Comment 23

[av (gone)]

It does. I just wanted a second opinion as I am not very comfortable with this 
code.

Comment 24

[Peter Lubczynski]

I applied your patch and it fixed the problem with the testcase.

Comment 25

[av (gone)]

I guess I am taking it...

Comment 26

[Marc Attinasi]

Comment on attachment 42769 [details] [diff] [review]
fix -- first try

sr=attinasi

Comment 27

[av (gone)]

Taking over.

Comment 28

[av (gone)]

Fix checked in.

Comment 29

[guivho]

I see this bug with build 2002020103 (and also saw it with milestone release
0.9.7) when surfing to e.g. http://webmail.telenet.be in a freshly started
browser. The password manager also does not fill in the remembered values when
this bug occurs. (A am using a Win2K box).

This url requires the plugin for type application/x-shockwave-flash which is
available and often Mozilla just detects it and mentions in the status line
'Starting Plugin for type application/x-shockwave-flash'.

The npnul32.dll is available in "c:\Program Files\mozilla.org\Mozilla\Plugins".

This bug does not happen consistently. I have the impression that it only
happens in a freshly loaded browser, but without any guarantees. Often the page
just gets loaded, the remembered password values get filled in, and I can
proceed without any problems.

This bug is also not limited to this one url, it also occurs sporadically with
other urls. If it helps, I'll mention them in additional comment entries when
the problem occurs.

Comment 30

[guivho]

Clicking the 'Join #mozillazine' button at http://www.mozillazine.org/chat/ pops
up a panel and the infamous 'No Plugin Downloader Plugin' dialog. Clocking OK
leaves me with a white panel without chat functionality.

Comment 31

[Peter Lubczynski]

WFM on my debug pull from a week ago

Comment 32

[shrirang khanzode]

v