Using kwebkitpart 1.2.0, flashplugin 11.1

With default settings one konqueror process is preloaded and stays running on the background. Take a look settings -> Configure Konqueror -> performance -> preloading

Preloading is off. Besides, this only happens after visiting pages with flash. Otherwise the process it terminated normally.

Cannot reproduce. However, I am using flashplugin 11.2 beta package on my system. Is your machine 32 or 64 bit ?

(In reply to comment #4)
> Cannot reproduce. However, I am using flashplugin 11.2 beta package on my
> system. Is your machine 32 or 64 bit ?

64 bits

(In reply to comment #5)
> (In reply to comment #4)
> > Cannot reproduce. However, I am using flashplugin 11.2 beta package on my
> > system. Is your machine 32 or 64 bit ?
> 
> 64 bits

Then it is most probably a crashed Konqueror instance because there are known crashes with QtWebKit + flash 11.1 on 64 bit systems. The question is why you do not get a crash dialog. Can you try to attach to the process that remains and generate a backtrace for it ? On the command line do the following:

1.) gdb kdeinit4 <konqueror-PID> (Replay kdeinit4 with konqueror if you started Konqueror from the command line).

2.) type "bt" and press enter once you get the gdb prompt.

> 1.) gdb kdeinit4 <konqueror-PID> (Replay kdeinit4 with konqueror if you started
> Konqueror from the command line).
> 
> 2.) type "bt" and press enter once you get the gdb prompt.

(gdb) bt
#0  0x00007f70e1f178b3 in poll () from /lib/libc.so.6
#1  0x00007f70dee3ed58 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f70dee3f219 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f70e356f0ff in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007f70e2751f1e in ?? () from /usr/lib/libQtGui.so.4
#5  0x00007f70e353ee92 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007f70e353f0e7 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#7  0x00007f70e3543c45 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#8  0x00007f70d15609b2 in kdemain () from /usr/lib/libkdeinit4_konqueror.so
#9  0x00000000004083e4 in _start ()

(In reply to comment #7)
> > 1.) gdb kdeinit4 <konqueror-PID> (Replay kdeinit4 with konqueror if you started
> > Konqueror from the command line).
> > 
> > 2.) type "bt" and press enter once you get the gdb prompt.
> 
> (gdb) bt
> #0  0x00007f70e1f178b3 in poll () from /lib/libc.so.6
> #1  0x00007f70dee3ed58 in ?? () from /usr/lib/libglib-2.0.so.0
> #2  0x00007f70dee3f219 in g_main_context_iteration () from
> /usr/lib/libglib-2.0.so.0
> #3  0x00007f70e356f0ff in
> QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
> from /usr/lib/libQtCore.so.4
> #4  0x00007f70e2751f1e in ?? () from /usr/lib/libQtGui.so.4
> #5  0x00007f70e353ee92 in
> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from
> /usr/lib/libQtCore.so.4
> #6  0x00007f70e353f0e7 in
> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
> /usr/lib/libQtCore.so.4
> #7  0x00007f70e3543c45 in QCoreApplication::exec() () from
> /usr/lib/libQtCore.so.4
> #8  0x00007f70d15609b2 in kdemain () from /usr/lib/libkdeinit4_konqueror.so
> #9  0x00000000004083e4 in _start ()

Hmm... That looks ok to me. It looks like it is simply sitting idle in its main even loop. Did you try starting Konqueror from the command line ? Do you have the same result ? What if any error message do you see in ~/.xsession-errors after closing Konqueror ?

> Hmm... That looks ok to me. It looks like it is simply sitting idle in its main
> even loop. Did you try starting Konqueror from the command line ? Do you have
> the same result ? What if any error message do you see in ~/.xsession-errors
> after closing Konqueror ?

If I start konqueror from the command line the process is terminated correctly in every case

After closing the konqueror window and the process stays in memory, any subsequent konqueror window I open behaves strangely: tabs ramdomly swap their content, links don't respond to clicks, etc

(In reply to comment #9)
> > Hmm... That looks ok to me. It looks like it is simply sitting idle in its main
> > even loop. Did you try starting Konqueror from the command line ? Do you have
> > the same result ? What if any error message do you see in ~/.xsession-errors
> > after closing Konqueror ?
> 
> If I start konqueror from the command line the process is terminated correctly
> in every case

In that case there is likely something wrong with your install. More specifically kded4. Are there more than one such process running ? You can check by pressing CTRL+ESC and typing "kded4" in the "Quick Search" input field. Also you might want to check your ~/.xsession-errors file to see if there are any error message being printed out when you click on Konqueror's close button.

Is this issue still present in more recent versions of  KDE 4.8.1 or higher ? I cannot personally reproduce this problem.

(In reply to comment #12)
> Is this issue still present in more recent versions of  KDE 4.8.1 or higher
> ? I cannot personally reproduce this problem.

Yes. It is also present in rekonq, so it could be a qtwebkit issue

I've got this problem too, using KDE 4.8.3. I can also reproduce it:

1. In Konqueror, make Webkit the default browser engine.
2. Go to http://www.youtube.com/watch?v=McuHVXgR8dA and play the video.
3. Quit Konqueror.

The konqueror process remains active. Notice that this isn't a flash video. Even if you disable the plugins in konqueror, the problem still occurs.

I also have this issue, using Konqueror 4.8 with Webkit KPart. It happens not only with videos on Youtube, like in comment #14, but after heavy usage, too. However, it doesn't happen every time, so I wasn't able to find a repeatable way to reproduce the bug.
When the browser process stays after closing its window, there still are many kio_http processes running. However, after some time almost all of them quit, except for one. It stays active forever, just like the browser one. strace shows, that they both are waiting in select. If I manually kill either, the other one quits too. So it seems, that they are waiting for something from each other, producing a deadlock.
I didn't manage to reproduce this with KHTML engine. It means, that the bug is somewhere around the Webkit KPart. So I first compiled the Webkit KPart from Git, but it didn't solve the problem. Then I added a message box call into its destructor to make sure it is called - it was. With all that, I wasn't sure, against what this report should be filed, so let it be here.

Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!

kdelibs is dead