Closed
Bug 815807
Opened 11 years ago
Closed 11 years ago
Make Marionette load later in B2G startup cycle, except when --load-early is passed
Categories
(Remote Protocol :: Marionette, defect)
Tracking
(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)
People
(Reporter: jgriffin, Assigned: jgriffin)
References
Details
Attachments
(6 files, 3 obsolete files)
953 bytes,
patch
|
ahal
:
review+
|
Details | Diff | Splinter Review |
8.80 KB,
patch
|
jgriffin
:
review+
|
Details | Diff | Splinter Review |
990 bytes,
patch
|
Details | Diff | Splinter Review | |
875 bytes,
patch
|
Details | Diff | Splinter Review | |
1.43 KB,
patch
|
past
:
review+
|
Details | Diff | Splinter Review |
5.17 KB,
patch
|
jgriffin
:
review+
|
Details | Diff | Splinter Review |
In order to allow us to land bug 800138, which allows Marionette to work remotely on pandas, we need to load Marionette later in the startup process. However, this breaks WebAPI tests on emulators. Therefore, we need to optionally allow Marionette to preserve it's current early-loading behavior on B2G. We can add a --load-early argument to facilitate this.
Assignee | ||
Updated•11 years ago
|
Target Milestone: --- → B2G C2 (20nov-10dec)
Assignee | ||
Comment 1•11 years ago
|
||
In order to implement this without breaking anything on TBPL, I'll have to land three patches in sequence: 1 - gecko patch which adds --load-early to the Marionette Python client 2 - a mozharness script change to add --load-early to the webapi tests 3 - gecko patch which causes the Marionette server to act differently when --load-early is passed
Assignee: nobody → jgriffin
Assignee | ||
Comment 2•11 years ago
|
||
This will be slightly bitrotted by bug 790817, but I'll unbitrot it before landing if needed. This patch has no effect until parts 2 and 3 land (not yet submitted).
Attachment #686225 -
Flags: review?(ahalberstadt)
Assignee | ||
Comment 3•11 years ago
|
||
This is the mozharness script change; it can't land until part 1 has propagated to all the trees, in order to avoid breaking things in TPBL
Attachment #686228 -
Flags: review?(ahalberstadt)
Assignee | ||
Updated•11 years ago
|
Attachment #686225 -
Attachment is obsolete: true
Attachment #686225 -
Flags: review?(ahalberstadt)
Assignee | ||
Updated•11 years ago
|
Attachment #686225 -
Attachment is obsolete: false
Assignee | ||
Comment 4•11 years ago
|
||
Comment on attachment 686225 [details] [diff] [review] Part 1: add --load-early arg to Marionette, Blargh, bzexport unset the review flag.
Attachment #686225 -
Flags: review?(ahalberstadt)
Comment 5•11 years ago
|
||
Comment on attachment 686225 [details] [diff] [review] Part 1: add --load-early arg to Marionette, Review of attachment 686225 [details] [diff] [review]: ----------------------------------------------------------------- ::: testing/marionette/client/marionette/emulator.py @@ +401,5 @@ > + self.wait_for_system_message(marionette) > + > + def restart_b2g(self): > + print 'restarting B2G' > + self.dm.shellCheckOutput(['stop', 'b2g']) We should probably start using mozb2g to get all of the b2g specific stuff out of here, but I won't block on that since this is time sensitive. I'm guilty of just adding the install_busybox method ;)
Updated•11 years ago
|
Attachment #686225 -
Flags: review?(ahalberstadt) → review+
Updated•11 years ago
|
Attachment #686228 -
Flags: review?(ahalberstadt) → review+
Assignee | ||
Comment 6•11 years ago
|
||
(In reply to Andrew Halberstadt [:ahal] from comment #5) > Comment on attachment 686225 [details] [diff] [review] > Part 1: add --load-early arg to Marionette, > > Review of attachment 686225 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: testing/marionette/client/marionette/emulator.py > @@ +401,5 @@ > > + self.wait_for_system_message(marionette) > > + > > + def restart_b2g(self): > > + print 'restarting B2G' > > + self.dm.shellCheckOutput(['stop', 'b2g']) > > We should probably start using mozb2g to get all of the b2g specific stuff > out of here, but I won't block on that since this is time sensitive. I'm > guilty of just adding the install_busybox method ;) I agree, after all the fires are out we should clean up a lot of things. I'll file a bug for this if I can't find an existing one.
Assignee | ||
Comment 7•11 years ago
|
||
Bug 816236 filed for getting Marionette to use mozdevice/mozb2g.
Assignee | ||
Comment 8•11 years ago
|
||
Part 1: https://hg.mozilla.org/integration/mozilla-inbound/rev/60a1cb7e8b79
Whiteboard: [automation-needed-in-aurora][automation-needed-in-beta][leave open]
Assignee | ||
Comment 9•11 years ago
|
||
Unbitrotted; carry r+ forward.
Attachment #686225 -
Attachment is obsolete: true
Attachment #686255 -
Flags: review+
Assignee | ||
Comment 10•11 years ago
|
||
I realized I needed to tweak some code to prevent breakage until part 2 lands, so here it is.
Assignee | ||
Comment 11•11 years ago
|
||
Part 1a: https://hg.mozilla.org/integration/mozilla-inbound/rev/2c3ca2156b00
Assignee | ||
Comment 12•11 years ago
|
||
And I realized when I merged Part 1 with inbound, on which bug 790817 landed, I made a typo which broke Marionette on TBPL. Here's the fix. :sigh: https://hg.mozilla.org/integration/mozilla-inbound/rev/702ff40d1447
Assignee | ||
Comment 13•11 years ago
|
||
This patch takes some of past's work from bug 800138, along with patch 1 on this bug to load marionette early only if a pref is set. Also does some cleanup of related code on the Python side. Tested locally and it works fine.
Attachment #686343 -
Flags: review?(ahalberstadt)
Comment 14•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/60a1cb7e8b79 https://hg.mozilla.org/mozilla-central/rev/2c3ca2156b00 https://hg.mozilla.org/mozilla-central/rev/702ff40d1447
Comment 15•11 years ago
|
||
Comment on attachment 686343 [details] [diff] [review] Part 3: Load marionette early in the B2G startup process if relevant pref is set, otherwise load it late, Review of attachment 686343 [details] [diff] [review]: ----------------------------------------------------------------- Heh, I have no idea why any of this is needed. r+ Do you think in the future we could pass in the actual event to wait for via pref? That would make things a bit more flexible in case we find ourselves needing to wait for yet another event, or the events change.
Attachment #686343 -
Flags: review?(ahalberstadt) → review+
Assignee | ||
Comment 16•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/5b81398a1ea2 https://hg.mozilla.org/releases/mozilla-aurora/rev/7cbfbb0bcb89 https://hg.mozilla.org/releases/mozilla-aurora/rev/ba6628781ca1
Whiteboard: [automation-needed-in-aurora][automation-needed-in-beta][leave open] → [automation-needed-in-beta][leave open]
Assignee | ||
Comment 17•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/db23aec39973 https://hg.mozilla.org/releases/mozilla-beta/rev/ed3420ea3e63 https://hg.mozilla.org/releases/mozilla-beta/rev/c63bc3273e92
Whiteboard: [automation-needed-in-beta][leave open] → [leave open]
Assignee | ||
Comment 18•11 years ago
|
||
Part 2: http://hg.mozilla.org/build/mozharness/rev/ff8bda110d82
Assignee | ||
Comment 19•11 years ago
|
||
Pushed part 3 to try: https://tbpl.mozilla.org/?tree=Try&rev=c714fc81f334
Assignee | ||
Comment 20•11 years ago
|
||
(In reply to Jonathan Griffin (:jgriffin) from comment #19) > Pushed part 3 to try: https://tbpl.mozilla.org/?tree=Try&rev=c714fc81f334 This patch breaks mochitest. The reason is that when we restart B2G after installing the test profile, we never get a 'system-message-listener-ready' event, so Marionette never gets initialized. I'm not quite sure why this is. The workaround is to add the loadearly pref to the test profile, for which I'll attach a patch. We won't be able to run mochitests on pandas until we find a better way to deal with this, but I guess that's a fight for another day.
Assignee | ||
Comment 21•11 years ago
|
||
This revision fixes bustage with mochitest and reftest.
Attachment #686343 -
Attachment is obsolete: true
Attachment #686930 -
Flags: review?(ahalberstadt)
Assignee | ||
Comment 22•11 years ago
|
||
Pushed new version of Part 3 to try: https://tbpl.mozilla.org/?tree=Try&rev=bb5f83086e20
Assignee | ||
Comment 23•11 years ago
|
||
(In reply to Andrew Halberstadt [:ahal] from comment #15) > Comment on attachment 686343 [details] [diff] [review] > Part 3: Load marionette early in the B2G startup process if relevant pref is > set, otherwise load it late, > > Review of attachment 686343 [details] [diff] [review]: > ----------------------------------------------------------------- > > Heh, I have no idea why any of this is needed. r+ > > Do you think in the future we could pass in the actual event to wait for via > pref? That would make things a bit more flexible in case we find ourselves > needing to wait for yet another event, or the events change. I wouldn't want to have to pass in a pref with an event name in it, since it would force the Python client to be more closely coupled with the JS bits, which would mean that version mistmaches between client and server (which are quite common in the wild and usually harmless) could end up being bad. We'd also have to propagate a change like that to the JS client, so I think I'm in favor of leaving things as-is.
Comment 24•11 years ago
|
||
(In reply to Jonathan Griffin (:jgriffin) from comment #23) > I wouldn't want to have to pass in a pref with an event name in it, since it > would force the Python client to be more closely coupled with the JS bits, > which would mean that version mistmaches between client and server (which > are quite common in the wild and usually harmless) could end up being bad. > We'd also have to propagate a change like that to the JS client, so I think > I'm in favor of leaving things as-is. Oops, I shouldn't have said pref. I meant command line argument (i.e instead of --load-early, --load-event <event name>). Anyway, not important for now at least.
Comment 25•11 years ago
|
||
Comment on attachment 686930 [details] [diff] [review] Part 3: Load marionette early in the B2G startup process if relevant pref is set, otherwise load it late Review of attachment 686930 [details] [diff] [review]: ----------------------------------------------------------------- Lgtm
Attachment #686930 -
Flags: review?(ahalberstadt) → review+
Assignee | ||
Comment 26•11 years ago
|
||
Part 3: https://hg.mozilla.org/integration/mozilla-inbound/rev/9252522aab90 I'll also take what's left of bug 800138 and make a Part 4.
Assignee | ||
Comment 27•11 years ago
|
||
Part 3: https://hg.mozilla.org/releases/mozilla-aurora/rev/c1f26b5ca7bd https://hg.mozilla.org/releases/mozilla-beta/rev/6cc72f5e8dc3
Assignee | ||
Comment 28•11 years ago
|
||
This contains the last gecko bits of bug 800138 that haven't been landed as parts of other patches. The gaia PR for bug 800138 will have to land before we can close that bug.
Attachment #687187 -
Flags: review?(past)
Assignee | ||
Comment 29•11 years ago
|
||
Part 4 pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=71dbeb2731c1
Assignee | ||
Comment 30•11 years ago
|
||
Backed out part 3 due to non-B2G bustage: https://hg.mozilla.org/integration/mozilla-inbound/rev/d6529aa77182
Assignee | ||
Comment 31•11 years ago
|
||
(In reply to Jonathan Griffin (:jgriffin) from comment #30) > Backed out part 3 due to non-B2G bustage: > https://hg.mozilla.org/integration/mozilla-inbound/rev/d6529aa77182 Also: https://hg.mozilla.org/releases/mozilla-aurora/rev/77a4e53cc826 https://hg.mozilla.org/releases/mozilla-beta/rev/cae8d0d59cbd
Assignee | ||
Comment 32•11 years ago
|
||
Carry r+ forward. Fix desktop breakage by continuing to load Marionette early in non-B2G platforms. Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=b2a3ab386389 https://tbpl.mozilla.org/?tree=Try&rev=60b37c2de1b5
Attachment #686930 -
Attachment is obsolete: true
Attachment #687284 -
Flags: review+
Comment 33•11 years ago
|
||
Try run for b2a3ab386389 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=b2a3ab386389 Results (out of 4 total builds): success: 4 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jgriffin@mozilla.com-b2a3ab386389
Comment 34•11 years ago
|
||
per aki's mtg w/jgrffin, this is blocking-basecamp, hence nominating.
blocking-basecamp: --- → ?
Updated•11 years ago
|
Attachment #687187 -
Flags: review?(past) → review+
Comment 35•11 years ago
|
||
Try run for 60b37c2de1b5 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=60b37c2de1b5 Results (out of 12 total builds): success: 11 warnings: 1 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jgriffin@mozilla.com-60b37c2de1b5
Updated•11 years ago
|
blocking-basecamp: ? → +
Assignee | ||
Comment 36•11 years ago
|
||
Part 3: https://hg.mozilla.org/integration/mozilla-inbound/rev/1b70ac0124fe Part 4: https://hg.mozilla.org/integration/mozilla-inbound/rev/41be1ff63431
blocking-basecamp: + → ?
Whiteboard: [leave open] → [automation-needed-in-aurora][automation-needed-in-beta][leave open]
Assignee | ||
Comment 37•11 years ago
|
||
(In reply to Jonathan Griffin (:jgriffin) from comment #36) > Part 3: https://hg.mozilla.org/integration/mozilla-inbound/rev/1b70ac0124fe > Part 4: https://hg.mozilla.org/integration/mozilla-inbound/rev/41be1ff63431 I have no idea why this reset the blocking-basecamp flag.
Updated•11 years ago
|
blocking-basecamp: ? → +
Assignee | ||
Comment 38•11 years ago
|
||
aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/f92aed392073 https://hg.mozilla.org/releases/mozilla-aurora/rev/f3c6c6bce22c beta: https://hg.mozilla.org/releases/mozilla-beta/rev/e2c93c571158 https://hg.mozilla.org/releases/mozilla-beta/rev/ef6cedb88804
Comment 39•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/1b70ac0124fe https://hg.mozilla.org/mozilla-central/rev/41be1ff63431
Assignee | ||
Comment 40•11 years ago
|
||
All patches have landed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•11 years ago
|
Whiteboard: [automation-needed-in-aurora][automation-needed-in-beta][leave open]
Updated•11 years ago
|
Updated•2 months ago
|
Product: Testing → Remote Protocol
You need to log in
before you can comment on or make changes to this bug.
Description
•