Second test runs through JS proxy code produces unexpected exceptions

NEW
Assigned to

Status

()

Core
XPConnect
7 years ago
7 years ago

People

(Reporter: WeirdAl, Assigned: gal)

Tracking

({testcase})

Trunk
x86_64
Linux
testcase
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

7 years ago
Created attachment 505721 [details]
testcase
(Reporter)

Updated

7 years ago
blocking2.0: --- → ?
Expected results?  Actual results?  Steps to reproduce?  Alex, I know you can file a better bug report than just dumping in a code blob!
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
(Reporter)

Comment 2

7 years ago
This test is designed to pass equal but different objects through equal but different "SingletonHandler" instances, supposedly to elicit identical results through multiple passes.  It's also supposed to (but isn't guaranteed) pass a JS-based object and a DOM document through the same tests and generate identical results (with the exception of .toString()).

Steps:
(1) Open attachment 505721 [details] in FF4 trunk.
(2) Observe all four checkboxes ("First JSDoc test", "Second JSDoc test", "First native DOM document test", "Second native DOM document test") are checked.
(3) Click "Run test".

Expected results:
JSDoc1 and JSDoc2 present this text in the textarea, with no exceptions:

document: [object SimulatedDocument]
elem1: [object SimulatedElement]
elem2: [object SimulatedElement]
elem1 == elem2: true
elem1 === elem2: true
elem1.ownerDocument: [object SimulatedDocument]
document == elem1.ownerDocument: true
elem1.ownerDocument.getElementById('test') == elem1: true
elem3: [object SimulatedElement]
elem1 == elem3: true
elem1 === elem3: true
elem3.ownerDocument.getElementById('test') == elem1: true

Actual results:

We see the above text for JSDoc1.  For JSDoc2 (and DOMDoc1, DOMDoc2), we see this:

TypeError: can't convert doc to primitive type
RunTestWithDoc([object Proxy])@https://bug627648.bugzilla.mozilla.org/attachment.cgi?id=505721:315
RunTestByName("JSDoc2",getScriptObj)@https://bug627648.bugzilla.mozilla.org/attachment.cgi?id=505721:365
RunTest()@https://bug627648.bugzilla.mozilla.org/attachment.cgi?id=505721:376
onclick([object MouseEvent])@https://bug627648.bugzilla.mozilla.org/attachment.cgi?id=505721:1

We see the same exception for DOMDoc1 and DOMDoc2.

Note that past this point, I do not guarantee what the correct behavior is, and that the testcase could have other bugs in it.  Before this point, we were dealing strictly with JS-based objects.

Steps continued:
(4) Reload the web page.
(5) Uncheck "First JSDoc test" checkbox and click "Run test".

Expected results:  
JSDoc2 places this in the textarea:

document: [object SimulatedDocument]
elem1: [object SimulatedElement]
elem2: [object SimulatedElement]
elem1 == elem2: true
elem1 === elem2: true
elem1.ownerDocument: [object SimulatedDocument]
document == elem1.ownerDocument: true
elem1.ownerDocument.getElementById('test') == elem1: true
elem3: [object SimulatedElement]
elem1 == elem3: true
elem1 === elem3: true
elem3.ownerDocument.getElementById('test') == elem1: true

DOMDoc1 does not show this exception:

TypeError: can't convert doc to primitive type
RunTestWithDoc([object Proxy])@https://bug627648.bugzilla.mozilla.org/attachment.cgi?id=505721:315
RunTestByName("DOMDoc1",getDOMObj)@https://bug627648.bugzilla.mozilla.org/attachment.cgi?id=505721:365
RunTest()@https://bug627648.bugzilla.mozilla.org/attachment.cgi?id=505721:377
onclick([object MouseEvent])@https://bug627648.bugzilla.mozilla.org/attachment.cgi?id=505721:1

Actual results:  JSDoc2 generates the expected results, but DOMDoc1 and DOMDoc2 give the "can't convert doc to primitive type" exception.

Steps continued:

(6) Reload the web page.
(7) Uncheck "Second JSDoc test" checkbox and click "Run test".

At this point, you're dealing with DOM documents only, passed through the SingletonHandler's proxies.  The test itself may be invalid at this point, but hopefully a fixed version of the test case will generate this (or something close) in the textarea:

document: [object Document]
elem1: [object Element]
elem2: [object Element]
elem1 == elem2: true
elem1 === elem2: true
elem1.ownerDocument: [object Document]
document == elem1.ownerDocument: true
elem1.ownerDocument.getElementById('test') == elem1: true
elem3: [object Element]
elem1 == elem3: true
elem1 === elem3: true
elem3.ownerDocument.getElementById('test') == elem1: true
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Alex, a reduced testcase showing only what doesn't work would be very helpful here!
(Reporter)

Comment 4

7 years ago
Created attachment 507800 [details]
reduced testcase

This is as far as I dare reduce it.  Interestingly, when I tried it with Tom van Cutsem's ForwardingHandler, the error disappeared.  

I don't know what that means here.  It may mean that the bug is once again in my proxy testcase.  However, getScriptObj() returns a completely fresh object each time it's called, including a fresh proxy handler and internal hashtable.  So I don't see how different runs through RunTestWithDoc(getScriptObj()); should produce different results.
Andreas, any thoughts on whether this needs to block or not?
Not blocking on this.

Gary, Andreas was wondering if you may be able to reduce this further?
Assignee: nobody → gary
blocking2.0: ? → -
(Reporter)

Comment 7

7 years ago
Testcase from comment 0 is at least partially invalid:  in the getProxy method, it says

var proxyOuter = outer.getProxy(outer.target);
var rv = obj.apply(proxyOuter, arguments);

It should've said:

var rv = obj.apply(outer.target, arguments);
(Reporter)

Comment 8

7 years ago
After fixing my local copy of the testcase, I noticed something.  Running just JSDoc1 and JSDoc2, I see calls to valueOf() in JSDoc2, but not in JSDoc1.  I see the same running just DOMDoc1 and DOMDoc2:  DOMDoc2 has calls to valueOf, but not DOMDoc1.
With the testcase in comment 4, I get:

First pass:
hashtable counter: 0
hashtable counter: 1
document: [object SimulatedDocument]


Second pass:
hashtable counter: 0
hashtable counter: 1
hashtable counter: 1
TypeError: can't convert doc to primitive type
RunTestWithDoc([object Proxy])@file:///Users/fuzz2/Desktop/proxy_test.html:215
RunTest()@file:///Users/fuzz2/Desktop/proxy_test.html:247
onload([object Event])@file:///Users/fuzz2/Desktop/proxy_test.html:1

but I don't see anything in stdout or in the error console.

Alex, can you come up with a variant that prints the "TypeError: can't convert doc to primitive type" line to the console? I can then hopefully help with coming up with a further-reduced testcase looking out for this error.
Created attachment 509142 [details]
Reduced by another 85% from previous reduced testcase

(Nonetheless, nothing is unachievable in this world as long as one has determination..)

I'm hoping this is the error you're aiming for. This is a further-reduced testcase that brings the size down to < 1kb but (if valid) I'm sure someone can reduce it even more while I head to some much needed sleep past a newly-started Chinese New Year 2011 at 2am..

Hope this helps! Throwing back to the pool...
Attachment #505721 - Attachment is obsolete: true
Attachment #507800 - Attachment is obsolete: true
Assignee: gary → nobody
Status: REOPENED → NEW
(Reporter)

Comment 11

7 years ago
That looks roughly right... the exception matches, and the code flow looks like what I did.  Andreas, it's up to you.
Assignee: nobody → gal
You need to log in before you can comment on or make changes to this bug.