Closed
Bug 1437828
Opened 7 years ago
Closed 7 years ago
Switch devtools to async/await from Task.jsm/yield in devtools/server
Categories
(DevTools :: General, enhancement)
DevTools
General
Tracking
(firefox60 fixed)
RESOLVED
FIXED
Firefox 60
Tracking | Status | |
---|---|---|
firefox60 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Depends on 1 open bug)
Details
Attachments
(1 file, 8 obsolete files)
Bug 1353542 rewrote Task.jsm for the whole browser/ folder.
Bug 1365607 intend to do that for the whole devtools/ folder,
but I would like to first start with devtools/server/ as this rewrite isn't that easy and would be easier to do independently.
The patches are going to be based on top of Promise.jsm removal for devtools/server in bug 1436978
Assignee | ||
Comment 1•7 years ago
|
||
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → poirot.alex
Assignee | ||
Comment 2•7 years ago
|
||
New try run after rebase:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=960a0fcad499211da542c245dd6b03a2856b6d42
Note that I had to pull out modification made to devtools/server/tests/mochitest/test_memory_allocations_01.html as this particular test starts failure for obscure reasons when refactoring it to async/await. I opened bug 1438121 for its refactoring.
Also note that I attached the xpcshell script I used to generate the two first changesets. But I don't intend to land it.
I fixed it to make it work with today's m-c (it was throwing) but I haven't made any modification to its logic.
This script comes from Florian in bug 1353542.
I intend to merge all of these changesets into a single one and strip command details I added in these individual changesets.
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 13•7 years ago
|
||
mozreview-review |
Comment on attachment 8950863 [details]
Bug 1437828 - Convert Task.jsm to async/await in devtools/server.
https://reviewboard.mozilla.org/r/220100/#review226114
Thanks for working on this! I only skimmed it, but it looks reasonable, and I've successfully used a similar script for RDM.
Attachment #8950863 -
Flags: review?(jryans) → review+
Comment 14•7 years ago
|
||
mozreview-review |
Comment on attachment 8950864 [details]
Bug 1437828 - Convert generators to sync functions in devtools/server/tests
https://reviewboard.mozilla.org/r/220102/#review226118
Thanks, looks good! :)
Attachment #8950864 -
Flags: review?(jryans) → review+
Assignee | ||
Comment 15•7 years ago
|
||
I have one blocker left: devtools/client/framework/test/browser_browser_toolbox_debugger.js fails with:
A promise chain failed to handle a rejection: eventLoop is undefined - stack: enter@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/utils/event-loop.js:118:5 _pushThreadPause@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/thread.js:180:5
At first sight, the test doesn't cleanup itself correctly (do not remove the breakpoint before closing, while the breakpoint is hit during closing)
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Assignee | ||
Comment 19•7 years ago
|
||
Two more patches to try to address debugger test failure.
The first first isn't directly related but only helps testing the file locally.
The second should, ideally, fix the intermittent visible on try.
New try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c73dab2a31a80356a7e950aec6fdadb7c6873559
Comment 20•7 years ago
|
||
mozreview-review |
Comment on attachment 8950865 [details]
Bug 1437828 - manual fixes.
https://reviewboard.mozilla.org/r/220104/#review226138
::: devtools/server/tests/mochitest/test_memory_gc_01.html:35
(Diff revision 1)
> o[Math.random()] = 1;
> objects.push(o);
> }
> objects = null;
>
> - await { total: beforeGC } = memory.measure();
> + beforeGC = (await memory.measure()).total;
Wow, I am really surprised by the original yield version of this...! I wouldn't have expected it work as written... This cleanup makes it more obvious, so good to see!
Attachment #8950865 -
Flags: review?(jryans) → review+
Comment 21•7 years ago
|
||
mozreview-review |
Comment on attachment 8950866 [details]
Bug 1437828 - Put spaces before parentheses in "async function()" pattern.
https://reviewboard.mozilla.org/r/220106/#review226140
Attachment #8950866 -
Flags: review?(jryans) → review+
Comment 22•7 years ago
|
||
mozreview-review |
Comment on attachment 8950867 [details]
Bug 1437828 - Manual eslint fix.
https://reviewboard.mozilla.org/r/220108/#review226144
::: devtools/server/tests/unit/test_sourcemaps-16.js:25
(Diff revision 1)
> });
> do_test_pending();
> }
>
> -const testSourcemap = async function (threadResponse, tabClient, threadClient, tabResponse) {
> +const testSourcemap = async function (threadResponse, tabClient, threadClient,
> + tabResponse) {
Hmm, do we have a standard for wrapping params that take more than one line? It's a bit strange to see the next line of params take up the same column as the first line of function body, with no separation between them...
Rust uses the style:
```
const testSourcemap = async function (
threadResponse,
tabClient,
threadClient,
tabResponse
) {
```
for long parameter lists (example[1]). Maybe it's reasonable for JS as well?
[1]: https://searchfox.org/mozilla-central/rev/d03ad8843e3bf2e856126bc53b0475c595e5183b/servo/components/style/style_resolver.rs#182
Attachment #8950867 -
Flags: review?(jryans) → review+
Comment 23•7 years ago
|
||
Regarding long parameter list, I'm quite sure this is what prettier does.
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 26•7 years ago
|
||
mozreview-review |
Comment on attachment 8950868 [details]
Bug 1437828 - Get rid of the now useless require("devtools/shared/task").
https://reviewboard.mozilla.org/r/220110/#review226146
::: devtools/server/tests/mochitest/test_memory_allocations_01.html:19
(Diff revision 1)
> <script src="memory-helpers.js" type="application/javascript"></script>
> <script>
> "use strict";
>
> window.onload = function () {
> + let { Task } = require("devtools/shared/task");
Why can't this test be converted to async / await? It's not obvious to me on the first read...
Attachment #8950868 -
Flags: review?(jryans) → review+
Comment hidden (obsolete) |
Comment 28•7 years ago
|
||
mozreview-review |
Comment on attachment 8951000 [details]
Bug 1437828 - Allows running brower_browser_toolbox_debugger.js more than once.
https://reviewboard.mozilla.org/r/220258/#review226168
Is this test issue related to async / await conversion? It seems a bit random to me... Assuming it is related, I'd like to know if `nukeSandbox` helps instead.
::: commit-message-371dc:1
(Diff revision 1)
> +Bug 1437828 - Allows running brower_browser_toolbox_debugger.js more than once. r=jryans
Nit: brower -> browser
::: devtools/client/framework/test/browser_browser_toolbox_debugger.js:40
(Diff revision 1)
> +
> + // Use a unique id for the fake script name in order to be able to run
> + // this test more than once. That's because the Sandbox is not immediately
> + // destroyed and so the debugger would display only one file but not necessarily
> + // connected to the latest sandbox.
> + let id = new Date().getTime();
Hmm, could we use `Cu.nukeSandbox` at the end of the test instead of this ID?
Attachment #8951000 -
Flags: review?(jryans) → review-
Comment 29•7 years ago
|
||
mozreview-review |
Comment on attachment 8951001 [details]
Bug 1437828 - Fix race during test shutdown in browser_browser_toolbox_debugger.js.
https://reviewboard.mozilla.org/r/220260/#review226178
Well, it seems good overall, but again, I am not sure I follow how this test is directly related to async / await conversion...
Attachment #8951001 -
Flags: review?(jryans) → review+
Comment 30•7 years ago
|
||
mozreview-review-reply |
Comment on attachment 8950868 [details]
Bug 1437828 - Get rid of the now useless require("devtools/shared/task").
https://reviewboard.mozilla.org/r/220110/#review226146
> Why can't this test be converted to async / await? It's not obvious to me on the first read...
Ah, this is the one about stack frames in bug 1438121. Thanks!
Assignee | ||
Comment 31•7 years ago
|
||
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #28)
> Comment on attachment 8951000 [details]
> Bug 1437828 - Allows running brower_browser_toolbox_debugger.js more than
> once.
>
> https://reviewboard.mozilla.org/r/220258/#review226168
>
> Is this test issue related to async / await conversion?
The test start failing because of async/await.
But this particular modification is unrelated, it just allow running it multiple times with --repeat.
That helps reproducing the intermittent failure that try has.
> It seems a bit random to me... Assuming it is related, I'd like to know if `nukeSandbox`
> helps instead.
I tried many things before coming up with the ID.
nukeSandbox is enough.
I tried "nukeSandbox + nullify + forceGC + forceCC" but it is still rarely fail to clean it up completely.
The most effective of all this was nullify + forceGC, I wasn't sure about utility of others.
I could move that particular changeset in another bug as it isn't necessary to land the task refactoring.
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #29)
> Comment on attachment 8951001 [details]
> Bug 1437828 - Fix race during test shutdown in
> browser_browser_toolbox_debugger.js.
>
> https://reviewboard.mozilla.org/r/220260/#review226178
>
> Well, it seems good overall, but again, I am not sure I follow how this test
> is directly related to async / await conversion...
The switch to async/await somehow changed the timing of breakpoint hit codepath -or- debugger/toolbox closing codepath.
I haven't tried to narrow down to what particular Task.jsm removal led to this test failure.
But I just found a recent intermittent with the same stack, bug 1438174. This patch should fix it.
It may be Promise.jsm and Task.jsm slightly changing the timings altogether.
Do you think I should investigate that more before landing?
(In reply to Alexandre Poirot [:ochameau] from comment #31)
> (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #28)
> > Comment on attachment 8951000 [details]
> > Bug 1437828 - Allows running brower_browser_toolbox_debugger.js more than
> > once.
> >
> > https://reviewboard.mozilla.org/r/220258/#review226168
> >
> > Is this test issue related to async / await conversion?
>
> The test start failing because of async/await.
> But this particular modification is unrelated, it just allow running it
> multiple times with --repeat.
> That helps reproducing the intermittent failure that try has.
Okay, I agree in general it's good to support that workflow!
> > It seems a bit random to me... Assuming it is related, I'd like to know if `nukeSandbox`
> > helps instead.
>
> I tried many things before coming up with the ID.
> nukeSandbox is enough.
> I tried "nukeSandbox + nullify + forceGC + forceCC" but it is still rarely
> fail to clean it up completely.
> The most effective of all this was nullify + forceGC, I wasn't sure about
> utility of others.
>
> I could move that particular changeset in another bug as it isn't necessary
> to land the task refactoring.
Hmm, interesting... Good to see you're trying all the tricks. :) I guess the ID approach is okay then, since that's probably more obvious to readers than various nuking and GC commands.
Yes, let's move it to a separate bug assuming it's not need to land task like you said, since this work is already quite large on its own.
> (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #29)
> > Comment on attachment 8951001 [details]
> > Bug 1437828 - Fix race during test shutdown in
> > browser_browser_toolbox_debugger.js.
> >
> > https://reviewboard.mozilla.org/r/220260/#review226178
> >
> > Well, it seems good overall, but again, I am not sure I follow how this test
> > is directly related to async / await conversion...
>
> The switch to async/await somehow changed the timing of breakpoint hit
> codepath -or- debugger/toolbox closing codepath.
> I haven't tried to narrow down to what particular Task.jsm removal led to
> this test failure.
> But I just found a recent intermittent with the same stack, bug 1438174.
> This patch should fix it.
> It may be Promise.jsm and Task.jsm slightly changing the timings altogether.
> Do you think I should investigate that more before landing?
Okay, well, it seems like a reasonable change to the test. I am okay with it given this explanation. Perhaps add some of this to the commit message? I leave it to you to decide if more investigation seems needed. :)
Comment hidden (mozreview-request) |
Assignee | ||
Updated•7 years ago
|
Attachment #8950864 -
Attachment is obsolete: true
Assignee | ||
Updated•7 years ago
|
Attachment #8950865 -
Attachment is obsolete: true
Assignee | ||
Updated•7 years ago
|
Attachment #8950866 -
Attachment is obsolete: true
Assignee | ||
Updated•7 years ago
|
Attachment #8950867 -
Attachment is obsolete: true
Assignee | ||
Updated•7 years ago
|
Attachment #8950868 -
Attachment is obsolete: true
Assignee | ||
Updated•7 years ago
|
Attachment #8951000 -
Attachment is obsolete: true
Assignee | ||
Updated•7 years ago
|
Attachment #8951001 -
Attachment is obsolete: true
Assignee | ||
Updated•7 years ago
|
Attachment #8950869 -
Attachment is obsolete: true
Assignee | ||
Comment 34•7 years ago
|
||
One last try, with all the changeset squashed into just one:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=3cacd69d59af70219ef089e54c77be3bc65b0dd3
This bug now depends on bug 1438508 which depends on bug 1438174.
Comment 35•7 years ago
|
||
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3b06c176e18d
Convert Task.jsm to async/await in devtools/server. r=jryans
Comment 36•7 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox60:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 60
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•