Bug 191977

<rdar://problem/46253093>

Created attachment 355667 [details] Patch

Comment on attachment 355667 [details] Patch Attachment 355667 [details] did not pass mac-ews (mac): Output: https://webkit-queues.webkit.org/results/10157964 New failing tests: inspector/table/table-remove-rows.html

Created attachment 355673 [details] Archive of layout-test-results from ews102 for mac-sierra The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews102 Port: mac-sierra Platform: Mac OS X 10.12.6

Comment on attachment 355667 [details] Patch Attachment 355667 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/10157983 New failing tests: inspector/table/table-remove-rows.html

Created attachment 355674 [details] Archive of layout-test-results from ews105 for mac-sierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews105 Port: mac-sierra-wk2 Platform: Mac OS X 10.12.6

Comment on attachment 355667 [details] Patch Attachment 355667 [details] did not pass mac-debug-ews (mac): Output: https://webkit-queues.webkit.org/results/10158190 New failing tests: inspector/table/table-remove-rows.html

Created attachment 355678 [details] Archive of layout-test-results from ews115 for mac-sierra The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews115 Port: mac-sierra Platform: Mac OS X 10.12.6

Comment on attachment 355667 [details] Patch r-. Need to fix Table.prototype._removeRows.

Comment on attachment 355667 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=355667&action=review r-, due to test failures (as discussed offline), and the lack of handling item addition/removal (e.g. `didInsertItem` and `didRemoveItem`) Otherwise, looks good! Was there a reason you decided on going forward with an index-based approach vs an object-based approach, like we discussed before Thanksgiving? I think the object-based approach will be much more flexible for `WI.TreeOutline` and would likely require far less work to implement vs an index-based approach. > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:33 > + this._delegate = delegate; NIT: would this really be considered a delegate? Perhaps "view" or something else like that to better explain that this is the "controlled object"? > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:42 > + console.assert(this._delegate.selectionControllerNextSelectableIndex, "SelectionController delegate must implement selectionControllerNextSelectableIndex."); `selectionControllerPreviousSelectableIndex`? > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:70 > + get lastSelectedItem() { return this._lastSelectedIndex; } > + get selectedItems() { return this._selectedIndexes; } Style: put all one-line getters at the top of the Public section > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:149 > + this._lastSelectedIndex = newSelectedItems.lastIndex; Should we also treat the last index as the anchor for shift-selection? This seems to be how Finder does it. > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:187 > + clear() NIT: I'd prefer `reset`, as `clear` is too similar to "clear selection or "deselect all" in my mind > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:197 > + return false; Is there a reason this function needs to return a boolean? > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:223 > + if (event.commandOrControlKey) { Nice! > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:359 > + let deselectedItems = oldSelectedIndexes.difference(indexes); > + let selectedItems = indexes.difference(oldSelectedIndexes); > + this._delegate.selectionControllerSelectionDidChange(this, deselectedItems, selectedItems); I like this new approach! > Source/WebInspectorUI/UserInterface/Views/Table.js:347 > + if (!oldSelectedItems.equals(this._selectionController.selectedItems)) Why is this check needed? > Source/WebInspectorUI/UserInterface/Views/Table.js:594 > + if (index === this.numberOfRows - 1) NIT: for sanity's sake, we should either add an assert or change this to be a `>=` > Source/WebInspectorUI/UserInterface/Views/Table.js:601 > + if (index === 0) NIT: for sanity's sake, we should either add an assert or change this to be a `<=` > Source/WebInspectorUI/UserInterface/Views/Table.js:1244 > + this._selectionController.handleKeyDown(event); This won't call `revealRow` when moving Up/Down. I think that's an issue if we try to go Up/Down without a previous selection, as the item to select may be outside what's been cached. Perhaps there should be a `selectionControllerRevealIndex` delegate call?

