[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [moz-bonobo-list] Plugin claims application/octet-stream as type wh
From: |
Christian Glodt |
Subject: |
Re: [moz-bonobo-list] Plugin claims application/octet-stream as type when it's not |
Date: |
14 Jun 2003 15:07:32 +0200 |
On Sat, 2003-06-14 at 14:55, Jean Bréfort wrote:
> Le sam 14/06/2003 à 13:39, Christian Glodt a écrit :
>
> > The error message may be incorrect, as Jean Bréfort stated in
> > another mail. I'll correct that. The problem scenario however
> > seems to be the following: Mozilla downloads the file into its
> > cache. Files in the cache don't keep their usual filename, but
> > get renamed (an example cache file on my system is
> > ~/.mozilla/chris/9os9cqge.slt/Cache/A8C67739d01). The plugin
> > then tries to load a component which can open this file.
> > This fails because gnome-vfs doesn't detect the correct mime
> > type for the file in the cache. Then the plugin displays an
> > error message, based on the same (wrong) mime type detected by
> > gnome-vfs.
>
> Things might be somewhat different. I studied the problem because at one
> moment, gchem3d crashed and I bobobo-mozilla cmplaint that it could not
> load a text/plain file while the file was a chemical/x-mdl-molfile.
> Addint type="chemical/x-mdl-molfile" in the object tag did not change
> anything. When I replaced in mozilla-bonobo-viewer.c the
> get_mime_type_from_file_data by the get_mime_type_from_uri, the message
> was correct, so that the name transmitted to the plugin is the real
> name, not the one in the cache.
Yes, that will probably improve the error message.
> > So the solution is to fix gnome-vfs. Since that may take some
> > time (or may not be possible in all cases), the mime type needs
> > to be passed from the browser to the viewer, which can use it to
> > get a bonobo component for that mime type.
>
> For text files it will not be possible to get better. I suppose that if
> the result of gnome_vfs_get_mime_type_from_file_data is either
> text/plain or application/octet-stream, the other function should be
> called.
I think that it will be best to get the mime type from the
browser. Then we can instantiate a component that can handle
that mime type, and feed it the name of the file. That approach
should also work better for streaming content.
Cheers,
Christian Glodt