Closed
Bug 604363
Opened 14 years ago
Closed 14 years ago
Mozmill broken with tracemonkey merge (landing of compartments)
Categories
(Testing Graveyard :: Mozmill, defect)
Testing Graveyard
Mozmill
Tracking
(blocking2.0 beta7+)
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta7+ |
People
(Reporter: aaronmt, Assigned: mrbkap)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
peterv
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•14 years ago
|
Severity: normal → major
Comment 1•14 years ago
|
||
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)
Updated•14 years ago
|
Updated•14 years ago
|
blocking2.0: --- → ?
Updated•14 years ago
|
blocking2.0: ? → beta7+
Comment 2•14 years ago
|
||
>
> 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.
Comment 3•14 years ago
|
||
Something in this pretty huge list of patches is the cause:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3c762301b719&tochange=29c228a4d7eb
Keywords: regression,
regressionwindow-wanted
Comment 4•14 years ago
|
||
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.
Comment 5•14 years ago
|
||
Bisecting probably won't be worthwhile (the browser will just get buggier as you go back). The compartments guys should take a look.
Comment 6•14 years ago
|
||
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
Comment 7•14 years ago
|
||
And the JS code which retrieves the information within the browser:
http://github.com/mozautomation/mozmill/blob/hotfix-1.5.1/jsbridge/jsbridge/extension/resource/modules/server.js#L106
Comment 8•14 years ago
|
||
This has also broken the Thunderbird tinderboxes and developers.
Comment 9•14 years ago
|
||
Alright, we will fix this asap. If you can identify the code that broke that helps (as in #6/7).
Comment 10•14 years ago
|
||
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.
Comment 11•14 years ago
|
||
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?
Comment 12•14 years ago
|
||
appInfo and locale aren't in mozmill.js' EXPORTED_SYMBOLS and so shouldn't be visible externally.
Modules are executed just once intentionally.
Assignee | ||
Comment 13•14 years ago
|
||
(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.
Comment 14•14 years ago
|
||
(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?
Comment 15•14 years ago
|
||
(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?
Comment 17•14 years ago
|
||
(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%
Comment 18•14 years ago
|
||
(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.
Comment 19•14 years ago
|
||
(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.
Comment 20•14 years ago
|
||
(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.
Comment 21•14 years ago
|
||
(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?
Assignee | ||
Comment 22•14 years ago
|
||
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)
Updated•14 years ago
|
Attachment #483295 -
Flags: review?(peterv) → review+
Updated•14 years ago
|
Blocks: 580128
Keywords: regressionwindow-wanted
Comment 23•14 years ago
|
||
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!
Assignee | ||
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 25•14 years ago
|
||
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre
Status: RESOLVED → VERIFIED
Updated•8 years ago
|
Product: Testing → Testing Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•