Version: 0.6.85 (using KDE 4.6.1) OS: Linux On some pages, Rekonq wants to download a file named "safari.jsp" when displaying the content. Try e.g. http://www.hifi-forum.de/viewforum-33.html This is on a relatively fresh KDE 4.6 installation, no mime-types should have been changed, only Rekonq has been made the default browser. Reproducible: Always Steps to Reproduce: Open http://www.hifi-forum.de/viewforum-33.html Actual Results: As the last step of displaying this page, Rekonq wants to download a file Expected Results: The file probably contains Safari/Webkit-specific rendering infos (??) and should be treated accordingly.
I can confirm this. Another example would be http://kde-apps.org/ .
I cannot reproduce this bug at all. I'd like to have some more infos about, from each reporter: - distro: - KDE SC version: - Qt version: - rekonq version: some eventual results of the tests loading the sites with the network analyzer open. Thanks.
I can confirm this bug on kubuntu maverick kde SC 4.6.1 qt 4.7.0 rekonq 0.6.88 how can i copy/export the nertwork analyzer output?
Distro : Kubuntu 11.04 Qt: 4.7.2 KDE Development Platform: 4.6.1 (4.6.1) rekonq from latest git Could you please give us directions on how to conduct the said tests with the network analyser?
(In reply to comment #4) > Could you please give us directions on how to conduct the said tests with the > network analyser? I'd like just to know what request triggers the download. So, just follow the data flow coming and try identifying it... (a new idea about a step by step request download for the n a ? :D )
Looks like it comes from http://kde-apps.us.intellitxt.com/safari.jsp?x=1&t=1300615872055
Distro: Arch Linux KDE: 4.6.1 Qt: 4.7.1 rekonq: 0.6.95 Network analyzer says: Method: POST Url: http://kde-apps.us.intellitxt.com/safari.jsp?x=1&t=1300731315097 Answer: pending
*** Bug 270103 has been marked as a duplicate of this bug. ***
*** Bug 271286 has been marked as a duplicate of this bug. ***
It seems like this is not a rekonq but a server error. Safari has the same problems (https://discussions.apple.com/thread/2727040?start=0&tstart=75 ) and they say that JSPs (JavaServer Pages) should be server-side only and that they are not intended to be shown to the browser. Additionally, it seems like all these "safari.jsp" files come from one server, *.intellitxt.com, so as a workaround you can add this to your adblock list.
(In reply to comment #10) > It seems like this is not a rekonq but a server error. Safari has the same > problems (https://discussions.apple.com/thread/2727040?start=0&tstart=75 ) and > they say that JSPs (JavaServer Pages) should be server-side only and that they > are not intended to be shown to the browser. Additionally, it seems like all > these "safari.jsp" files come from one server, *.intellitxt.com, so as a > workaround you can add this to your adblock list. Adding *.intellitxt.com to adblock works. A true 'fix' seems still to be in order, but this work around is satisfactory. Thank you.
It's strange because it doesn't affect konqueror + webkit with adblock off :-/
I have "||intellitxt.com^" and "*.intellitxt.com" in my manual filters, but safari.jsp still comes up for download in, for example, theglobeandmail.com.
Try to use just "*intellitxt*", it works for me.
(In reply to comment #14) > Try to use just "*intellitxt*", it works for me. That did work, and got me to check why my filters didn't. It turned out the first period in "*.intellitxt.com*" was a problem. I guess some intellitxt URLs don't have anything else at the beginning of the host name. But it's weird that "||intellitxt.com^" in my manual filters doesn't do anything. Does rekonq's adblocking not recognize those kinds of expressions? There are a whole bunch of them in the EasyList. Are they just ignored?
Yes, default filter works not correctly, I have already reported this: https://bugs.kde.org/show_bug.cgi?id=280674 It is fixed in newer version.
it seems it works well against QtWebKit 2.2 with adblock disabled. Can someone of you confirm this?
Targetting 0.9 to not forget this...
*** This bug has been marked as a duplicate of bug 263870 ***