Closed Bug 751406 Opened 12 years ago Closed 12 years ago

Script tests fail with "AssertionError: JavascriptException not raised"

Categories

(Remote Protocol :: Marionette, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla15

People

(Reporter: jgriffin, Assigned: jgriffin)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

Two of our script tests,

test_execute_async_script.py:TestExecuteAsyncContent.test_execute_permission and
test_execute_script.py:TestExecuteContent.test_execute_permission

fail because they expect an exception to be raised where none is.  See:

http://brasstacks.mozilla.com/autolog/?tree=b2g&source=autolog&rev=43721b8672923c1542b7959b6743debd782ae297
Previously, attempting to return Components.classes would throw a "Permission denied" error.  Now, it returns "undefined", at least in B2G.  Now, attempting to use Components.classes (instead of just accessing it), yields this:

"JavascriptException: TypeError: Components.classes is undefined"

It would be interesting to see if the same results are obtained in desktop Firefox.
(In reply to Jonathan Griffin (:jgriffin) from comment #1)

> It would be interesting to see if the same results are obtained in desktop
> Firefox.

On desktop Firefox (nightly), the previous behavior is still observed.  Attempting to access Components.classes yields:

JavascriptException: Error: Permission denied for <moz-safe-about:blank> to get property XPCComponents.classes
Chris, what's your take on this?

We have a sanity test that tries to do this in content:

   return Components.classes;

Previously in B2G, and presently in nightly Firefox, this would generate an expected JS exception:

JavascriptException: Error: Permission denied for <moz-safe-about:blank> to get property XPCComponents.classes

However, currently in B2G, this does not throw an Exception, rather it just returns "undefined".  Attempting to *use* Components.classes does generate an error, but a TypeError, rather than a Permission error:

JavascriptException: TypeError: Components.classes is undefined

I can't explain the difference between Firefox and B2G.  Is this a bug, or should we update the tests such that they don't assume that simply accessing Components.classes without using it should throw an exception?
Attached patch test patchSplinter Review
This patch allows the tests to pass on both B2G and desktop Firefox, but I'm not sure we want to use it or not.
Vivien, Fabrice do you guys know of anything that might have changed recently that could have led to this?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> Vivien, Fabrice do you guys know of anything that might have changed
> recently that could have led to this?

On the top of my head, no. Jonathan, can you bisect or do you need more help?
Jonathan, what are the test doing exactly? If i do dump(Components.classes) in Firefox, it returns 'undefined'. In which case should it return an error? Are the pages loaded in a special document or a regular web page?
The change seems to have occurred very recently. 

I had a version of Nightly that was running from a few days ago, and it gave me the JavaScript error, but in today's Nightly (15.0a1 (2012-05-02)), you will get 'undefined'. So we should see 'undefined' from both Nightly and B2G.
(In reply to Vivien Nicolas (:vingtetun) from comment #7)
> Jonathan, what are the test doing exactly? If i do dump(Components.classes)
> in Firefox, it returns 'undefined'. In which case should it return an error?
> Are the pages loaded in a special document or a regular web page?

The test is to make sure that the content JS code we send through execute_* doesn't have access to privileged methods.

It used to throw a permissions error when we tried to access Components.classes, but now it returns 'undefined'.
(In reply to Malini Das [:mdas] from comment #8)
> The change seems to have occurred very recently. 
> 
> I had a version of Nightly that was running from a few days ago, and it gave
> me the JavaScript error, but in today's Nightly (15.0a1 (2012-05-02)), you
> will get 'undefined'. So we should see 'undefined' from both Nightly and B2G.

I can confirm this.  Turns out I had my nightly was a couple of weeks old, due to some bug in the update procedure...it would download and appear to apply updates, but in fact it wasn't being updated.

After downloading the latest nightly, I see that Firefox now reports Components.classes as undefined as well, so this isn't a B2G issue.
Depends on: 751627
It seems that this behavior was intentional, so I have changed the affected tests to compensate:

http://hg.mozilla.org/integration/mozilla-inbound/rev/53796df4a12e
Assignee: nobody → jgriffin
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/53796df4a12e
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.