Closed
Bug 751406
Opened 12 years ago
Closed 12 years ago
Script tests fail with "AssertionError: JavascriptException not raised"
Categories
(Remote Protocol :: Marionette, defect)
Remote Protocol
Marionette
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla15
People
(Reporter: jgriffin, Assigned: jgriffin)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
1.51 KB,
patch
|
Details | Diff | Splinter Review |
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•12 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•12 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•12 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•12 years ago
|
||
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?
Comment 6•12 years ago
|
||
(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?
Comment 7•12 years ago
|
||
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?
Comment 8•12 years ago
|
||
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.
Comment 9•12 years ago
|
||
(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•12 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 | ||
Comment 11•12 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
Comment 12•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/53796df4a12e
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•1 year ago
|
Product: Testing → Remote Protocol
You need to log in
before you can comment on or make changes to this bug.
Description
•