Change the 'is-ready' postMessage pairs to 'ready:request' and 'ready:response' to be more explicit #5148
Conversation
canova
force-pushed
the
postmessage-infinite-loop
branch
from
90370e5 to
76f7e78
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5148 +/- ##
=======================================
Coverage 88.56% 88.56%
=======================================
Files 307 307
Lines 27936 27936
Branches 7560 7560
=======================================
+ Hits 24741 24742 +1
+ Misses 2978 2977 -1
Partials 217 217 ☔ View full report in Codecov by Sentry. |
|
Ideally i'd use |
|
I will need to change https://github.com/fqueze/usb-power-profiling/blob/main/index.html#L361 too. |
|
I've been afk for personal stuff these last few weeks, I can look at this soon, but feel free to merge without me. |
|
Please change it to what makes most sense for the cleanest implementation, and I can easily update the message name when you merge. Mine's easy to change. |
canova
force-pushed
the
postmessage-infinite-loop
branch
from
76f7e78 to
73a8972
Compare
canova
changed the title
|
Thanks for the feedback @gregtatum! And thanks for the suggestion @julienw on the message names. I updated the PR and changed the Please let me know what you think! |
…:response' to be more explicit
canova
force-pushed
the
postmessage-infinite-loop
branch
from
73a8972 to
0d38aa6
Compare
|
Note that I'm deploying in a bit today. So we would need to update the places where we use this message. |
[Markus Stange] Fix links to setup-startup-profiling.py post monorepo migration. (#5162) [Greg Tatum] Fix marker-only compare profiles (#5130) [Greg Tatum] Copy over the profile meta when merging profiles (#5131) [Nazım Can Altınova] Change the 'is-ready' postMessage pairs to 'ready:request' and 'ready:response' to be more explicit (#5148) [Julien Wajsberg] Fix timestamp issues in local tests (#5167) Also thanks to our localizers for contributing: fur: Fabio Tomat
This is changed in firefox-devtools/profiler#5148. Previously we were using 'is-ready' for both the request and the response. Now we are using two distinct messages on both for clarity.
This is changed in firefox-devtools/profiler#5148. Previously we were using 'is-ready' for both the request and the response. Now we are using two distinct messages on both for clarity.
…API (#8) This is changed in firefox-devtools/profiler#5148. Previously we were using 'is-ready' for both the request and the response. Now we are using two distinct messages on both for clarity.
Edit after updating the PR:
I have changed the postMessage names directly now to
'ready:request'and'ready:response'to be more explicit.Before update:
This changes the
is-readymessage handling that comes frompostMessage. I needed this for a Chrome extension I was working on. But in their extension API you have to be in the samewindowwhile sending this message. That's why whenis-readyreturns a message with the same name to itself, it creates an infinite loop. I changed the name fromis-readytoreadywhen notifying the profiler is ready.@gregtatum I wanted to get your feedback since you implemented this feature initially for your work. I would prefer to always send
readyinstead ofis-readybut that would probably break your use case. So that's why I went with a non-breaking usage where I check if the windows are the same and if so, send a message with a different name. Let me know what you think!