If you access sites like youtube, the integrated (flash-?) player doesn't stop downloading large amounts of data when you close the actual tab. This is especial disturbing if you have limited (by bandwith, volume or money) internet access. Can you please consider to close network connetions belonging to a tab on leaving? Reproducible: Always Steps to Reproduce: 1. open a tab with a youtube video, play it 2. close the tab (halt the video is not enough) 3. check with netstat -n -t -p | grep -i "connected.*rekonq" Is it possible to decide between downloads triggered explictly by user (perhaps delegated to kget) and internal triggered ones (flash is buffering)?
This never happens here. Connections are every time (obviously) closed on tab closed. And the classes responsible for that destroyed. You can check in the code (TabWindow::closeTab(int) method). What you can see is just a kio connection yet listed for some seconds after tab has been destroyed.
Am Montag, 31. Dezember 2012, 16:29:29 schrieben Sie: > https://bugs.kde.org/show_bug.cgi?id=312200 > > Andrea Diamantini <adjam7@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEEDSINFO > Resolution|--- |INVALID > > --- Comment #1 from Andrea Diamantini <adjam7@gmail.com> --- > This never happens here. Connections are every time (obviously) closed on > tab closed. And the classes responsible for that destroyed. You can check > in the code (TabWindow::closeTab(int) method). > What you can see is just a kio connection yet listed for some seconds after > tab has been destroyed. (Happy new year Andrea!) I know that you are right aboutTabWindow::closeTab(int). So you and everybody else can expect the timely closing of a network connection. What I can state is that the timely closing you described above happens if you close the hole rekonq (not the tab only). But this bug is about the tab case. I'am very sure about the reported behavior (here). Now the problem starts: I'am not aware about a (CLI) tool doing per process netstats in linux. Are you? (netstat, ss, /proc don't count per PID, for using iptables -m owner I don't know the PID beforehand) So I used strace and did some digging: strace -p `pidof rekonq` -f -t -e open,write,read,close -o rekonq.trace to catch read() and write() on fd->sockets for byte counting. But a first look shows that this doesn't seem to match (-f!) the PID's I have to kill to stop the network traffic. The PIDs to kill are shown with pstree -p as attached to kde_init->kio_http. I did some scripting here to get a little bit automation. But before I start real work, I'd like to ask you if you have an idea, how to proceed? TIA! Bernhard
oops.. I noticed today this has been erroneously set to needsinfo -> invalid. Correct actual bug state should be IMHO, needsinfo --> waitingforinfo. I cannot reproduce this bug yet and I need a reproducible testcase for it.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!