Bug 201539 – Web Inspector: Better position for Sources tab when enabling the experimental setting

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector

[Joseph Pecoraro]

Better position for Sources tab when enabling the experimental setting

It is horrible that the new Sources tab ends up all the way at the end. Let's try to place it where the Debugger tab was.

[Joseph Pecoraro]

Created attachment 378171 [details]
[PATCH] Proposed Fix

[Devin Rousso]

Comment on attachment 378171 [details]
[PATCH] Proposed Fix

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

r=me

> Source/WebInspectorUI/UserInterface/Views/SettingsTabContentView.js:348
>              let newTabs = WI._openTabsSetting.value.slice();

NIT: now that <https://webkit.org/b/17240> added `WI.Setting.prototype.save`, we can avoid this `slice` and instead just forcibly call `WI._openTabsSetting.save()` at the end of this function, right before `InspectorFrontendHost.reopen()`.

> Source/WebInspectorUI/UserInterface/Views/SettingsTabContentView.js:352
> +                    let index = newTabs.indexOf(WI.DebuggerTabContentView.Type);

Rather than look for `WI.DebuggerTabContentVIew` specifically, perhaps we could expose `productionTabClasses` (in `WI.contentLoaded` in Main.js) and use that for ordering (which would also benefit the Layers Tab), since that already has a defined order of where the default tabs should be.

This way, if the user doesn't have the Debugger Tab open, but one of the other "nearby" tabs is open, we'd still add the Sources Tab in the "generally" right place :)

> Source/WebInspectorUI/UserInterface/Views/SettingsTabContentView.js:354
> +                        newTabs.splice(index, 0, WI.SourcesTabContentView.Type);

NIT: `Array.prototype.insertAtIndex`.

[Joseph Pecoraro]

Comment on attachment 378171 [details]
[PATCH] Proposed Fix

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

>> Source/WebInspectorUI/UserInterface/Views/SettingsTabContentView.js:352
>> +                    let index = newTabs.indexOf(WI.DebuggerTabContentView.Type);
> 
> Rather than look for `WI.DebuggerTabContentVIew` specifically, perhaps we could expose `productionTabClasses` (in `WI.contentLoaded` in Main.js) and use that for ordering (which would also benefit the Layers Tab), since that already has a defined order of where the default tabs should be.
> 
> This way, if the user doesn't have the Debugger Tab open, but one of the other "nearby" tabs is open, we'd still add the Sources Tab in the "generally" right place :)

I'm not sure how we would decide to reconcile all cases. So I've simplified to this:
• If the Debugger tab exists, no matter where the user ordered it, use that spot
• If the Debugger tab does not exist, then the user has already shows ability to customized tabs.

In any case, this is a short term solution until we enable it by default!

>> Source/WebInspectorUI/UserInterface/Views/SettingsTabContentView.js:354
>> +                        newTabs.splice(index, 0, WI.SourcesTabContentView.Type);
> 
> NIT: `Array.prototype.insertAtIndex`.

Nice!

[Joseph Pecoraro]

https://trac.webkit.org/changeset/249592/webkit

[Radar WebKit Bug Importer]

<rdar://problem/55127412>