Bug 188455 - akregator executes flash regardless of plugin settings
Summary: akregator executes flash regardless of plugin settings
Status: RESOLVED DUPLICATE of bug 118908
Alias: None
Product: akregator
Classification: Applications
Component: akregator konqueror plugin (show other bugs)
Version: SVN
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-30 10:04 UTC by dietz
Modified: 2012-11-14 14:03 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dietz 2009-03-30 10:04:08 UTC
Version:           1.4.1 (using KDE 4.2.1)
OS:                Linux
Installed from:    Debian testing/unstable Packages

Akregator spawns nspluginviewer subprocesses regardless
of wether plugins are enabled.

Even worse, those nspluginviewers tend to run forever,
which leads to a couple of processes hanging around and
eating cpu cycles.

(BTW, this is an akregator bug but I did not find akregator
in the application list, so I filed under kontact, feel free to move
this bug to the appropriate place)
Comment 1 Bourdieu 2009-09-28 17:44:15 UTC
Confirmed here with KDE 4.2.4 and akregator 1.4.4.
Comment 2 dietz 2009-10-07 12:29:39 UTC
Hi,

I can still reproduce this with 4.3.1. (akregator 1.5.1).
After a short look at the sources I think this could be
a khtmlpart bug, because from the source it looks as if
plugin execution is disabled from akregator's code:

see http://websvn.kde.org/trunk/KDE/kdepim/akregator/src/articleviewer.cpp?view=markup (line 100):  m_part->setPluginsEnabled(false);
Comment 3 Christophe Marin 2009-11-28 01:34:53 UTC
This could be related to bug 208780. Can you test the solution in this comment: https://bugs.kde.org/show_bug.cgi?id=182869#c17 (running `QT_NO_GLIB=1 akregator` and see if the issue is reproducible)
Comment 4 dietz 2009-11-28 09:58:43 UTC
Just tried but after a little feed reading, I can still see nspluginviewer
instances.
Comment 5 Andrey Rakhmatullin 2010-02-02 09:50:45 UTC
4.3.95, still reproducible (and even when plugins are disabled in konqueror settings).

@dietz: QT_NO_GLIB=1 just prevents nspluginviewer from consuming CPU, it doesn't stop its launch.
Comment 6 François Tissandier 2010-04-19 08:14:57 UTC
I can confirm the problem on KDE 4.4 on Kubuntu Lucid Lynx. The main problem being that nspluginviewers are running forever, even if you closed the tab with the flash element. And they keep using all the CPU they need. On a laptop, it's a battery killer for sure.
Comment 7 Michael Andritschke 2010-06-14 19:42:18 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Arek Guzinski 2011-08-25 13:58:39 UTC
Hi,
this problem still exists in KDE 4.7 on gentoo and has the following effect, depending on which plugin is loaded:
gnash: spawns proccesses that consume CPU until killed (bad)
lightspark: makes akregator crash (very bad)
adobe-flash: makes akregator hang (as in: no more reaction) (very bad)

std(out|err) says:
akregator(6087)/kdecore (KLibrary) kde4Factory: The library "/usr/lib64/kde4/kwebkitpart.so" does not offer a qt_plugin_ins
akregator(6087)/kdecore (KLibrary) kde4Factory: The library "/usr/lib64/kde4/kwebkitpart.so" does not offer a qt_plugin_ins
(process:6087): GLib-GObject-CRITICAL **: gtype.c:2708: You forgot to call g_type_init()

(process:6087): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

(process:6087): Gdk-CRITICAL **: IA__gdk_x11_display_get_xdisplay: assertion `GDK_IS_DISPLAY (display)' failed

stacktrace (with kdevelop -> attach to proccess; with adobe-flash) says:

#0 send() at /lib64/libpthread.so.0:-1
#1 ??() at /usr/lib64/nsbrowser/plugins/npwrapper.libflashplayer.so:-1
#2 ??() at /usr/lib64/nsbrowser/plugins/npwrapper.libflashplayer.so:-1
#3 ??() at /usr/lib64/nsbrowser/plugins/npwrapper.libflashplayer.so:-1
#4 WebCore::PluginView::start() at plugins/PluginView.cpp:234
#5 WebCore::PluginView::init() at plugins/PluginView.cpp:192
#6 WebCore::ScrollView::addChild() at platform/ScrollView.cpp:68
#7 WebCore::moveWidgetToParentSoon() at rendering/RenderWidget.cpp:84
#8 WebCore::RenderWidget::setWidget() at rendering/RenderWidget.cpp:199
#9 WebCore::RenderPart::setWidget() at rendering/RenderPart.cpp:51
#10 WebCore::FrameLoader::loadPlugin() at loader/FrameLoader.cpp:1380
#11 WebCore::FrameLoader::requestObject() at loader/FrameLoader.cpp:1285
#12 WebCore::RenderEmbeddedObject::updateWidget() at rendering/RenderEmbeddedObject.cpp:285
#13 WebCore::FrameView::updateWidgets() at page/FrameView.cpp:1501
#14 WebCore::FrameView::performPostLayoutTasks() at page/FrameView.cpp:1531
#15 WebCore::FrameView::layout() at page/FrameView.cpp:770
#16 WebCore::ThreadTimers::sharedTimerFiredInternal() at platform/ThreadTimers.cpp:111
#17 QObject::event() at kernel/qobject.cpp:1180
#18 QApplicationPrivate::notify_helper() at kernel/qapplication.cpp:4461
#19 QApplication::notify() at kernel/qapplication.cpp:4340
#20 KApplication::notify() at /var/tmp/paludis/kde-base-kdelibs-4.7.0-r1/work/kdelibs-4.7.0/kdeui/kernel/kapplication.cpp:310
--
#0 pthread_cond_wait@@GLIBC_2.3.2() at /lib64/libpthread.so.0:-1
#1 WTF::TCMalloc_PageHeap::scavengerThread() at wtf/FastMalloc.cpp:2377
#2 WTF::TCMalloc_PageHeap::runScavengerThread() at wtf/FastMalloc.cpp:1496
#3 start_thread() at /lib64/libpthread.so.0:-1
#4 clone() at /lib64/libc.so.6:-1
-- 
#0 pthread_cond_timedwait@@GLIBC_2.3.2() at /lib64/libpthread.so.0:-1
#1 wait() at thread/qwaitcondition_unix.cpp:85
#2 QWaitCondition::wait() at thread/qwaitcondition_unix.cpp:159
#3 QThreadPoolThread::run() at concurrent/qthreadpool.cpp:139
#4 QThreadPrivate::start() at thread/qthread_unix.cpp:319
#5 start_thread() at /lib64/libpthread.so.0:-1
#6 clone() at /lib64/libc.so.6:-1
Comment 9 Maarten De Meyer 2012-11-14 14:03:01 UTC

*** This bug has been marked as a duplicate of bug 118908 ***