modalDialog detection broken if findWindow() can't convert window to 'nsIWebBrowserChrome' (Permission denied for DOMAIN to create wrapper for object of class UnnamedClass)

RESOLVED FIXED

Status

Mozilla QA
Mozmill Tests
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: whimboo, Assigned: whimboo)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [lib][mozmill-test-failure])

Attachments

(2 attachments)

(Assignee)

Description

5 years ago
On bug 786230 we fail in detecting the opened install dialog. Reason is an exception which gets thrown inside findWindow() and which is not handled in the observe method:

http://hg.mozilla.org/qa/mozmill-tests/file/e7f70da2e7fc/lib/modal-dialog.js#l84

By moving the findWindow() call into the try/catch block I see the following exception:

****** exception: Error: Permission denied for <http://localhost:43336> to create wrapper for object of class UnnamedClass
*** window: [object ChromeWindow]

The fix is simple but I also have to investigate why the exception is thrown.
(Assignee)

Updated

5 years ago
Whiteboard: [lib][mozmill-test-failure]
(Assignee)

Comment 1

5 years ago
Created attachment 655990 [details] [diff] [review]
Kill application disconnects v1 [checked-in]
Attachment #655990 - Flags: review?(dave.hunt)

Updated

5 years ago
Attachment #655990 - Flags: review?(dave.hunt) → review+
(Assignee)

Comment 2

5 years ago
Comment on attachment 655990 [details] [diff] [review]
Kill application disconnects v1 [checked-in]

This patch simply kills the application disconnect errors for now but doesn't fix the underlying issue. This will be fixed in a follow-up patch.

Landed on default for now:
http://hg.mozilla.org/qa/mozmill-tests/rev/07c050c31c68

Will execute some tests before backporting.
(Assignee)

Comment 3

5 years ago
Comment on attachment 655990 [details] [diff] [review]
Kill application disconnects v1 [checked-in]

Patch works fine. No more disconnects for now:
http://mozmill-ci.blargon7.com/#/functional/report/d87d47fd1034f072b9bece6ee6d5dc50

Landed on other branches:
http://hg.mozilla.org/qa/mozmill-tests/rev/19f815d84870 (beta)
http://hg.mozilla.org/qa/mozmill-tests/rev/2f68a5df83e1 (release)
http://hg.mozilla.org/qa/mozmill-tests/rev/75b8a23b16f2 (esr10)

Aurora was done with the merge from default -> aurora:
http://hg.mozilla.org/qa/mozmill-tests/rev/07c050c31c68
Attachment #655990 - Attachment description: Kill application disconnects v1 → Kill application disconnects v1 [checked-in]
(Assignee)

Updated

5 years ago
Summary: modalDialog detection broken if findWindow() throws an exception → modalDialog detection broken if findWindow() can't convert window to 'nsIWebBrowserChrome' (Permission denied for DOMAIN to create wrapper for object of class UnnamedClass)
(Assignee)

Comment 4

5 years ago
This failure cannot be reproduced with an Aurora build like Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20120821 Firefox/16.0 ID:20120821042007

Looks like it is a regression or change in Firefox we don't know about yet. CC'ing Kyle who could probably help us out.

Problem here is the following code:

    var window = mozmill.wm.getMostRecentWindow('');

    // Get the WebBrowserChrome and check if it's a modal window
    var chrome = window.QueryInterface(Ci.nsIInterfaceRequestor).
                 getInterface(Ci.nsIWebNavigation).
                 QueryInterface(Ci.nsIDocShellTreeItem).
                 treeOwner.
                 QueryInterface(Ci.nsIInterfaceRequestor).
                 getInterface(Ci.nsIWebBrowserChrome);

When we are trying to get a nsIWebBrowserChrome reference we fail sometimes if the modal dialog has been opened by a content page, i.e. the addon install dialog.
Keywords: regression, regressionwindow-wanted
(Assignee)

Comment 5

5 years ago
I cannot reproduce with a Aug 23rd Nightly build but clearly with one from Aug 24th:

Pass: http://hg.mozilla.org/mozilla-central/rev/5650196a8c7d
Fail: http://hg.mozilla.org/mozilla-central/rev/1c0ac073dc65

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5650196a8c7d&tochange=1c0ac073dc65

I wonder if it could be related to bug 777072. I can check more when I'm back tomorrow.
(Assignee)

Updated

