Add a basic "moz:profiler" module for starting and stopping the profiler
Categories
(Remote Protocol :: WebDriver BiDi, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: canova, Assigned: canova)
References
(Blocks 2 open bugs)
Details
Attachments
(2 files)
This is the bug where we will experiment very basic functionality for "moz:tracing" WebDriver BiDi module.
| Assignee | ||
Comment 1•2 years ago
|
||
Depends on D196161
Updated•2 years ago
|
Updated•2 years ago
|
Comment 2•1 year ago
|
||
Hi Nazim,
Do you plan to resume the work here?
The question about having a moz-specific profiler module popped up during a recent devtools meeting :)
cc :ochameau
| Assignee | ||
Comment 3•1 year ago
|
||
Ah, I had forgotten about this patch. I'm a bit busy with lots of things at the moment, but on the other hand, it's not a big effort to land this. If you can land bug 1868828 it should be easy to rebase and land it after small changes.
It's been a while since I wrote this patch, and looking at it back, I'm not happy with the moz:tracing naming. I think it would be better to rename this module to moz:profiling instead. I think I initially wanted to name it tracing thinking that it's good to keep it similar to CDP. But it doesn't make sense for Firefox.
Other than this, the patch is pretty self contained and small.
Comment 4•1 year ago
|
||
(In reply to Nazım Can Altınova [:canova][:canaltinova on phabricator] from comment #3)
Ah, I had forgotten about this patch. I'm a bit busy with lots of things at the moment, but on the other hand, it's not a big effort to land this. If you can land bug 1868828 it should be easy to rebase and land it after small changes.
It's been a while since I wrote this patch, and looking at it back, I'm not happy with the
moz:tracingnaming. I think it would be better to rename this module tomoz:profilinginstead. I think I initially wanted to name ittracingthinking that it's good to keep it similar to CDP. But it doesn't make sense for Firefox.
Other than this, the patch is pretty self contained and small.
Bug 1868828 is on autoland now, feel free to resume work here. Note that we quickly discussed about the folder structure for vendored modules and it sounds good to keep them under a moz/ subfolder (as you did in your current patch)
| Assignee | ||
Comment 5•1 year ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #4)
Bug 1868828 is on autoland now, feel free to resume work here.
Nice, thanks for working on it!
Note that we quickly discussed about the folder structure for vendored modules and it sounds good to keep them under a moz/ subfolder (as you did in your current patch)
I see, sounds good. So would the path formoz:profiler be remote/webdriver-bidi/modules/root/moz/mozProfiler.sys.mjs or remote/webdriver-bidi/modules/root/moz/profiler.sys.mjs (or uppercase P in profiler?)
Comment 6•1 year ago
|
||
So given that we want to use the profiler with sampling here (as I understand) and not for tracing, lets rename the bug so that it reflects the goal for this bug.
(In reply to Nazım Can Altınova [:canova][:canaltinova on phabricator] from comment #5)
I see, sounds good. So would the path for
moz:profilerberemote/webdriver-bidi/modules/root/moz/mozProfiler.sys.mjsorremote/webdriver-bidi/modules/root/moz/profiler.sys.mjs(or uppercase P in profiler?)
Similar to the other modules it should be remote/webdriver-bidi/modules/root/moz/profiler.sys.mjs. The vendor prefix is already encoded in the folder. But nevertheless it opens a question what should happen if we have two identical module names (one public and one as vendored module). Should we encode the moz prefix in the class name?
Comment 7•1 year ago
|
||
The only requirement from the framework's point of view is to export it as export const profiler. Then internally the module class can be ProfilerModule, MozProfilerModule, etc...
Note that for root/windowglobal modules we don't explicitly call the class eg RootNetworkModule/WindowglobalNetworkModule, but just NetworkModule. So we already have duplicate classnames in that case.
Updated•5 days ago
|
| Assignee | ||
Comment 8•5 days ago
|
||
Adds wdspec tests for the moz:profiler.start and moz:profiler.stop
commands, including:
- Basic start/stop behavior, including stopping the profiler when
it isn't running and calling start/stop multiple times. - Invalid argument tests for all start parameters (entries, interval,
features, threads, context, duration). - NoSuchFrame error when an unknown context id is passed to start.
- Writing a profile to disk via stop({ filePath }), including a
JSON sanity check on the resulting file. - UnknownError when the profile file path cannot be written.
- Invalid argument tests for the stop filePath parameter.
Updated•5 days ago
|
Updated•5 days ago
|
Description
•