Identify ElemHideEmulationFilters based on the filter text in the devtools panel

[sebastian]

Background

In order to show applied ElemHideFilters in the ​devtools panel we match the injected selectors against each element in the document, and report any selector that matches a hidden element, back to the background page, which then finds the corresponding filter and logs it to the devtools panel.

With #3596, we added logic to deal with ElemHideEmulationFilters, so that they show up in the devtools panel as well. For these kind of filters we cannot associate the generated selector with the original filter, however the actual filter text is available. But instead of passing the orginal filter through all the way to the devtools panel, we went with a more pragmatic approach and just extracted the selector part from the filter so that it works with the existing logic, introducing a slightly leaky abstraction.

Now, with #5094, we are going to integrate a new kind of ElemHideEmulationFilter that don't generate a selector in the first place, but hides elements directly. In order to log these filters in the devtools panel, we have to skip the tracing functionality, and potentially end up duplicating the hack.

What to change

Change the ElementHidingTracer in the content script and the devtools.traceElemHide message handler in the background page, so that the full filter text is sent and used to identify the filter, if available.

[abpbot]

A commit referencing this issue has landed:
​Issue 5117 - Identify ElemHideEmulationFilters based on the filter text in the devtools panel

[Ross]

Done. Hiding filters and ElemHideEmulationFilters appear in the ABP DevTools panel as expected.

ABP 1.13.2.1785
chrome 49 / 59 / Windows 7
Opera 39 / 45 / Windows 7