5 years ago
Component: Mozmill → Mozmill Tests
Product: Testing → Mozilla QA
(In reply to Henrik Skupin (:whimboo) from comment #5)
> I wonder if it could be related to bug 777072. I can check more when I'm
> back tomorrow.

That seems likely.  Mounir?
How is mozmill generating permissions?
(Assignee)

Comment 8

5 years ago
There seem to be a couple of tests affected, like installing addons or accessing SSL pages. For the former one we are whitelisting localhost so extensions can be installed without the notification bar showing up. It happens like this:

  pm.add(utils.createURI(aDomain),
         "install",
         Ci.nsIPermissionManager.ALLOW_ACTION);

But for the SSL pages we only set some preferences:

http://hg.mozilla.org/qa/mozmill-tests/file/c2a9444b6012/tests/functional/testSecurity/testEncryptedPageWarning.js#l16

But as mentioned earlier it doesn't fail all the time. When we are waiting for the modal dialog to open the code in question works a couple of times before it starts failing.

Next I will work on getting the exact changeset which caused this issue.
(Assignee)

Comment 9

5 years ago
So this is not related to the permission manager changes as we first thought of. I was able to nail down the regression range to the inbound merge:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cace7cc25814&tochange=e509c7472f30

There are way too many changes in this merge and I can't spot any offending changeset right now. I will bisect now.
Bug 757046 looks interesting.
(Assignee)

Comment 11

5 years ago
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #10)
> Bug 757046 looks interesting.

And that's it!

The first bad revision is:
changeset:   103203:c1e3da499d87
user:        Bobby Holley <bobbyholley@gmail.com>
date:        Thu Aug 23 11:45:28 2012 -0700
summary:     Bug 757046 - Convert enablePrivilege into an insecure test-only construct (preffed off everywhere but in automation). r=bz

So it's most likely a Mozmill bug now which we have to fix. I should have a patch later today.
Blocks: 757046
Keywords: regressionwindow-wanted
(Assignee)

Comment 12

5 years ago
Created attachment 656449 [details]
minimized testcase

This test fails in the >5th iteration like:

***** iteration: 0
TEST-PASS | /Volumes/data/code/mozmill-tests/nightly/testPermissions.js | testPermissions.js::setupModule
TEST-START | /Volumes/data/code/mozmill-tests/nightly/testPermissions.js | test
***** iteration: 1
***** iteration: 2
***** iteration: 3
***** iteration: 4
***** iteration: 5
***** iteration: 6
***** iteration: 7
ERROR | Test Failure: {"exception": {"stack": "", "message": "Permission denied for <http://www.mozqa.com> to create wrapper for object of class UnnamedClass", "fileName": "resource://mozmill/modules/frame.js -> file:///Volumes/data/code/mozmill-tests/nightly/testPermissions.js", "name": "Error", "lineNumber": 101}}
TEST-UNEXPECTED-FAIL | /Volumes/data/code/mozmill-tests/nightly/testPermissions.js | testPermissions.js::test


Line number 101 is:

    var chrome = window.QueryInterface(Ci.nsIInterfaceRequestor).
>                getInterface(Ci.nsIWebNavigation).
(Assignee)

Comment 13

5 years ago
CC'ing Boris in the hope he has an idea why we fail here in getting the Ci.nsIWebNavigation interface.
Well, the obvious answer is because your script doesn't have the system principal, so can't get wrappers to non-OM objects.  Is that the case?

If the script _is_ supposed to have the system principal, then clearly something is broken in the security manager.
tracking-firefox17: --- → ?
(Assignee)

Comment 15

5 years ago
(In reply to Boris Zbarsky (:bz) from comment #14)
> Well, the obvious answer is because your script doesn't have the system
> principal, so can't get wrappers to non-OM objects.  Is that the case?

But why does it work in the first number of iterations? It doesn't fail all the time but after x number of tries. So I don't think that this is the case here.

But can you be more specific what we would have to do in Mozmill to get the system principal? Setting the preference "security.enablePrivilege.enable_for_tests" doesn't help.

> If the script _is_ supposed to have the system principal, then clearly
> something is broken in the security manager.

Not sure what I should do next. Debugging getInterface() and find out why the exception is thrown? Or is there something else I should try first?
> But why does it work in the first number of iterations?

If it works for a bit and then stops, all in the same script, it sounds like a JIT bug.

What happens if you set "javascript.options.methodjit_always" to true?

> But can you be more specific what we would have to do in Mozmill to get the system
> principal?

Normally, run from a chrome:// URI.  The exception above (comment 12) is showing the principal as "http://www.mozqa.com".  I assume the code in comment 4 does not in fact live at that hostname?

> Not sure what I should do next

If you're willing to debug, you can breakpoint in the failure case in nsScriptSecurityManager::CanCreateWrapper and get the JS or C++ stacks.  That might give me some idea of what's going on...
And for what it's worth, so far it's sounding unlikely that the bug is on the mozmill side.
Severity: normal → critical
(Assignee)

Comment 18

5 years ago
(In reply to Boris Zbarsky (:bz) from comment #16)
> If it works for a bit and then stops, all in the same script, it sounds like
> a JIT bug.
> 
> What happens if you set "javascript.options.methodjit_always" to true?

It doesn't change the behavior. I still get the permission failure.

> Normally, run from a chrome:// URI.  The exception above (comment 12) is
> showing the principal as "http://www.mozqa.com".  I assume the code in
> comment 4 does not in fact live at that hostname?

This is from the testcase I have attached. We add that host to the whitelist, so that we can install extensions from it. The code in comment for lives in a test on the local disk which gets run by Mozmill.

> If you're willing to debug, you can breakpoint in the failure case in
> nsScriptSecurityManager::CanCreateWrapper and get the JS or C++ stacks. 
> That might give me some idea of what's going on...

I can try tomorrow.

(In reply to Boris Zbarsky (:bz) from comment #17)
> And for what it's worth, so far it's sounding unlikely that the bug is on
> the mozmill side.

I think in that case I will file a new bug because this one already contains Mozmill test related changes. I will move over all the information, flags, and dependencies.
> It doesn't change the behavior. I still get the permission failure.

Yes, but do you get it some number of iterations in, or immediately?
(Assignee)

Comment 20

5 years ago
(In reply to Boris Zbarsky (:bz) from comment #19)
> > It doesn't change the behavior. I still get the permission failure.
> 
> Yes, but do you get it some number of iterations in, or immediately?

It varies. Lately after the >10th iteration.
(Assignee)

Updated

5 years ago
Depends on: 786852
(Assignee)

Comment 21

5 years ago
Bug 786852 has been filed which handles the core issue. This bug will remain open for the mozmill-tests which are failing.
No longer blocks: 757046
Severity: critical → normal
tracking-firefox17: ? → ---
(Assignee)

Comment 22

5 years ago
The underlying bug in Firefox has been fixed and this failure cannot be seen any longer.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.