Attach browser debugger to tests before they start running

RESOLVED FIXED in Firefox 55

Status

defect
P3
normal
RESOLVED FIXED
6 years ago
11 months ago

People

(Reporter: Gijs, Assigned: jryans)

Tracking

(Blocks 1 bug)

unspecified
Firefox 55
Dependency tree / graph

Firefox Tracking Flags

(firefox55 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Per IRC discussion about bug 895471, ensuring that tests don't run until the browser debugger is fully connected isn't trivial. The current mochitest patch on that bug uses --no-autorun as a clumsy way to ensure this is the case. We should try to come up with something more solid that the test framework can hook into to determine the debugger is ready before proceeding with running tests (automatically, ie without hitting the button).
My idea was to make the debugger server dispatch a Debugger:Resumed DOM event every time ThreadActor.prototype.onResume is called, which would indicate that the browser debugger is attached and ready to debug the test process. Similar to how the Debugger:Shutdown event is currently dispatched from the server on shutdown.

My only worry is if the test harness code that waits for that event is paused until the debugger resumes, in which case we would have to do something more hacky (like maybe setting an expando flag on the chrome window and polling).
Priority: -- → P3
Summary: Flesh out event/interaction between the browser debugger and mochitest(-*) so as to avoid --no-autorun but have debuggable tests → Attach browser debugger to tests before they start running
Comment hidden (mozreview-request)
(Assignee)

Comment 3

2 years ago
It's not obvious to me whether the current patch is really that much better, since you still have to click something (at least on macOS) because of focus issues.  We'll see what Gijs thinks though. :)
(Reporter)

Comment 4

2 years ago
mozreview-review
Comment on attachment 8846688 [details]
Bug 929535 - Use wait-for-jsdebugger with mochitests.

https://reviewboard.mozilla.org/r/119702/#review121542

::: testing/mochitest/runtests.py:2422
(Diff revision 1)
>              if options.immersiveMode:
>                  options.browserArgs.extend(('-firefoxpath', options.app))
>                  options.app = self.immersiveHelperPath
>  
>              if options.jsdebugger:
> -                options.browserArgs.extend(['-jsdebugger'])
> +                options.browserArgs.extend(['--jsdebugger', '--wait-for-jsdebugger'])

Is using two dashes here right? I seem to recall that for some reason only 1 of these works on Windows, or something. Worth checking.
Attachment #8846688 - Flags: review?(gijskruitbosch+bugs) → review+
(Assignee)

Comment 5

2 years ago
mozreview-review-reply
Comment on attachment 8846688 [details]
Bug 929535 - Use wait-for-jsdebugger with mochitests.

https://reviewboard.mozilla.org/r/119702/#review121542

> Is using two dashes here right? I seem to recall that for some reason only 1 of these works on Windows, or something. Worth checking.

Sigh, it seems you are right.  Switched back to single dashes.  (Windows also doesn't print any CLI help either...)
Comment hidden (mozreview-request)
(Assignee)

Updated

2 years ago
Assignee: nobody → jryans
Status: NEW → ASSIGNED

Comment 7

2 years ago
Pushed by jryans@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/b62199ddf0f3
Use wait-for-jsdebugger with mochitests. r=Gijs

Comment 8

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/b62199ddf0f3
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55

Updated

11 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.