[master] - Some elements remain buttons preventing removal.

[Duart Snel]

Take a look at this element from stackoverflow

<a id="aw0" target="_blank" href="some-url" onfocus="ss('aw0')" onmousedown="st('aw0')" onmouseover="ss('aw0')" onclick="ha('aw0')">
<img src="some-url">
</a>

These are for example the side ads that appear. they stay on the "click" mode and opens a new page on click instead of nuking the element.

this also seems to happen on youtube (you can remove the element surrounding the image on here but some inexperienced users wont know that)
Here's the youtube element

<div id="google_image_div" style="height: 250px; width: 300px; overflow:hidden; position:relative">
<a id="aw0" target="_blank" href="">
<img src="https://tpc.googlesyndication.com/daca_images/simgad/3811901932149519284"  class="img_ad">
</a>
</div>

[René Hansen]

Yeah I've noticed that it doesn't always behave entirely as expected. I have a sneaking suspicion, that we might not be able win out in all cases, due to whatever unforeseen Javascript magic is used on various sites.

E.g. if a click handler is attached to an element after ours, there's no way to stop that handler from firing on our end.

At the moment we attach click handlers to all a tags, but only on document load. If it's rendered after the fact, our handler won't trigger.

We should probably add that as part of the responsibility of the MutationObserver callback. To add our click handler to any new element injected on a page, which matches our targets list.

[René Hansen]

Stumbled over this example today:

https://blog.rescuetime.com/rescuetime-for-ios-removed

Here's an email popup modal, which actually loads an iframe with the content. It's near impossible to catch the containing iframe by itself, and so ekill fails completely in that case.

[René Hansen]

This problem is half-way solved with 2f56a44. Closing for now and solving on a case by case basis, when new examples pop up.