When having AdBlock enabled (with the option to hide filtered icons), depending on the filter icons might be missing on Konqueror's introduction page. I think Konqueror should not apply the AdBlock filters on its Introduction page at all. Reproducible: Always Steps to Reproduce: 1. Enable "Hide filtered icons" 2. Activate the "EasyList" filter 3. Click ok and restart Konqueror, or choose "Konqueror Introduction" from the Help menu Actual Results: Trash icon is missing (and probably others to depending on the filter I suppose). Expected Results: All icons should be shown correctly. This is with Konqueror 4.14.6 and kdelibs 4.14.6 from the KDE Applications 14.12.3 release. It has originally been reported here: https://bugzilla.opensuse.org/show_bug.cgi?id=916952
Created attachment 92112 [details] screenshot showing the issue Attached a screenshot showing the problem.
I cannot reproduce. However to discover what is the blocking rule you could try click the ad-block icon on the bottom right of konqueror window and move the mouse over a blocked element (rendered in red color), a tooltip showing the blocking rule should appear.
Created attachment 92128 [details] screenshot showing the matching filter rule (In reply to Andrea Iacovitti from comment #2) > I cannot reproduce. As mentioned, this happens here with the "EasyList" filter e.g. (https://easylist-downloads.adblockplus.org/easylist.txt), the last one in my list. "Hide filtered images" has to be activated too, of course. > However to discover what is the blocking rule you could try click the > ad-block icon on the bottom right of konqueror window and move the mouse > over a blocked element (rendered in red color), a tooltip showing the > blocking rule should appear. There is no mention at all of the blocked element in this dialog. After deactivating the "Hide filtered images" option (at the moment the image is still not shown btw, only an empty frame), I see it rendered in red now: file:///usr/share/icons/oxygen/48x48/status/user-trash-full.png The tooltip says: Blocked by V[0-9].*\-.*\-[a-z0-9]{4} (see newly attached screenshot) AFAICT, this shouldn't even match?
(In reply to Wolfgang Bauer from comment #3) > AFAICT, this shouldn't even match? Not an expert but I think it matches the double '-' in "user-trash-full.png" string The problem here is we do not fully support ad-block rules and in our implemetation for a filter rule like this: /\/[0-9].*\-.*\-[a-z0-9]{4}/$script,xmlhttprequest,domain=keezmovies.com|spankwire.com|tube8.com we end up to consider only the regexpr part: \/[0-9].*\-.*\-[a-z0-9]{4} ignoring its options (the ones after '$' sign)
Created attachment 92145 [details] plausible patch Better ignore regexpr with options as we do not support options.
(In reply to Andrea Iacovitti from comment #4) > The problem here is we do not fully support ad-block rules and in our > implemetation for a filter rule like this: > /\/[0-9].*\-.*\-[a-z0-9]{4}/$script,xmlhttprequest,domain=keezmovies. > com|spankwire.com|tube8.com > we end up to consider only the regexpr part: > \/[0-9].*\-.*\-[a-z0-9]{4} > ignoring its options (the ones after '$' sign) Oh. I somehow misread the rule as having a 'V' at the beginning instead of '\/'. That's why I was surprised that it matches at all... (In reply to Andrea Iacovitti from comment #5) > Created attachment 92145 [details] > plausible patch I tried the patch and can confirm that the icons indeed show up now with the EasyList filter active. I even tried to enable _all_ automatic filters. There's only a problem with Corset (http://brianyi.com/corset.txt) which specifies * as only filter rule. So not a bug in KHTML, although that filter should maybe be removed.
Git commit b806d664d078228e223f2b79645c366c0e23e719 by Andrea Iacovitti. Committed on 24/04/2015 at 10:52. Pushed by aiacovitti into branch 'KDE/4.14'. khtml-filter: Ignore regexp with options as we do not support them. FIXED-IN: 4.14.8 M +7 -1 khtml/khtml_filter.cpp http://commits.kde.org/kdelibs/b806d664d078228e223f2b79645c366c0e23e719
Repetition here: https://bugs.kde.org/show_bug.cgi?id=344013