500349 - DOMParser no longer available in Greasemonkey scripts

Status: VERIFIED FIXED

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

Description

[Jesse Ruderman]

Attachment: simple greasemonkey script that shows the problem

In a Greasemonkey script, if I try to use "new DOMParser()", I get "ReferenceError: DOMParser is not defined".

Works on 1.9.1 branch, fails on mozilla-central.

This breaks my "Valid XHTML" Greasemonkey script, which I use while I'm editing blog posts.

Comment 1

[Alice0775 White]

http://hg.mozilla.org/mozilla-central/rev/fa9c9caa3886
Works:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090621 Minefield/3.6a1pre ID:20090621000409

Fails:
http://hg.mozilla.org/mozilla-central/rev/a8daae5ef5ce
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090621 Minefield/3.6a1pre ID:20090621093954

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fa9c9caa3886&tochange=a8daae5ef5ce

Comment 2

[Jesse Ruderman]

I suspect bug 484764, since that is known to have caused another regression involving dom parser, bug 500071.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: testcase

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

As Jesse guessed, this is a regression from bug 484764. The problem is that we now rely on nsDOMClassInfo::PostCreatePrototype to resolve the constructor on the window. However, when we're resolving through an XPCNativeWrapper (or, technically, a cross origin XOW with special privileges) we *don't* want to resolve onto the window, we want to resolve onto the wrapper.

It isn't immediately clear to me how we should fix this. I'm hoping peterv has ideas, though!

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

(oh, the testcase should alert "true").

Comment 6

[Peter Van der Beken [:peterv]]

Attachment: v1

This fixes attachment 386325 [details], still need to test with Greasemonkey.

Comment 7

[Alice0775 White]

If there is tryserver build, I am very glad

Comment 8

[Peter Van der Beken [:peterv]]

Comment on attachment 389617 [details] [diff] [review]
v1

This makes us do what the old code did. I think checking for |obj != aWin->GetGlobalJSObject()| should be ok, don't think I should check for XPCNativeWrapper here. Fixes the Greasemonkey testcase and Blake's testcase (I'll make a mochitest out of that one).

Comment 9

[Peter Van der Beken [:peterv]]

http://hg.mozilla.org/mozilla-central/rev/410eb23d33c7

Comment 10

[Michael Ryan]

Why was there another file deleted in that changeset?

Comment 11

[Peter Van der Beken [:peterv]]

(In reply to comment #10)
> Why was there another file deleted in that changeset?

I don't really know how that happened. I've backed out and relanded (twice, because rebase screwed me and somehow emptied my patch).

Backout:
http://hg.mozilla.org/mozilla-central/rev/6d21a1f54673
http://hg.mozilla.org/mozilla-central/rev/a5105991af66

Relanding 1 (empty changeset, rebase's fault):
http://hg.mozilla.org/mozilla-central/rev/793a3c7590b7

Relanding 2:
http://hg.mozilla.org/mozilla-central/rev/c2cc58728c8b

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Mass change: adding fixed1.9.2 keyword

(This bug was identified as a mozilla1.9.2 blocker which was fixed before the mozilla-1.9.2 repository was branched (August 13th, 2009) as per this query: http://is.gd/2ydcb - if this bug is not actually fixed on mozilla1.9.2, please remove the keyword. Apologies for the bugspam)

Comment 13

[Aakash Desai [:aakashd]]

verified FIXED on builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a2pre) Gecko/20090904 Namoroka/3.6a2pre ID:20090904033959

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090904 Minefield/3.7a1pre ID:20090904030702