Network transparency is again broken in KGhostView. send a pdf url in an email to kmail, then try to click on that link. It won't load the pdf file. This can be reproduced on the command line by copying the commandline that kmail tries to launch.
*** Bug 69259 has been marked as a duplicate of this bug. ***
I can reproduce on kmail, but not on the command line. I can also reproduce on minicli (ALT+F2) by pasting a .pdf URL (try http://www.cs.utexas.edu/users/ygz/378-03S/16.pdf ). On the commandline, however "kghostview http://www.cs.utexas.edu/users/ygz/378-03S/16.pdf -caption kghostview -icon unknown -miniicon unknown" on a konsole will work. Maybe the problem is elsewhere.... regards, luis
Subject: Re: kghostview network transparency is broken On Tuesday 02 December 2003 12:15, you wrote: > ------- I can reproduce on kmail, but not on the command line. > > I can also reproduce on minicli (ALT+F2) by pasting a .pdf URL (try > http://www.cs.utexas.edu/users/ygz/378-03S/16.pdf ). > > On the commandline, however > "kghostview http://www.cs.utexas.edu/users/ygz/378-03S/16.pdf -caption > kghostview -icon unknown -miniicon unknown" on a konsole will work. > > Maybe the problem is elsewhere.... I ran kghostview -caption foo url and it failed.
Subject: Re: kghostview network transparency is broken Is this CVS HEAD one is talking about? Today it works for me in all forms (kmail, minicli and command line ...). Also, I am not aware of any changes to kghostview's code which could be responsible for a change in this behaviour for months. Not to say that I couldn't have missed something, just strikes me as an unexpected bug. ciau, luis
Subject: Re: kghostview network transparency is broken On Thursday 04 December 2003 08:25, you wrote: > Is this CVS HEAD one is talking about? Yes > Today it works for me in all forms (kmail, minicli and command line ...). > > Also, I am not aware of any changes to kghostview's code which could be > responsible for a change in this behaviour for months. Not to say that I > couldn't have missed something, just strikes me as an unexpected bug. I most definitely cannot open pdf links from a kmail message. Actually I'm using kontact, not that it should matter. Other have reported this too.
It opens kghostview, and Loading Progress dialog, but doesn't download the pdf. If I save link as, it downloads. If I copy link location and paste it into the kghostview open file dialog, it downloads and opens. It doesn't work from minicli as mentioned above. The download starts, gets 72.1k of data, then stalls for some reason. Here is the tcpdump for a view of http://files.awdm.com/e-files/ra/22a/22a-um001d-en-e.pdf bash-2.05b# tcpdump host mars.awdm.com tcpdump: listening on eth0 ... (all ok till) ... 09:07:32.459122 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 63713:65161(1448) ack 375 win 32768 <nop,nop,timestamp 480069702 91608824> 09:07:32.461953 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 65161:66609(1448) ack 375 win 32768 <nop,nop,timestamp 480069702 91608824> 09:07:32.463761 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 68057:69505(1448) ack 375 win 32768 <nop,nop,timestamp 480069703 91608827> 09:07:32.463821 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: . ack 66609 win 5792 <nop,nop,timestamp 91608834 480069702,nop,nop,sack sack 1 {68057:69505} > (DF) 09:07:32.480267 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 69505:70953(1448) ack 375 win 32768 <nop,nop,timestamp 480069706 91608833> 09:07:32.480336 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: . ack 66609 win 5792 <nop,nop,timestamp 91608835 480069702,nop,nop,sack sack 1 {68057:70953} > (DF) 09:07:33.005737 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 66609:68057(1448) ack 375 win 32768 <nop,nop,timestamp 480069758 91608835> 09:07:33.048788 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: . ack 70953 win 2896 <nop,nop,timestamp 91608892 480069758> (DF) 09:07:33.073732 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 70953:72401(1448) ack 375 win 32768 <nop,nop,timestamp 480069765 91608892> 09:07:33.114760 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: . ack 72401 win 1448 <nop,nop,timestamp 91608899 480069765> (DF) 09:07:38.139144 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 72401:73849(1448) ack 375 win 32768 <nop,nop,timestamp 480070272 91608899> 09:07:38.139220 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: . ack 73849 win 0 <nop,nop,timestamp 91609401 480070272> (DF) 09:07:43.164484 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 73849:73850(1) ack 375 win 32768 <nop,nop,timestamp 480070775 91609401> 09:07:43.164553 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: . ack 73849 win 0 <nop,nop,timestamp 91609904 480070775> (DF) 09:07:48.173714 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 73849:73850(1) ack 375 win 32768 <nop,nop,timestamp 480071276 91609904> 09:07:48.173784 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: . ack 73849 win 0 <nop,nop,timestamp 91610405 480071276> (DF) 09:07:53.181381 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 73849:73850(1) ack 375 win 32768 <nop,nop,timestamp 480071777 91610405> 09:07:53.181452 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: . ack 73849 win 0 <nop,nop,timestamp 91610905 480071777> (DF) 09:07:58.189088 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 73849:73850(1) ack 375 win 32768 <nop,nop,timestamp 480072278 91610905> 09:07:58.189129 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: . ack 73849 win 0 <nop,nop,timestamp 91611406 480072278> (DF) 09:08:06.676850 mars.awdm.com.www > h24-71-25-33.wk.shawcable.net.49661: . 73849:73850(1) ack 375 win 32768 <nop,nop,timestamp 480073127 91611406> 09:08:06.676921 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: . ack 73849 win 0 <nop,nop,timestamp 91612255 480073127> (DF) 09:08:18.174526 h24-71-25-33.wk.shawcable.net.49661 > mars.awdm.com.www: R 375:375(0) ack 73849 win 49232 <nop,nop,timestamp 91613405 480073127> (DF) At 73849 it tells the server it wants 0 data for some reason (if I'm reading this correctly) then the download stops. Derek
*** Bug 60702 has been marked as a duplicate of this bug. ***
I did some investigation into this bug. It seems that the cause of the problem is lurking somewhere in KIO rather than in kghostview per se. If I understood correctly what is supposed to happen is: 1) a KGVRun object is created 2) the KGVRun object looks for a slave to use to fetch the file; this may be a newly created slave or one which was previously sitting around idle 3) the KGVRun fetches for long enough to figure out the mimetype, which then gets socked away for later use 4) the KGVRun puts its slave on "hold" 5) KIO::get is called to fetch the data 6) KIO::get asks for a slave, which may or may not be the one which was previously put on hold in step 4 7) KIO::get tells the slave to start fetching Now, it turns out that if KIO::get uses the slave which was put on hold in step 4, then the data never starts flowing -- the progress bar stays stuck at 0%. On the other hand, if KIO::get creates a new slave, then everything works peachy. Experimentally, it turns out that the question of whether or not KIO::get uses a new slave is in fact related to whether the KGVRun object created a new slave at step 2, or instead grabbed an idle slave from a pre-existing pool (this pool is maintained by KLauncher, if I understand right.) Namely, if KGVRun created a new slave, then KIO::get will also create a new slave, and everything will be fine. But if KGVRun grabbed an idle slave, then KIO::get will re-use that same slave, and the transfer will hang. I'm not knowledgeable enough on KIO to understand _why_ these things happen, and I wouldn't dare to try to patch KIO without learning a lot more about it. Nevertheless, one can work around this problem just by changing what happens in kghostview at step 4: namely, we can tell KGVRun to kill off its slave instead of putting it on hold. This fixes the problem at least on my system. It might not be the ideal fix, though; my vague understanding of KIO suggests that using the held slave would be more efficient; killing it might mean we open one connection, transfer a small amount of data, then drop it and open another connection to transfer the whole file. Still, this seems far preferable to the current situation! A patch implementing the above-described workaround will follow.
Created attachment 4270 [details] work around broken network transparency by never holding ioslave
Created attachment 4287 [details] work around broken network transparency by never holding ioslave (corrected version) Oops, I screwed up the patch -- here is a corrected version which should apply cleanly.
I applied the workaround to BRANCH, thanks a lot. I am reassigning the bug to KIO on the basis of Andy's nice analysis above. Can any KIO-expert comment on this? luis
Subject: Re: kghostview network transparency is broken Waldo would be the real expert on this, but let me try my luck: Does it work if you only remove KIO::Scheduler::publishSlaveOnHold(); but keep the job->putOnHold(); line ? This is what BrowserRun does, and it works ok. The publish line is wrong - it's about giving the slave to _another_ process, as happens from minicli or from konqueror when it launched another app; no wonder it's creating trouble here. But the putOnHold itself should be fine - it allows to resume from there in the ::get(), instead of opening another connection to the server from scratch.
Subject: kdegraphics/kghostview CVS commit by luis_pedro: 1 - When an error occurs, tell the user what the interpreter really is (it might help detect a misconfiguration). 2 - Use David Faure's sugestion for fixing network transparency (thanks, it works fine). CCMAIL: 69456-close@bugs.kde.org, 72940-close@bugs.kde.org M +7 -6 kgv_view.cpp 1.173 --- kdegraphics/kghostview/kgv_view.cpp #1.172:1.173 @@ -717,10 +717,12 @@ void KGVPart::slotGhostscriptOutput( cha void KGVPart::slotGhostscriptError( const QString& error ) { - // FIXME: find a significant error message - _logWindow->setLabel( i18n( "An error occurred in rendering.\n%1\n%2\n" ) + _logWindow->setLabel( i18n( "<qt>An error occurred in rendering.<br>" + "<strong>%1</strong><br>" + "The display may contain errors.<br>" + "Below are any error messages which were received from Ghostscript " + "(<nobr><strong>%2</strong></nobr>) " + "which may help you.</qt>" ) .arg( error ) - .arg( i18n( "You might see some errors in the display or it may work.\n" - "The error messages below are from Ghostscript (\"gs\") and may " - "help identify or correct the problem.\n" ) ), + .arg( configDialog()->interpreterPath() ) , true ); // The true above makes it show a "configure gs" option, but maybe we @@ -950,5 +952,4 @@ void KGVRun::foundMimeType( const QStrin KIO::TransferJob *job = static_cast< KIO::TransferJob* >( m_job ); job->putOnHold(); - KIO::Scheduler::publishSlaveOnHold(); m_job = 0; }