Comment on attachment 355667 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=355667&action=review >> Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:33 >> + this._delegate = delegate; > > NIT: would this really be considered a delegate? Perhaps "view" or something else like that to better explain that this is the "controlled object"? In practice it's a view, but delegate is very general which I like here. >> Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:70 >> + get selectedItems() { return this._selectedIndexes; } > > Style: put all one-line getters at the top of the Public section I'll change it here, but in general I don't think this should be a hard and fast rule. Sometimes it makes sense to group properties semantically. >> Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:149 >> + this._lastSelectedIndex = newSelectedItems.lastIndex; > > Should we also treat the last index as the anchor for shift-selection? This seems to be how Finder does it. Nice observation. In fact, it looks like Finder only does this in the absence of an existing shift-selection anchor; I'll match that behavior. >> Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:187 >> + clear() > > NIT: I'd prefer `reset`, as `clear` is too similar to "clear selection or "deselect all" in my mind `reset` is better. >> Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:197 >> + return false; > > Is there a reason this function needs to return a boolean? There is. TreeOutline will use the return value. I should have added the return value in that patch, but let's just keep this. >> Source/WebInspectorUI/UserInterface/Views/Table.js:1244 >> + this._selectionController.handleKeyDown(event); > > This won't call `revealRow` when moving Up/Down. I think that's an issue if we try to go Up/Down without a previous selection, as the item to select may be outside what's been cached. > > Perhaps there should be a `selectionControllerRevealIndex` delegate call? Great catch. We can resolve this in Table, without extending the delegate: selectionControllerSelectionDidChange(controller, deselectedItems, selectedItems) { if (deselectedItems.size) this._toggleSelectedRowStyle(deselectedItems, false); if (selectedItems.size) this._toggleSelectedRowStyle(selectedItems, true); + if (selectedItems.size === 1) { + let rowIndex = selectedItems.firstIndex; + if (!this._isRowVisible(rowIndex)) + this.revealRow(rowIndex); + } if (this._delegate.tableSelectionDidChange) this._delegate.tableSelectionDidChange(this); }

Created attachment 355735 [details] Patch

(In reply to Devin Rousso from comment #10) > Comment on attachment 355667 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=355667&action=review > > r-, due to test failures (as discussed offline), and the lack of handling > item addition/removal (e.g. `didInsertItem` and `didRemoveItem`) > > Otherwise, looks good! Was there a reason you decided on going forward with > an index-based approach vs an object-based approach, like we discussed > before Thanksgiving? I think the object-based approach will be much more > flexible for `WI.TreeOutline` and would likely require far less work to > implement vs an index-based approach. An object-based approach has the advantage of being slightly simpler, in that `didRemoveItem` and `didInsertItem` aren't needed to keep SelectionController's stored indexes in synch with the view. This has the consequence that the selected items are no longer in order, however, which is an issue for copying rows from Table. The index-based approach was also complete, and I didn't want to rock the boat at the 11th hour. ;)

(In reply to Matt Baker from comment #13) > The index-based approach was also complete, and I didn't want to rock the boat at the 11th hour. ;) No worries! Was just wondering :) I think an object-based approach will be more flexible, but in the spirit of getting things done, this works just as well =D

Comment on attachment 355735 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=355735&action=review > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:42 > + console.assert(this._delegate.selectionControllerNextSelectableIndex, "SelectionController delegate must implement selectionControllerNextSelectableIndex."); `selectionControllerPreviousSelectableIndex`? > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:195 > + didRemoveItem(index) What happened to `didInsertItem`? Don't we need to do effectively the same logic but instead add one to each index? > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:200 > + while (index = this._selectedIndexes.indexGreaterThan(index)) { So this is relying on the falsey nature of `NaN` to return when there is no greater index? > Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:225 > + } There should be a default return value after this.

Created attachment 355747 [details] Patch

Comment on attachment 355735 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=355735&action=review >> Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:195 >> + didRemoveItem(index) > > What happened to `didInsertItem`? Don't we need to do effectively the same logic but instead add one to each index? Individual items aren't inserted into Table, only removed. TreeOutline inserts individual items, so it will be added in https://webkit.org/b/191483. >> Source/WebInspectorUI/UserInterface/Controllers/SelectionController.js:200 >> + while (index = this._selectedIndexes.indexGreaterThan(index)) { > > So this is relying on the falsey nature of `NaN` to return when there is no greater index? Yep.

Comment on attachment 355747 [details] Patch r=me, nice work :)

Comment on attachment 355747 [details] Patch Clearing flags on attachment: 355747 Committed r238563: <https://trac.webkit.org/changeset/238563>

All reviewed patches have been landed. Closing bug.