Web Inspector: Debugger: DOM, URL, and Event breakpoints don't grey out when all breakpoints are disabled

• Component: Web Inspector
• Status: RESOLVED FIXED

[Devin Rousso]

# 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

[Radar WebKit Bug Importer]

<rdar://problem/48478193>

[Devin Rousso]

Created attachment 363240 [details]
Patch

[Joseph Pecoraro]

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.

[Devin Rousso]

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`.

[Devin Rousso]

Created attachment 363427 [details]
Patch

[Devin Rousso]

Created attachment 363428 [details]
Patch

[WebKit Commit Bot]

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: [e-mail])
The commit-queue is continuing to process your patch.

[WebKit Commit Bot]

Comment on attachment 363428 [details]
Patch

Clearing flags on attachment: 363428

Committed r242318: <https://trac.webkit.org/changeset/242318>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.