43620 - Need to launch the default plugin for full page mode

Status: VERIFIED WONTFIX

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

Description

[Nisheeth Ranjan]

Try accessing the above URL.  The URL will load, but, because you don't have the 
Acrobat plugin installed, nothing will show up in the content area.

We need to display an error/plugin-selection dialog of some sort when we come 
across content that needs to be rendered by an uninstalled plugin.

Comment 1

[shrirang khanzode]

yeah. I see it (build:2000070608) Also ,acrobat is broken right now(known bug)

Comment 2

[av (gone)]

Re-summarizing. Shrirang, how does it look in 4.x?

Comment 3

[shrirang khanzode]

In 4.x also, I see a blank content window if acrobat reader is not 
found/installed. Also a message box pops up saying "Could not load the plug-in 
'Adobe Acrobat' for the MIME type 'application/pdf'. Make sure enough memory is 
available and the plugin is installed properly.' Clicking OK on this message box 
also opens up a blank content window (similar to mozilla). 

Comment 4

[Andreas Franke (gone)]

With 4.x on PC/Linux, I immediately get a "Save As... (type application/pdf)"
dialog that allows me to save the pdf file to the local disk.

Comment 5

[Braden]

Is this a duplicate of bug 22954?

Comment 6

[shrirang khanzode]

Thanks for bringing this bug to my notice...thisis working fine in today's 
windows build.The pdf launches fine. CAn you pls confirm, nisheeth ?Thnx.

Comment 7

[shrirang khanzode]

actually..bug 22954 is different. This bug mentions about the browser handling 
the case when no acrobat reader is present on the user's machine(default plugin 
launching and informing the user). I renamed the nppdf32.dll on my machine and 
launch the url..and I see a crash today (2000071008)

Stack trace: 


 Call Stack:    (Signature = nsDocShell::NewContentViewerObj 33966d9b) 
     
   nsDocShell::NewContentViewerObj 
                                            
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2408]
     
   nsDocShell::CreateContentViewer 
                                            
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2350]
     
   nsDSURIContentListener::DoContent 
                                            
[d:\builds\seamonkey\mozilla\docshell\base\nsDSURIContentListener.cpp, line 101]
     
   nsDocumentOpenInfo::DispatchContent 
                                            
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 362]
     
   nsDocumentOpenInfo::OnStartRequest 
                                            
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 234]
     
   nsHTTPFinalListener::OnStartRequest 
                                            
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p, line 1153]
     
   nsHTTPCacheListener::OnStartRequest 
                                            
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p, line 149]
     
   nsDiskCacheRecordChannel::OnStartRequest 
                                            
[d:\builds\seamonkey\mozilla\netwerk\cache\filecache\nsDiskCacheRecordChannel.cp
p, line 640]
     
   nsOnStartRequestEvent::HandleEvent 
                                            
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 
213]
     
   nsStreamListenerEvent::HandlePLEvent 
                                            
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 
106]
     
   PL_HandleEvent 
                                            
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 588]
     
   PL_ProcessPendingEvents 
                                            
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 547]
     
   _md_EventReceiverProc 
                                            
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1045]
     
   USER32.dll + 0x1820 (0x77e71820)

Comment 8

[Andreas Franke (gone)]

This bug is still valid on PC/Linux, build 2000071008. To reproduce:
1) Make sure that you have _no_ pdf plugin installed.
2) Load this page: http://bugzilla.mozilla.org/show_bug.cgi?id=43620
3) Click on the URL link above the Summary field.
4) Observe that the pdf file is downloaded (the progress meter slowly counts
from 0% to 100%)
5) After that mozilla just displays "Document: Done (59.544 secs)".
   No error message, just plain nothing (but no crash either).

Comment 9

[av (gone)]

Shrirang, in fact, this bug I believe is connected to 22954. The fix for 22954 
by mistake returns success even if plugin not found screwing the rest of the 
code. I'll check in the fix for this oneliner as soon as I get it revewed.

Comment 10

[av (gone)]

It is in.

So without it we should a crash on every full-page invocation if we don't have a 
plugin installed. I.e. on every click on a link like this:
<a href=file.ext>text</a> if we don't have a plugin to handle *.ext files.

Should be OK now.

Comment 11

[av (gone)]

