Logger: Popup which shows the used filter is empty

[alexara]

Describe the issue

Clicking on an blocked item on the logger page opens an overlay which shows the filter list in question.
After disabling that filter list and reloading the page, you can still click on the logger page on the item which was blocked before the reload.
However, now the overlay is empty.

Screenshot in which the issue can be seen

Steps for anyone to reproduce the issue

1. Open a page, where at least one item is blocked by uBO
   e.g. http://www.continental-reifen.de/fahrrad/service/faq/montagehinweise
2. Go to the logger and see which filter list is responsible for blocking a specific item
3. Disable this filter list
4. Reload the page
5. Go to the logger and click again on the same blocked item: The overlay is now emtpy.

Your settings

• Browser/version: FF 50.0
• uBlock Origin version: 1.9.16

Your filter lists

Default

Suggestion

• Either
  disable the possibility of clicking on an blocked item where's no filter list known
• OR
  keep the filter list stored and show them even after a reload

[uBlock-user]

Fixed in #1691

[gorhill]

This was fixed in dev build.

[gwarser]

I can confirm in Fx 52 uBO 1.9.17rc0
on http://www.dobreprogramy.pl/Bitcoiny-w-PIT-Ministerstwo-Finansow-przypomina-o-obowiazku-podatkowym,News,77577.html

With "Anti-Adblock Killer | Reek" enabled

and disbled

[gorhill]

@gwarser Did you click on an old Reek's-related log entry after disabling Reek's?

[gwarser]

Yes, wp.pl entry.

[gorhill]

Not something that can be fixed -- uBO reverse lookup filters in memory only -- there is no use case for disabling a filter list and investigating the logger for filters no longer in effect.

[alexara]

Not something that can be fixed -- uBO reverse lookup filters in memory only -- there is no use case for disabling a filter list and investigating the logger for filters no longer in effect.

Oh, I actually meant that when I created this thread.

Wouldn't it make sense then to remove the possibility to investigate for a filter list, which is no longer in effect?
OR
instead of showing an empty popup, show "This request was blocked due a filter list which is no longer available" or something like that.

As it is now, it's confusing

[gorhill]

Oh, I actually meant that when I created this thread.

I did not read carefully, I missed this, I had assumed it was related to the solved issue. Sorry.

Yes, a meaningful message could be displayed.

[gwarser]

Logger overlay is also empty when cosmetic filter starts with dot.
For example for issue title on this page .com##.js-issue-title.
It's OK for github.com##.js-issue-title or com##.js-issue-title.

I found a lot of these invalid filters in 'Popup Blocker PLUS ( PL )', reported:
FiltersHeroes/PolishAnnoyanceFilters#9

[gorhill]

.com##.js-issue-title does not appear to be a valid filter, it does not work with ABP. That it works in uBO is just because of the specific implementation in uBO. Using com##.js-issue-title would be a valid filter. Two possibilities: I discard such invalid filters, or I accept that they can exist and fix the logger.

[stonecrusher]

It's not only invalid filters. \5f is unicode hex for underscore.

###\5f __plusone_0 from Fanboy's social blocking list works in terms of blocking as well as ###___plusone_0 does.

Not sure why they use hex replacement for underscore. If it is an error in the list (although blocking works) it would be nice to know what list that item is on when it pops up in the logger. However, it looks intentional because if class/ID begins with underscore, it is always replaced by \5f in that list.

First variation shows empty overlay, second works as intended.

Firefox 55.0.3 + uBO 1.13.8

/edit

The reason they use the escaped underscore is because W3C recommendation says leading - and _ should be reserved for vendor specific names. Probably it was automatically sanitized.

However using Hex is absolutely allowed in CSS, usually just no one uses it. So you can have different representations for the same object.

[joey04]

I made this patch that fixes the blank dialog box. (Note the TODO for making it a proper i18n message.)

Clicking on a rule not found shows this:

It's easy to verify - use methods mentioned before or just comment out one of your own rules after loading the relevant page with the logger open (so the rule is logged, of course). I then toggle the rule enable/disable several times, and the dialog box was correct found/not found each time.