765837 - Google's mutation observer library won't load

Status: RESOLVED WORKSFORME

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

Description

[John Nagle]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0
Build ID: 20120612164001

Steps to reproduce:

Created an Jetpack-type content script add-on, and attempted to load Google's mutation-summary library (http://code.google.com/p/mutation-summary/source/browse/mutation_summary.js) as part of the content script


Actual results:

File "resource://551f2920-3c19-11e1-b86c-0800200c9a66-at-jetpack/adlimiter/data/mutation_summary.js", line 20, in
        if ('webkitMatchesSelector' in Element.prototype)
    TypeError: invalid 'in' operand Element.prototype





Expected results:

Should not have raised exception. 

This is just some startup code which is trying to handle "webKit" and "moz" prefixes if present. It's looking for a method in Element.prototype, which seems reasonable enough. Is something about Element.prototype broken in content scripts? Is this another place where the XRayWrapper mechanism is incomplete?

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

What is "content script" in this context?  Does the JS context have "Element"?
If it doesn't have Element, then raising the exception is the right thing to do.

Comment 2

[John Nagle]

Re: "What is "content script" in this context?"

It's a feature of the add-on SDK.

Ref: https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/addon-kit/page-mod.html

Comment 3

[John Nagle]

More background seems to be necessary.

Mutation observers aren't that useful for ordinary web pages with Javascript.  If your page is modifying itself, you known what it's doing.  They are primarily used by add-ons which watch over web pages - ad blockers, tracking blockers, rating systems, and such.  When the web page changes, the add-on needs to know about it.

The Mozilla "page mod" SDK exposes the DOM of a web page to the Javascript of the content script portion of the page mod add-on.  But the DOM is not exposed directly - DOM objects are encapsulated in proxy objects called XRayWrapper.  

The proxying is not perfect; every once in a while someone finds a flaw.  This may be another one.

Comment 4

[John Nagle]

Question: Were mutation observers in a content script ever tested? Is there a test case?  Maybe this just fell through the cracks.

Comment 5

[John Nagle]

(In reply to John Nagle from comment #4)
> Question: Were mutation observers in a content script ever tested? Is there
> a test case?  Maybe this just fell through the cracks.

   I'm able to get mutation observers to work in a content script without using Google's library.  So mutation observers do work in content scripts. Google's mutation summary library still doesn't work. Unclear whether this is Mozilla's problem or Google's problem.  But it ought to be fixed by somebody.  

   There's still some confusion over how "attributeFilter" works (see https://forums.mozilla.org/addons/viewtopic.php?p=21282), but that seems to be a separate problem.

Comment 6

[Ken Leland III]

I tested this and got the same error.
I am using Addon Kit 1.9 with firefox 15.1.

Comment 7

[yonatan]

The library doesn't work cause Element.prototype is undefined from some reason and not an object as it should be.

btw that happen only when using it as a content script (of an add-on), on the other hand with the scratchpad tool its an object as it should be.

SDK version 1.13.1
FF version 18.0.2 (Ubuntu)

Comment 8

[Matteo Ferretti [:zer0] [:matteo]]

So, it seems that this code:

    if ('webkitMatchesSelector' in Element.prototype)

Is working on Firefox Nightly (21) so probably some changes was done on platform side that fixed it.

Comment 9

[Gabor Krizsanits (INACTIVE)]

I think the reason why Element.prototype is undefined in content-script, that content-script is using an xray wrapper. Now xray wrappers are handling prototype quite badly / not at all, we have this problem... 
Probably this will be fixed only after the new DOM binding is landed for nodes/elements. I think if it's now fixed in ff 21, it is because Peter had some patches related to DOM prototypes with custom xrays, so it's great if this works, however I don't think that prototype property is fully functional... Anyway, if there is a quick fix needed for the time being one can use the Element.prototype.wrappedJSObject as a work around, to get an unwrapped version of the underlying prototype, which will work, but does not protect against any mutation the content did on Element.prototype.

Comment 10

[Abe - QA (:Abe_LV)]

User Agent 	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Version 	46.0a1
Build ID 	20160112030207
Channel 	nightly

Thank you for taking time to report this.
Are you still able to reproduce this in the latest version ?

Comment 11

[John Nagle]

It has been almost four years after the original bug report.  Asking that a bug be reproduced at this late date is insulting.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Nothing insulting there. Sorry that something happened with the triaging so that the bug never ended up to the right component.

But mutation observers have been implemented natively for years, so I doubt this is valid anymore

Comment 13

[Boris Zbarsky [:bzbarsky]]

> Asking that a bug be reproduced at this late date is insulting.

Except for the fact that in the meantime Xrays got changed so they have a useful .prototype, so the issue described in comment 9 no longer exists.  And since this bug doesn't have detailed steps to reproduce (e.g. an actual add-on to install and run, or clear step-by-step instructions for creating such an add-on for a platform engineer who's not familiar with the add-on sdk), it's hard for people to check themselves.