Closed Bug 604363 Opened 14 years ago Closed 14 years ago

Mozmill broken with tracemonkey merge (landing of compartments)

Categories

(Testing Graveyard :: Mozmill, defect)

defect
Not set
blocker

Tracking

(blocking2.0 beta7+)

VERIFIED FIXED
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: aaronmt, Assigned: mrbkap)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre

Running Mozmill 1.5.0 (JSBridge 2.4.0/Mozrunner 2.5.1) on the 10/14 build of Minefield will start the browser but will fail without proceeding with:

Traceback (most recent call last):
  File "/usr/local/bin/mozmill", line 8, in <module>
    load_entry_point('mozmill==1.5.0', 'console_scripts', 'mozmill')()
  File "/Library/Python/2.6/site-packages/mozmill/__init__.py", line 810, in cli
    CLI().run()
  File "/Library/Python/2.6/site-packages/mozmill/__init__.py", line 758, in run
    self.mozmill.start(runner=runner, profile=runner.profile)
  File "/Library/Python/2.6/site-packages/mozmill/__init__.py", line 244, in start
    self.appinfo = self.get_appinfo(self.bridge)
  File "/Library/Python/2.6/site-packages/mozmill/__init__.py", line 332, in get_appinfo
    results = {'application_id': str(appInfo.ID),
  File "/Library/Python/2.6/site-packages/jsbridge/jsobjects.py", line 94, in __getattr__
    attributes = self._bridge_.describe(self._name_)['attributes']
KeyError: 'attributes'

Related to the compartment JS stuff landing
Severity: normal → major
It's sad to see that those patches have been landed on mozilla central even it was known that a pre-build with compartments included has been broken Mozmill. It would have been nice to check with us again on that topic, before its landing. But now our testing framework is broken. :(
Severity: major → blocker
Summary: Mozmill failure with (10/14) trunk nightly - getting attributes in jsobjects.py → Mozmill broken with tracemonkey merge (landing of compartments)
blocking2.0: --- → ?
blocking2.0: ? → beta7+
>
> It's sad to see that those patches have been landed on mozilla central even it
> was known that a pre-build with compartments included has been broken Mozmill.

Getting nightly coverage is pretty critical, but I'm sorry things got done in this order.
Pushlog for the builds between 101013 and 101014:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=178f26e21cfc&tochange=ad0a0be8be74

I will try to run a bisect in the background.
Bisecting probably won't be worthwhile (the browser will just get buggier as you go back). The compartments guys should take a look.
Ok, anything we could do on our side to help you?

The code in question (on our side) is located here:
http://github.com/mozautomation/mozmill/blob/hotfix-1.5.1/jsbridge/jsbridge/jsobjects.py#L94
This has also broken the Thunderbird tinderboxes and developers.
Alright, we will fix this asap. If you can identify the code that broke that helps (as in #6/7).
Kinda hard for me to figure out the exact reason on our side. Would be great if someone else could step in here. Cling, Jeff, or Heather?

As far as I can see it's related to the mozmill.appInfo object. In the todays version of Minefield this object is null in the describe function.
Ok, so this seems to be an issue across different modules. I did some debugging and I can see the following:

In mozmill.js we create some XPCOM instances:
http://github.com/mozautomation/mozmill/blob/master/mozmill/mozmill/extension/resource/modules/mozmill.js#L74

Those instances are used in other modules by including mozmill.js like:

var mozmill = {}; Components.utils.import("resource://mozmill/modules/mozmill.js", mozmill);

When I add some code to another module like the one below I get different results:

var mozmill = {}; Components.utils.import("resource://mozmill/modules/mozmill.js", mozmill);
dump("** " + mozmill.wm + "\n");       => [xpconnect wrapped nsIWindowMediator]       
dump("** " + mozmill.appInfo + "\n");  => undefined
dump("** " + mozmill.locale + "\n");   => undefined

Having the same dumps in mozmill.js all of them contain valid instances of the XPCOM objects. The interesting thing is that in mozmill.js the dumps are only executed once. Even when I import the module multiple times. Is that expected? Do all imported modules share the same memory?
appInfo and locale aren't in mozmill.js' EXPORTED_SYMBOLS and so shouldn't be visible externally.

Modules are executed just once intentionally.
(In reply to comment #1)
> It's sad to see that those patches have been landed on mozilla central even it
> was known that a pre-build with compartments included has been broken Mozmill.

For what it's worth, this is the first I've heard of this bustage.
(In reply to comment #8)
> This has also broken the Thunderbird tinderboxes and developers.

Do you mean Thunderbird is broken, or that Thunderbird is relying on Mozmill?
(In reply to comment #13)
> > It's sad to see that those patches have been landed on mozilla central even it
> > was known that a pre-build with compartments included has been broken Mozmill.
> 
> For what it's worth, this is the first I've heard of this bustage.

We were asked to run the first builds for compartments a while ago and we gave feedback about this bustage (also see the wiki page). Further I mentioned that to Clint, who directly talked to you. I wanted to make sure that we don't end-up in the situation we have now.

The steps to install Mozmill can be found here:
https://developer.mozilla.org/en/Mozmill#The_Command_Line_Client
Henrik: thanks for the detailed digging. Could you zip up a profile with everything installed so people can jump right in?
(In reply to comment #12)
> appInfo and locale aren't in mozmill.js' EXPORTED_SYMBOLS and so shouldn't be
> visible externally.

Ah right. So that's not the reason for. So I was on the wrong path. Thanks.

(In reply to comment #16)
> Henrik: thanks for the detailed digging. Could you zip up a profile with
> everything installed so people can jump right in?

Not necessary. Once mozmill is installed as command line tool simply execute the command:

mozmill -b %path to minefield%
(In reply to comment #14)
> (In reply to comment #8)
> > This has also broken the Thunderbird tinderboxes and developers.
> 
> Do you mean Thunderbird is broken, or that Thunderbird is relying on Mozmill?

AFAICT the majority of Thunderbird is working - there's one bit that may not be, but I need to do some more diagnosis on that.

Thunderbird *is* relying on MozMill for its UI testing - we're not a browser so mochitest & co just don't make sense for Thunderbird.
(In reply to comment #18)
> 
> Thunderbird *is* relying on MozMill for its UI testing - we're not a browser so
> mochitest & co just don't make sense for Thunderbird.

OK cool. Just trying to make sure we had everything written down.
(In reply to comment #11)
> Ok, so this seems to be an issue across different modules. I did some debugging
> and I can see the following:
> 
> In mozmill.js we create some XPCOM instances:
> http://github.com/mozautomation/mozmill/blob/master/mozmill/mozmill/extension/resource/modules/mozmill.js#L74
> 
> Those instances are used in other modules by including mozmill.js like:
> 
> var mozmill = {};
> Components.utils.import("resource://mozmill/modules/mozmill.js", mozmill);
> 
> When I add some code to another module like the one below I get different
> results:
> 
> var mozmill = {};
> Components.utils.import("resource://mozmill/modules/mozmill.js", mozmill);
> dump("** " + mozmill.wm + "\n");       => [xpconnect wrapped nsIWindowMediator] 
> dump("** " + mozmill.appInfo + "\n");  => undefined
> dump("** " + mozmill.locale + "\n");   => undefined
> 
> Having the same dumps in mozmill.js all of them contain valid instances of the
> XPCOM objects. The interesting thing is that in mozmill.js the dumps are only
> executed once. Even when I import the module multiple times. Is that expected?
> Do all imported modules share the same memory?

Yeah, it should only dump once. Also we unlike wm, appInfo and locale aren't actually on mozmill.js's EXPORTED_SYMBOLS, so that makes sense.

I have a feeling this has more to do with the evalInSandbox we use.
(In reply to comment #20)
> I have a feeling this has more to do with the evalInSandbox we use.

But we only call that function right after the start of Minefield when the -t option has been specified and tests have to be run, but not without this option, right?
Blocks: 604362
Attached patch FixSplinter Review
We were creating Xray wrappers around chrome objects in chrome sandboxes. There's no reason to protect chrome from chrome, so this patch just disables that behavior entirely.
Assignee: nobody → mrbkap
Attachment #483295 - Flags: review?(peterv)
Attachment #483295 - Flags: review?(peterv) → review+
I think mrbkap just pushed that fix:

  http://hg.mozilla.org/mozilla-central/rev/ed24c21e6497

I've tried it out on jetpack-sdk and it has indeed fixed bug 604362, so hopefully it should fix Mozmill too!
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre
Status: RESOLVED → VERIFIED
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.