The default bug view has changed. See this FAQ.

Script tests fail with "AssertionError: JavascriptException not raised"

RESOLVED FIXED in mozilla15

Status

Testing
Marionette
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jgriffin, Assigned: jgriffin)

Tracking

(Depends on: 1 bug)

unspecified
mozilla15
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
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
(Assignee)

Comment 1

5 years ago
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.
(Assignee)

Comment 2

5 years ago
(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
(Assignee)

Comment 3

5 years ago
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?
(Assignee)

Comment 4

5 years ago
Created attachment 620529 [details] [diff] [review]
test patch

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'.
(Assignee)

Comment 10

5 years ago
(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.
(Assignee)

Updated

5 years ago
Depends on: 751627
(Assignee)

Comment 11

5 years ago
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
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.