Closed Bug 1295933 Opened 3 years ago Closed 3 years ago

Adblock Plus Broken XML moz binding cause element to be unreachable

Categories

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

48 Branch
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 119078

People

(Reporter: tim.j.williams5, Unassigned)

Details

Attachments

(2 files)

Attached file 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.
Blocks: abp
Component: Untriaged → DOM
Product: Firefox → Core
Version: unspecified → 48 Branch
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.
No longer blocks: abp
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>
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.
Flags: needinfo?(tim.j.williams5)
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>
any news about this one?
(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?
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.
 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.
Flags: needinfo?(tim.j.williams5)
Boris may have some ideas here. Save the NI when he's back from TPAC.
Hi Boris, could you clarify what expected behaviour is for the case of comment 4? Thanks!
Flags: needinfo?(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);
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(bzbarsky)
Resolution: --- → DUPLICATE
Duplicate of bug: 119078
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.