Bug 151594 - Web Inspector: support runtime registration of tab type associations
Summary: Web Inspector: support runtime registration of tab type associations
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: BJ Burg
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-11-24 15:36 PST by BJ Burg
Modified: 2015-12-04 11:53 PST (History)
7 users (show)

See Also:


Attachments
Proposed Fix (36.11 KB, patch)
2015-11-24 23:39 PST, BJ Burg
joepeck: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description BJ Burg 2015-11-24 15:36:02 PST
I want to add tabs that only exist in engineering builds. This would be done by putting the relevant models and content views in the Debug/ directory and registering it inside Bootstrap.js. But, the list of tab types is hardcoded. We should make it dynamic.
Comment 1 Radar WebKit Bug Importer 2015-11-24 15:36:16 PST
<rdar://problem/23659417>
Comment 2 BJ Burg 2015-11-24 23:39:50 PST
Created attachment 266146 [details]
Proposed Fix
Comment 3 Joseph Pecoraro 2015-12-02 10:58:25 PST
Comment on attachment 266146 [details]
Proposed Fix

View in context: https://bugs.webkit.org/attachment.cgi?id=266146&action=review

Looks good. r=me

> Source/WebInspectorUI/ChangeLog:10
> +        for debugging purposes. Though the relevant models and views can be
> +        put Debug/ directory to exclude from production builds, there's no

Grammar: "can be put Debug/" needs refinement.

> Source/WebInspectorUI/UserInterface/Base/Main.js:444
> +    return new Set(this._knownTabClassesByType.values());

Maybe this should just return the values and not a set?

> Source/WebInspectorUI/UserInterface/Views/ConsoleTabContentView.js:38
> +    static tabInfo()

Style: We've been putting "static" functions inside a "// Static" block. But I've also considered just dropping that block and putting it above the "// Public" block like the constructor.

> Source/WebInspectorUI/UserInterface/Views/NewTabContentView.js:137
> +        allowedTabClasses.sort(function(a, b) {
> +            return a.tabInfo().title.localeCompare(b.tabInfo().title);
> +        });

Arrow function? foo.sort((a, b) => a.tabInfo().title.localeCompare(b.tabInfo().title))
Comment 4 BJ Burg 2015-12-04 09:31:48 PST
(In reply to comment #3)
> Comment on attachment 266146 [details]
> Proposed Fix
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=266146&action=review
> 
> Looks good. r=me
> 
> > Source/WebInspectorUI/ChangeLog:10
> > +        for debugging purposes. Though the relevant models and views can be
> > +        put Debug/ directory to exclude from production builds, there's no
> 
> Grammar: "can be put Debug/" needs refinement.
> 
> > Source/WebInspectorUI/UserInterface/Base/Main.js:444
> > +    return new Set(this._knownTabClassesByType.values());
> 
> Maybe this should just return the values and not a set?

I want to expose the fact that there are no duplicates as part of the API.

> > Source/WebInspectorUI/UserInterface/Views/ConsoleTabContentView.js:38
> > +    static tabInfo()
> 
> Style: We've been putting "static" functions inside a "// Static" block. But
> I've also considered just dropping that block and putting it above the "//
> Public" block like the constructor.

The block was more useful when we couldn't use the static keyword. I will move this up.

> 
> > Source/WebInspectorUI/UserInterface/Views/NewTabContentView.js:137
> > +        allowedTabClasses.sort(function(a, b) {
> > +            return a.tabInfo().title.localeCompare(b.tabInfo().title);
> > +        });
> 
> Arrow function? foo.sort((a, b) =>
> a.tabInfo().title.localeCompare(b.tabInfo().title))
Comment 5 BJ Burg 2015-12-04 11:53:21 PST
Committed r193432: <http://trac.webkit.org/changeset/193432>