1295933 - Adblock Plus Broken XML moz binding cause element to be unreachable

Status: RESOLVED DUPLICATE of bug 119078

(Core :: DOM: Core & HTML, defect)

Description

[Tim Williams]

Attachment: firefox.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce:

1. clean Firefox with Adblock Plus extension
2. surf firefox.html


Actual results:

1. Element is hidden with moz binding (#adunit url("about:abp-elemhidehit?630904640176#dummy"))
2. Element moz-binding can't be override, even if set to none/url("") with important value.
3. Element is broken from the DOM and can't be presented anymore even if we remove the problematic class "adUnit" from the element.


Expected results:

1. element should be re-displayed if the problematic selector had been removed (and therefore no binding is presented on the element).
2. moz-binding should be over-writable when setting it to none with important value.

Comment 1

[Wladimir Palant]

I'm not sure I can follow. I assume that your Adblock Plus instance is configured with EasyList. This filter list contains the filter ###adunit. The purpose of that filter is hiding any element with id="adunit". What you are describing is merely this filter working properly. If this filter causes a false positive then the EasyList forum (https://forums.lanik.us/) is the right place to report it.

The fact that a webpage cannot override the filter has nothing to do with bindings - it would be the same if it were display:none. It's a user stylesheet so it takes priority over the author styles.

Comment 2

[Tim Williams]

no Waldimir, this is Firefox bug, or in fact, Adblockers exploiting this Firefox bug.
I know that ###adunit is part of easylist, but if you create an element with the id "adunit" then you change this id, the element is still hidden, because this Firefox bug cases the element to "die" and there is no way to use this element ever again!

Here is an example that should work (like in chrome):
<script>
var element = document.createElement('div'); // creating a div
document.documentElement.appendChild(element); // append it to DOM
element.id  = "adunit"; // give the element a "blacklisted selector" - element is now hidden
element.id  = "somethingElseThatShouldBeDisplayed"; // change the selector - element is still hidden
element.style.display = "block"; // element is still hidden
element.style.setProperty('-moz-binding','none','important'); // element is still hidden
</script>

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Tim,
Thanks for reporting the issue, though I am not quite sure I understand your question.

Per my best understanding of your comment 2, I wrote a simple test https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4398# 
I visited the link via Firefox with Adblock+ enabled, and I saw the text "should be displayed". 
If I comment the line |element.id = "something..."| in my test case, then the text is hidden.

I saw the behaviour on both FF48 and Nightly 51.

Comment 4

[Tim Williams]

sorry, bad example, it looks like ABP didn't have the time to inject his element biding class, this example will work (checked on both FF48 and Nightly 51)

<div id="adunit">should be displayed</div> <!-- this is an element with "blacklisted class" -->
<script>
window.setTimeout(function(){
	var element = document.getElementById('adunit'); // find the element
	element.id  = "somethingElseThatShouldBeDisplayed"; // change the selector - element is still hidden
	element.style.display = "block"; // element is still hidden
	element.style.setProperty('-moz-binding','none','important'); // element is still hidden
},500);
</script>

Comment 5

[Tim Williams]

Attachment: screenshot of before and after

Comment 6

[Tim Williams]

https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4399
https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4401

Comment 7

[Tim Williams]

any news about this one?

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Tim Williams from comment #5)
> Created attachment 8782425 [details]
> screenshot of before and after

According to the screenshot, seems even after ABP injects its element binding class, that div element is still accessbile and manipulable by the obervation that id is changed successfully. Doesn't that imply the element is still alive? What do you mean by "die" in comment 2?

Comment 9

[Wladimir Palant]

A broken XBL binding prevents frame construction - as far as the DOM is concerned the element is still there but it can never be visible.

Comment 10

[Tim Williams]

 Wladimir, this is clearly a bug, the element is "dead" and can't be visible anymore, even though it is clean now and not using the "blacklisted" class/id.

Comment 11

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Boris may have some ideas here. Save the NI when he's back from TPAC.

Comment 12

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Boris, could you clarify what expected behaviour is for the case of comment 4? Thanks!

Comment 13

[Boris Zbarsky [:bzbarsky]]

> element.style.setProperty('-moz-binding','none','important'); // element is still hidden

Untrusted script is not allowed to set -moz-binding, last I checked, so this won't do anything.

>	element.style.display = "block"; // element is still hidden

Its display was already "block", so this is a no-op.  But in any case, even toggling through different display styles won't help, because the binding association is just keyed on the element at this point...

So the only thing in comment 4 that could affect the binding is the id set.  That's almost certainly running into bug 119078.

The simplest thing to do to work around all this is to remove the element from the DOM and then reinsert it at the old position:

  var parent = element.parentNode;
  var next = element.nextSibling;
  element.remove();
  parent.insertBefore(element, next);