Attempt to remove the frame script and only use WebChannels for profile injection and symbolication
Categories
(DevTools :: Performance Tools (Profiler/Timeline), enhancement, P3)
Tracking
(firefox96 fixed)
Tracking | Status | |
---|---|---|
firefox96 | --- | fixed |
People
(Reporter: gregtatum, Assigned: mstange)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
We now have a WebChannel available for profiler.firefox.com, we should try and use it for symbolication and for profile injection. This would be more secure, and more maintainable. The question is the speed difference between the two.
Assignee | ||
Comment 1•4 years ago
|
||
This requires work both in the Firefox profiler front-end code, and in the devtools code.
For profile injection, we need to make sure to supply the right profile to the right tab. The user might have captured several profiles in various open tabs. If the user reloads one of these tabs, the WebChannel will re-request the profile.
The WebChannel request supplies the requesting browser
instance. We could have a WeakMap that maps the browser from the opened tab to the profile captured for that tab. We'll just need to have a place to store that state; at the moment, handleWebChannelMessage
is a free function but maybe we'll want to wrap it in some kind of stateful object. And then every time we capture a profile, we register it with that stateful object.
Assignee | ||
Comment 2•4 years ago
|
||
Depends on D121932
Assignee | ||
Comment 3•4 years ago
|
||
The corresponding front-end change is in https://github.com/firefox-devtools/profiler/pull/3482 and will need to land first.
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
This was implemented in https://github.com/firefox-devtools/profiler/pull/3466.
Depends on D121933
Comment 5•3 years ago
|
||
There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:mstange, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Assignee | ||
Comment 6•3 years ago
|
||
I was planning to write a test, to check that reloading an opened profiler tab always has the correct profile. But realistically I am not going to get to that soon. So I think I'll just land this as-is.
The other change that I thought about making was to add some kind of workaround for users who have an old version of the profiler cached in the service worker. But at this point it's been almost 3 months since the front-end added support for the web channel, so I think this concern is alleviated.
Comment 8•3 years ago
|
||
Backed out 3 changesets (Bug 1726281, Bug 1625309) for causing mochitest failures on browser_popup-profiler-states.js.
Backout link
Push with failures
Failure Log
dt2 log
Assignee | ||
Comment 9•3 years ago
|
||
Hmm, seems like I had never pushed this to try...
The failing test makes use of fake-frontend.html which needs to be changed to use the WebChannel instead of the frame script.
Assignee | ||
Comment 10•3 years ago
|
||
Depends on D121933
Assignee | ||
Comment 11•3 years ago
|
||
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/10bdd3f45b4d
https://hg.mozilla.org/mozilla-central/rev/2d78cef7380f
https://hg.mozilla.org/mozilla-central/rev/b52cd8a49ebd
Description
•