[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Bug#22331: how to reproduce.
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-03-15 21:47:36
[Download RAW message or body]

On Thu, Mar 15, 2001 at 03:01:40PM -0500, Leon Bottou wrote:
> 
> How to reproduce the problem.
> 
> Requirements:
> - Latest cvs version of kdebase/nsplugins.
> - DjVu plugin (http://www.djvu.com/download).
> 
> Go to URL:
> http://www.djvuzone.org/cgi-bin/htdemo/makeframes?query=/djvu/sci/shannon/index.djvu?djvuopts&page=1
> 
> Without the patch, you will see a dialog asking whether you
> want to save the data into file.  The upper frame only contains a
> message
> from the nsplugin part explaining that a proper plugin could not be
> found.
> 
> The nsplugin part starts because KHTMLPart::processObjectRequest()
> has the mimetype information and can determine which part should run.
> But the nsplugin part also needs the mimetype in order to determine
> which plugin to run.  It does this using BrowserExtension::urlArgs()
> and looking at the UrlArgs::serviceType field.  But it is empty.
> 
> The patch suggested in my initial message simply copies
> the mimetype into the UrlArgs::serviceType field.
> With the patch, the plugin starts properly, and you can 
> see the djvu image in the upper frame.
> 
> This patch addresses a problem that will occur with every part
> that needs to access the actual mimetype in order to decide
> what to do (i.e. almost every part serving more than one mimetype).
> The nsplugin part is a good example.
> 
> Hope it helps.

Yes, it certainly helps! Thanks a lot for the analysis and patch!

I applied your patch slightly different though. It might be that a part
supports multiple servicetypes (like for example khtml or nspluginpart
does) and when re-using a part (meaning: we figure out the mimetype of
the url and realize that the part also supports that one, so we don't
need to create a new part) , then we also want to set the servicetype
in the URLArgs correctly, not only for newly created part.

Bye,
 Simon 

[prev in list] [next in list] [prev in thread] [next in thread]