44692 - Default plugin doesn't do anything if no mimetype specified in EMBED tag

Status: VERIFIED FIXED

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

Description

[shrirang khanzode]

Build:2000070608

I see this problem on windows build. Right now bug 43500 is not fixed (default 
plugin is not added to plugins folder automatically). So you will have to wither 
use the mozilla build or manually put the npnul32.dll file in the plugins 
folder to recreate this problem.

Steps:

1. Go to the above mentioned url.
2. You should see a square box on the right side with a puzzle symbol and text 
   saying 'Click here to get the plugin'.
3. Clicking with the mouse on the icon does not do anything.

Expected: Idwally, I should be sent to the Netscape plugin download page like in 
4.x browser.

Comment 1

[shrirang khanzode]

Nominating this for nsbeta2 since this is major and is required to be working 
for beta2.

Comment 2

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 3

[av (gone)]

The mime type is not specified in the source of the embed tag. That's why the 
default plugin is doing nothing. The mechanism for retrieving the mime type by 
extension is still to be implemented (43556). Adding dependency.

Comment 4

[av (gone)]

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

Comment 5

[av (gone)]

Changing summary.

Comment 6

[ekrock's old account (dead)]

So for content providers, the workaround for this bug is to explicitly specify 
the MIME type in the EMBED tag. We want to be backwardly compatible with Nav4 
behavior on content, so we would still like to fix this bug, but the fact that a 
workaround exists lowers the priority on this bug if we run out of time.

Comment 7

[shrirang khanzode]

nominating for nsbeta3. Quicktime site is a widely used site and we are not sure 
when the content providers will be making this change.

Comment 8

[edburns]

Adding myself for CC.

Comment 9

[Marc Attinasi]

Approving for beta3: looks like the dependendent bug 43556, which is also 
beta3+, should fix this?

Comment 10

[av (gone)]

With couple of lines of code -- yes, it should.

Comment 11

[Jesse Ruderman]

I don't understand the dependency.  How is the operating system going to know 
what the correct mimetype is if the user hasn't already downloaded the plugin?  
Wouldn't it make more sense to ask http://cgi.netscape.com/cgi-bin/plug-
in_finder.cgi to guess the mimetype based on the extension?

(on Windows, Mozilla currently goes to 
http://cgi.netscape.com/cgi-bin/plug-in_finder.cgi?video/quicktime when given a 
mimetype of quicktime and when there is no "video/quicktime" entry in
HKEY_CURRENT_USER\Software\Netscape\Netscape Navigator\Default Plugin)

Comment 12

[av (gone)]

My guess is we are supposed to use HKEY_CLASSES_ROOT where tons of mime types 
are associated with file extensions even before a given plugin is installed. 
This is a good question to ask mscott (see 43556).

Comment 13

[av (gone)]

I've got a fix. Should we pump the priority up to get it in? Erick?

Comment 14

[ekrock's old account (dead)]

Yes. This is a P1 because Apple is a high profile partner and QuickTime is a 
high profile plug-in. This is also high profile backward compatibility. Setting 
priority to P1. Please check in fix as soon as you get any needed reviews.

Comment 15

[av (gone)]

Attachment: Patch which fixes it

Comment 16

[av (gone)]

The fix is in. Marking fixed.

Comment 17

[shrirang khanzode]

This is fixed on windows. Marking verified (build 2000092212m18)