17551 - [FEATURE] need default plug-in handler: When mozilla doesn't find a plugin, instead of informing the user, it goes on to display the rest of the page.

Status: VERIFIED FIXED

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

Description

[Jayashri Visvanathan]

The above URL contains information that needs a quicktime plugin to view.
Netscape 4.x pops up a dialog which takes me to a page from where I can download
the plugin while mozilla doesn't do that. It silently goes on to display the
rest of the page and the user has no idea that he is missing something in the
page as there is not a even a blank or a place holder frame for the content that
is not being displayed.

Comment 1

[Jayashri Visvanathan]

Some additional info about this bug

  1. Occurs on bioth windows and solaris
  2. It is a [4.xP] bug. It doesn't occur in  Netscape 4.x but occurs in
Mozilla.
  3. Using M-10 (Oct 11 th or sometime ) version of Sea Monkey


  By the way, going to the URL that I metioned you might experience a crash.
That's because of a  print statement. Not sure if its fixed now or not.  In
nsPluginHostImpl.cpp, in the method
InstantiateEmbededPlugin in case the debug if statement, you can see its
printing the mimeType without checking for nil. In the URL that I metioned it is
nil. So it crashes. So if you just change it so that it prints
mimeType only it is not nil, then you should be able to reproduce my bug.

Comment 2

[Eli Goldberg]

Confirmed also present on Mac OS; changed Platform/OS to All.

Comment 3

[Eli Goldberg]

Shrirang is now QA owner for Plug-ins; QA assigning all of my Plug-ins bugs over
to him.

Comment 4

[av (gone)]

This is a matter of implementing a default plugin what we called it in 4.x. 
Eric, what would be marketing view on this?

Comment 5

[ekrock's old account (dead)]

We should do the same thing Navigator 4 did. Marking [FEATURE] in summary and 
with 4xp and beta2 keywords. Andrei--since beta2 is supposed to be feature 
complete, would it be possible to move this to the M16 or M17 milestones? 
Leaving M18 for now.

Comment 6

[ekrock's old account (dead)]

Note that the default plug-in page feature generates page views on the plug-in 
finder at Netcenter which are an important source of Netcenter revenue. We need 
to try to get this feature in by 5/16; if we don't, there will be strong 
economic reasons for an exception on this.

Comment 7

[av (gone)]

Eric, I have a fix for this one. The idea is to use the old default plugin which 
gets invoked when unknown mime type is encountered. That's the fastest way to do 
that. The default plugin will take care of it exactly the same way as in 4.x 
since it is the same plugin. There is a couple of things though. Please correct 
me if I am wrong. I think we should launch the default plugin on <embed> tag 
only, leaving the <object> tag playing with alt content. As it goes in the 
standard. There still will be the way for content writers to launch the default 
plugin even with the original <object> tag if they put an <embed> as an 
alternative content.

Another thing, the big one. The default plugin relies heavily on asking the 
browser for URLs like this: javascript:window.open("URL";) That's how it gets to 
the Netscape Plugin Finder page. Looks like this sort of URLs is not working. Is 
this supposed to work or I am just doing anything wrong? If this is a known bug 
it should be fixed in sync, otherwise my fix will be of no use in many cases, 
not always though.

Comment 8

[shrirang khanzode]

Andrei, bug 38537 and bug 34667 mention the javascript url's problem.

Comment 9

[av (gone)]

Thanks, Shrirang. And they marked nsbeta2, so looks like everything is fine. I 
am putting dependency on those two.

Comment 10

[ekrock's old account (dead)]

*** Bug 37558 has been marked as a duplicate of this bug. ***

Comment 11

[ekrock's old account (dead)]

Setting to [nsbeta2+][6/15]. PDT team has approved this checkin.

Comment 12

[av (gone)]

Checked in. While waiting for JavaScript type URLs we can still see it working, 
just disable JavaScript in prefs.js

Comment 13

[edburns]

av, I tried visiting a page that requires the quicktime plugin, 

http://www.apple.com/quicktime/qtv/britney/

And found that the same behavior that Jayashri reported is still present.  

Visiting this in IE5 draws draws a little box.

Comment 14

[edburns]

Old URL was stale.  Britney is FRESH!

Comment 15

[edburns]

The behavior av describes requires you have the plugin npnul32.dll in your 
mozilla plugins directory, or netscape 4.x plugins directory.

Also, you must disable javascript to see this bug fixed.  Do this by adding 

user_pref("javascript.enabled", false);

to prefs.js

I'm attaching npnul32.dll presently.

Comment 16

[edburns]

Attachment: The Default Plugin.

Comment 17

[av (gone)]

Can we reclose it?

Comment 18

[edburns]

I still think the fact that the EMBED tag that references the plugin must have 
a height > 60 in order for this to work is a problem.

This solution should work for all plugins, regardless of their height, width, 
etc.

Also, after building the default plugin provided by Eric, I have found that 
plugins that do not specify a mime type in their EMBED tag will cause the 
default plugin to throw an assertion. 

Look at npnul\Plugin.cpp::showGetPluginDialog().

Should this be a separate bug?

Comment 19

[edburns]

If the EMBED tag doesn't specify a PLUGINSPAGE, an assertion is thrown.

If the EMBED tag specifies a pluginspage that is a relative URL, no URL 
resolution is performed, and the page doesn't load correctly.

I thought the idea was for the default plugin to take you to the Netscape 
Plugin page if it couldn't figure out how to go to a successful page based on 
the markup.

Is it your understanding that the default plugin currently works does this?  If 
so, what am I doing wrong, since I'm not observing this behavior.

I'm attaching my testcase html page.

Comment 20

[edburns]

Attachment: testcase

Comment 21

[av (gone)]

This relative URL thing should probably be a separate bug. If you remove 
PLUGINSPAGE attribute, it works as expected. And I don't see the assertion.

Comment 22

[ekrock's old account (dead)]

Right. Golden rule is "one bug report, one issue." This bug report is to track 
the complete absence of a default plug-in handler. If you feel there are bugs 
with the plug-in handler's behavior once checked in, please open a separate 
report for each issue. Thanks for all your hard work on this!

Comment 23

[shrirang khanzode]

Bug 42694 has been seperately logged for the 'PLUGINSPAGE relative url problem'. 
Bug 42696 has been logged for the 'assertion caused due to no mime 
type' problem. Pls use those bugs for further discussions on these problems. 
Thnx.

I will be verifying this original bug soon (availability of default plugin 
handler).

Comment 24

[av (gone)]

Marking fixed as the remaining issues are filed as separate bugs.

Comment 25

[shrirang khanzode]

Verified with build 2000061908.