java plugin in nspluginviewer

Till Krech till at snafu.de
Mon Oct 21 19:57:51 BST 2002


On Monday 21 October 2002 06:47, George Staikos wrote:
> On October 20, 2002 18:05, Till Krech wrote:
> > There are several problems:
> > 1) I do not get any debug output from nspluginviewer. It is started from
> > a KProcess within the plugin_part in konqueror. My workaround: use
> > receivedStderr signal and a slotStderr wich does a kdDebug. Not very
> > nice.
>
>   Does it not go to .xsession-errors?
No it doesn't.
lsof says:
nspluginv 30340 till    0r   CHR        1,3            59659 /dev/null
nspluginv 30340 till    1w   CHR        1,3            59659 /dev/null
nspluginv 30340 till    2w   CHR        1,3            59659 /dev/null

>
> > 2) Width and height of a plugin are set to 1600 x 1200 by default.
> > Applets are then really that big (behind the scenes) and the embedded
> > widget only shows a small part of most applets.
> > The width and height attributes of an <object> tag are not passed to the
> > plugin which only understands parameters such as
> > <param name="width" value="400">
> > I found a workaround by 'converting' the attributes to pseudo params
> > __KHTML__WIDTH and __KHTML_HEIGHT in khtml/rendering/render_frames.cpp as
> > it is already done with other attributes like this:
> >       params.append( QString::fromLatin1("__KHTML__WIDTH=\"%1\"").arg(
> > o->getAttribute(ATTR_WIDTH).string() ) );
> >       params.append( QString::fromLatin1("__KHTML__HEIGHT=\"%1\"").arg(
> > o->getAttribute(ATTR_HEIGHT).string() ) );
>
>   I'm not sure about all of this stuff, but I do know that the 1600x1200
> size was done on purpose to fix problems with other plugins.  If they were
> started too small, then resizing them up to the required size didn't work.
But this might have been the same problem. In rev 1.67 of viewer/nsplugin.cpp 
the size was set to 300 x 300 regardless of which width and height were given 
in the tag attributes. Maybe plugins were always 300 x 300 ?
I do not know though, if the pseudo params approach is the best solution. Koos 
Vriezen told me, I should take the size of the QXEmbed widget which embeds 
the plugin. 
>
> > 3) The java plugin does not work with user agent strings other than
> > Netscape 4.7. It is possible to define a pseudo domain 'nspluginviewer'
> > and to set the user agent string for this domain. But this makes not much
> > sense. Why should a user be able/obligated to configure this ? Netscape
> > plugins are for Netscape browsers. nspluginviewer can only handle ns4
> > plugins.
>
>    Yes I guess we could hardcode this to a NS user agent.  I dont' see why
> not...
>
> > 4) there are crashes in the nspluginviewer because of memory corruption.
> > I tried to run konqueror with valgrind --trace-children but it stops when
> > loading the netscape plugin shared object file.
>
>     This could be related to #5 maybe?  I fixed a lot of these memory
> problems in the past, but then again, maybe I missed some.
>
> > 5) I found a (in my eyes) weird problem. Look at this
> > (kdebase/nsplugins): In nsplugin.h:
> > class NSPluginStreamBase : public QObject
> > {
> > Q_OBJECT
> > ...
> > private:
> > ----->   QByteArray _queue;
> > ...
> > }
> >
> > and in nsplugin.cpp:
> > NSPluginStreamBase::~NSPluginStreamBase()
> > {
> >    if (_stream) {
> >       _instance->NPDestroyStream( _stream, NPRES_USER_BREAK );
> >       delete _stream;
> >    }
> >
> >    delete _tempFile;
> > ----->   delete _queue;
> > }
> >
> > _queue is not a pointer. What happens upon delete ? Isn't _queue deleted
> > automatically when NSPluginStreamBase is deleted?
>
>    Yes this looks rather bad to me.  Please fix that one.  Just remove the
> delete.
Tried already but there are still random crashes in malloc.
So this seems not to be the only candidate. In addition, the plugin also 
allocates and frees memory using the nspluginviewer as a proxy.

-- 
Till Krech from Berlin, Germany is happy with
SuSE Linux 8.0 (i386) 2.4.18-64GB-SMP * KDE: 3.0.8 (KDE 3.1 beta2)
Qt: 3.1.0-b2 * gcc version 3.2





More information about the kfm-devel mailing list