Conversation
Extension IDs are embedded in Text marker strings, so sanitization requires marker name-specific parsing. Structured extension marker payloads make the sensitive fields explicit and remove this special case.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6314 +/- ##
==========================================
+ Coverage 83.84% 83.90% +0.06%
==========================================
Files 352 353 +1
Lines 37807 37982 +175
Branches 10674 10718 +44
==========================================
+ Hits 31698 31870 +172
- Misses 5679 5683 +4
+ Partials 430 429 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| }; | ||
|
|
||
| export type ExtensionMarkerPayload = { | ||
| type: 'ExtensionParent' | 'ExtensionChild' | 'ExtensionSuspend'; |
There was a problem hiding this comment.
Is there a specific reason to use 3 different names for the marker type? If the structure is the same we should use a single name. This will allow us to use a single struct inside Firefox later.
| tableLabel: | ||
| "{marker.data.extensionId}{marker.data.extensionId ? ', ' : ''}{marker.data.name}", | ||
| chartLabel: | ||
| "{marker.name} — {marker.data.extensionId}{marker.data.extensionId ? ', ' : ''}{marker.data.name}", |
There was a problem hiding this comment.
Let's remove {marker.name} - from chartLabel. It doesn't add a lot of value there as we can already see the name easily on the left side of the marker chart.
| }, | ||
| ]; | ||
|
|
||
| export const extensionMarkerSchemas: MarkerSchema[] = [ |
There was a problem hiding this comment.
Similar to the comment I added in the types, we can reduce them into a single schema.
2 participants
Main | Deploy preview
Extension IDs are embedded in Text marker strings, so sanitization requires marker name-specific parsing. Structured extension marker payloads make the sensitive fields explicit and remove this special case.
Follow-up of #6291
Profile