Bug 159646

Summary: REGRESSION (r195456): Web Inspector: Changing tabs in Styles sidebar shouldn't change sidebar's width
Product: WebKit Reporter: Nikita Vasilyev <nvasilyev>
Component: Web InspectorAssignee: Nikita Vasilyev <nvasilyev>
Status: RESOLVED FIXED    
Severity: Normal CC: bburg, commit-queue, hi, joepeck, mattbaker, nvasilyev, timothy, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
[Animated GIF] Bug
none
WIP
nvasilyev: review-, nvasilyev: commit-queue-
Patch
bburg: review+, bburg: commit-queue-
Patch none

Nikita Vasilyev
Reported 2016-07-11 14:47:15 PDT
Created attachment 283347 [details] [Animated GIF] Bug Steps: 1. Open Elements tab 2. Select Styles tab in the right sidebar 3. Make the sidebar wider 4. Select the Node tab Expected: The sidebar didn't change its width after selecting the Node tab. Actual: The sidebar changed its width to the previous width of the Node tab.
Attachments
[Animated GIF] Bug (55.33 KB, image/gif)
2016-07-11 14:47 PDT, Nikita Vasilyev
no flags
WIP (4.86 KB, patch)
2016-07-26 14:41 PDT, Nikita Vasilyev
nvasilyev: review-
nvasilyev: commit-queue-
Patch (8.73 KB, patch)
2016-07-26 15:24 PDT, Nikita Vasilyev
bburg: review+
bburg: commit-queue-
Patch (8.84 KB, patch)
2016-07-29 11:47 PDT, Nikita Vasilyev
no flags
Radar WebKit Bug Importer
Comment 1 2016-07-11 14:47:32 PDT
Joseph Pecoraro
Comment 2 2016-07-11 16:27:15 PDT
+1 I just ran into this the other day and it was annoying.
Matt Baker
Comment 3 2016-07-11 17:02:52 PDT
+1 This was bugging me over the weekend!
Devin Rousso
Comment 4 2016-07-12 21:29:15 PDT
I think this has to do with the fact each of the `detailsSidebarPanels` inside `WebInspector.ElementsTabContentView` have separate `savedWidth` values (which comes froma `WebInspector.Setting` object) via `WebInspector.SidebarPanel`. Since Nodes, Styles, and Layers are all considered separated sidebars (and this problem may exist anywhere that multiple sidebar panels are used, like the Resource and Scope Chain), the best solution may be to add some logic to `WebInspector.TabContentView` or `WebInspector.Sidebar` (since that is the "controller" that maintains all of the added sidebars),
Nikita Vasilyev
Comment 5 2016-07-19 14:30:26 PDT
Nikita Vasilyev
Comment 6 2016-07-19 16:15:33 PDT
1. Sidebar panels should NOT remember their width, Sidebar should. Node, Styles, and Layers should all have the same width, which isn't currently the case. 2. However, sidebar width should be uniq for each tab. Changing sidebar width in Elements shouldn't change sidebar width in Resources. If we agree on these two points, I think it makes sense to make sidebar a subview of TabContentView. Currently, sidebars are global (WebInspector.detailsSidebar and WebInspector.navigationSidebar). If we make them local per tab, we can store their width in, say, WebInspector.Sidebar#_widthSetting.
Timothy Hatcher
Comment 7 2016-07-20 08:26:55 PDT
(In reply to comment #6) > 1. Sidebar panels should NOT remember their width, Sidebar should. Node, > Styles, and Layers should all have the same width, which isn't currently the > case. > > 2. However, sidebar width should be uniq for each tab. Changing sidebar > width in Elements shouldn't change sidebar width in Resources. > > If we agree on these two points, I think it makes sense to make sidebar a > subview of TabContentView. Currently, sidebars are global > (WebInspector.detailsSidebar and WebInspector.navigationSidebar). If we make > them local per tab, we can store their width in, say, > WebInspector.Sidebar#_widthSetting. I agree with those points, but Sidebar needs to be global because of the way it lays out in relation to the quick console. Managing the width changes per tab can be done by TabBrowser.js. It already does things like this when the tab changes: this._navigationSidebar.collapsed = tabContentView.navigationSidebarCollapsedSetting.value;
Nikita Vasilyev
Comment 8 2016-07-26 14:41:39 PDT
Nikita Vasilyev
Comment 9 2016-07-26 15:24:57 PDT
Blaze Burg
Comment 10 2016-07-29 10:56:49 PDT
Comment on attachment 284645 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=284645&action=review r=me with comments > Source/WebInspectorUI/ChangeLog:12 > + Please explain that TabContentView stores the width but TabBrowser manages saving and restoring it. This is weird so we should point it out. > Source/WebInspectorUI/UserInterface/Views/Sidebar.js:268 > + this.element.style.width = newWidth + "px"; Nit: prefer = `${newWidth}px`. This change does not seem relevant to the patch. > Source/WebInspectorUI/UserInterface/Views/Sidebar.js:276 > + this.dispatchEventToListeners(WebInspector.Sidebar.Event.WidthDidChange, {newWidth: newWidth}); Nit: just {newWidth} will work. > Source/WebInspectorUI/UserInterface/Views/TabBrowser.js:284 > + var tabContentView = this.selectedTabContentView; Nit: let > Source/WebInspectorUI/UserInterface/Views/TabBrowser.js:340 > + if (tabContentView.detailsSidebarWidthSetting.value !== 0) What's up with this conditional? Do we really want to allow this._detailsSidebar.width to be undefined, false, or null? I think you can just drop the !== 0. > Source/WebInspectorUI/UserInterface/Views/TabContentView.js:181 > + get detailsSidebarWidthSetting() This seems awkward IMO, but I don't think we are going to change it now. Carry on.
Nikita Vasilyev
Comment 11 2016-07-29 11:47:25 PDT
WebKit Commit Bot
Comment 12 2016-07-29 11:59:38 PDT
Comment on attachment 284879 [details] Patch Clearing flags on attachment: 284879 Committed r203912: <http://trac.webkit.org/changeset/203912>
WebKit Commit Bot
Comment 13 2016-07-29 11:59:43 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.