# STEPS TO REPRODUCE 1. inspect any page 2. create an event breakpoint for any event 3. disable all breakpoints => the event breakpoint icon is still blue, when all "regular" breakpoints turn grey
<rdar://problem/48478193>
Created attachment 363240 [details] Patch
Comment on attachment 363240 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=363240&action=review r=me > Source/WebInspectorUI/UserInterface/Controllers/DOMDebuggerManager.js:63 > + this.addDOMBreakpoint(WI.DOMBreakpoint.fromPayload(payload)); Typically we use `fromPayload` when something is coming from a protocol object. That isn't happening here. This is the opposite of `breakpoint.serializableInfo` so how about calling these `FooBreakpoint.deserialize(...)` of `fromCookie` or `fromStorage`? We have a similar naming convention (deserialize) for objects we serialize to/form Workers.
Comment on attachment 363240 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=363240&action=review >> Source/WebInspectorUI/UserInterface/Controllers/DOMDebuggerManager.js:63 >> + this.addDOMBreakpoint(WI.DOMBreakpoint.fromPayload(payload)); > > Typically we use `fromPayload` when something is coming from a protocol object. That isn't happening here. > > This is the opposite of `breakpoint.serializableInfo` so how about calling these `FooBreakpoint.deserialize(...)` of `fromCookie` or `fromStorage`? > > We have a similar naming convention (deserialize) for objects we serialize to/form Workers. Interesting. I viewed the distinction as `serialize` was for worker-proxy data passing while `fromPayload` was for "construct this type from an object" (the model objects for audits/recordings use `fromPayload` to load from imports/cache, not just backend data). Personally, I'd prefer to have a single channel that goes from an object to a constructor, as we can always provide customization in the form of additional parameters, but for the sake of consistency I'll change this to `deserialize`.
Created attachment 363427 [details] Patch
Created attachment 363428 [details] Patch
The commit-queue encountered the following flaky tests while processing attachment 363427 [details]: media/modern-media-controls/placard-support/placard-support-pip.html bug 195249 (author: graouts@apple.com) The commit-queue is continuing to process your patch.
Comment on attachment 363428 [details] Patch Clearing flags on attachment: 363428 Committed r242318: <https://trac.webkit.org/changeset/242318>
All reviewed patches have been landed. Closing bug.