As to the original report. In 4.x the default plugin is not launched either in 
situations like this. Shrirang I see not exactly what you described. When I have 
no Acrobate plugin it pops up a Open/Save to File dialog box suggesting you to 
open it with AcrobatReader as an external helper app. Currently Mozilla shows a 
dialog letting you to choose from Save/PickApp/Cancel which is not really 
different. Why it is not giving you chance to use Acrobat as a helper app is 
another issue of general mime type to file extension association which mscott is 
working on.

So to me the original problem looks a candidate to invalid.

Comment 12

[shrirang khanzode]

i agree...

Comment 13

[Andreas Franke (gone)]

Note that the original summary of this bug was 
	"Need to display a Plugin not installed error dialog".

This bug had been filed as a split-off from bug 37032, 
being about exactly what I describe in my comments 2000-07-10 14:21.

So this shouldn't be marked invalid.

Comment 14

[shrirang khanzode]

Andreas, there is no parity between 4.x and mozilla for this issue(4.x also 
doen not pop up any error message). That's why andrei suggested the invalid 
status. 4.x also shows a similar dialog when the plugin is absent. The 'pick 
app' functionality is not working is a different issue. 

Comment 15

[Andreas Franke (gone)]

Have you tried to reproduce the problem described in my comments above?

The problem is not the "Pick App" dialog. The problem is that the document is
downloaded (which takes about a minute), but nothing happens with it, and there
is no dialog at all, no error dialog, no save as dialog, just nothing.
I think the document should not even be downloaded in this case.

If you enter the .pdf url into the location field, you get an 
"Unknown File Type" dialog, which is fine with me. But if I click the link to
this .pdf url on a page, it's a different behaviour.

In 4.x, I get a "Save As... (type application/pdf)" dialog in both cases.

I don't know if av's checkin from today has changed the behaviour. If is makes
the "Unknown File Type" dialog come up in both cases, then this bug could be
marked fixed (but not invalid :).

Adding 4xp keyword. Maybe the old summary should be restored.

Comment 16

[Andreas Franke (gone)]

Ok, withdrawing 4xp kw. I found an entry in 4.x for PDF saying 
"Unknown: Prompt User". 
Mozilla seems to have prefs for that already, but I did not see a pdf entry
listed there, although when I tried to add one, I got a dialog saying that there
is already a helper app registered for this.
Maybe this explains the difference.

Comment 17

[av (gone)]

My today change should fix this loading but doing nothig behaviour.

Comment 18

[Andreas Franke (gone)]

With today's Linux build (2000071108), it's basically the same thing as yesterday.
The pdf file is downloaded, but then nothing happens:
[New Thread 21555]
Document: Done (78.326 secs)
Document http://www.ipservices.att.com/ipaccess/gvpns/2000vpn.pdf loaded
successfully

Comment 19

[shrirang khanzode]

I see what Andreas has mentioned in his comments. Even on today's linux build 
(2000071208), if I click on a pdf link, the file seems to download but nothing 
happens. IF a url is entered in the url box, then "Unknown File Type" dialog 
spews up. This is still happening.

Comment 20

[ekrock's old account (dead)]

Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because
the Netscape engineer it is assigned to is overburdened.

Comment 21

[Peter Lubczynski]

If this is still happening, I'll see if I can fix it with my recent changes.

Comment 22

[Peter Lubczynski]

I don't think we want to fix this because if there is no plugin to handle the 
MIME type, then the content handler should take it over to the OS. Right Scott?

Suggesting WONTFIX

Comment 23

[Braden]

Peter: What do you mean by "take it over to the OS"?

Comment 24

[Peter Lubczynski]

So, to fix this bug, the default plugin should be launched when Netscape tries 
to open a file that it doensn't know about. 

This is wrong thing to do IMO, as the content handler does this. It brings up a 
dialog and asks if you want to "Open" or "Save" the file and even asks you what 
application you want to open it with if you have that registered in the OS.

Once again, nominating WONTFIX? Any objections?

Comment 25

[Peter Lubczynski]

Attachment: screenshot

Comment 26

[Braden]

Peter: Gotcha. Agreed.

Comment 27

[Peter Lubczynski]

WONTFIX per last comments

Comment 28

[shrirang khanzode]

v