Closed Bug 1625309 Opened 5 years ago Closed 3 years ago

Attempt to remove the frame script and only use WebChannels for profile injection and symbolication

Categories

(DevTools :: Performance Tools (Profiler/Timeline), enhancement, P3)

enhancement

Tracking

(firefox96 fixed)

RESOLVED FIXED
96 Branch
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.

Blocks: 1677490

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.

The corresponding front-end change is in https://github.com/firefox-devtools/profiler/pull/3482 and will need to land first.

Assignee: nobody → mstange.moz
Attachment #9234994 - Attachment description: WIP: Bug 1625309 - Remove the frame script and instead use the WebChannel to expose the profile and symbolication. → Bug 1625309 - Remove the frame script and instead use the WebChannel to expose the profile and symbolication. r=julienw
Status: NEW → ASSIGNED
Blocks: 1726281

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.

Flags: needinfo?(mstange.moz)
Flags: needinfo?(felash)
Flags: needinfo?(felash)

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.

Flags: needinfo?(mstange.moz)
Pushed by mstange@themasta.com: https://hg.mozilla.org/integration/autoland/rev/801a44944072 Remove the frame script and instead use the WebChannel to expose the profile and symbolication. r=julienw https://hg.mozilla.org/integration/autoland/rev/9ad8265a7c22 Use /from-browser. r=julienw

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

Flags: needinfo?(mstange.moz)

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.

Flags: needinfo?(mstange.moz)
Pushed by mstange@themasta.com: https://hg.mozilla.org/integration/autoland/rev/10bdd3f45b4d Remove the frame script and instead use the WebChannel to expose the profile and symbolication. r=julienw https://hg.mozilla.org/integration/autoland/rev/2d78cef7380f Make fake-frontend.html work with the WebChannel. r=julienw https://hg.mozilla.org/integration/autoland/rev/b52cd8a49ebd Use /from-browser. r=julienw
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: