RESOLVED FIXED Bug 162759
Web Inspector: Clicking twice on the color swatch square should hide the color picker
https://bugs.webkit.org/show_bug.cgi?id=162759
Summary Web Inspector: Clicking twice on the color swatch square should hide the colo...
Nikita Vasilyev
Reported 2016-09-29 15:34:33 PDT
Created attachment 290256 [details] [Image] Bug Steps: 1. Add "background: white" inline style. 2. Click on the color swatch square before "white". 3. Click there again. Actual: The color picker hides and shows immediately again, which isn't particularly useful. Expected: The color picker hides. This is how it works in Chrome DevTools and Firefox DevTools.
Attachments
[Image] Bug (303.24 KB, image/gif)
2016-09-29 15:34 PDT, Nikita Vasilyev
no flags
Patch (3.87 KB, patch)
2016-09-29 17:26 PDT, Devin Rousso
no flags
Archive of layout-test-results from ews100 for mac-yosemite (1.06 MB, application/zip)
2016-09-29 18:12 PDT, Build Bot
no flags
Archive of layout-test-results from ews106 for mac-yosemite-wk2 (950.12 KB, application/zip)
2016-09-29 18:24 PDT, Build Bot
no flags
Patch (3.25 KB, patch)
2016-10-01 23:40 PDT, Devin Rousso
mattbaker: review+
Patch (3.09 KB, patch)
2016-10-02 22:13 PDT, Devin Rousso
commit-queue: commit-queue-
Patch (3.09 KB, patch)
2016-10-02 22:15 PDT, Devin Rousso
no flags
Radar WebKit Bug Importer
Comment 1 2016-09-29 15:34:56 PDT
Devin Rousso
Comment 2 2016-09-29 17:26:55 PDT
Build Bot
Comment 3 2016-09-29 18:12:15 PDT
Comment on attachment 290270 [details] Patch Attachment 290270 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/2171636 New failing tests: transitions/default-timing-function.html
Build Bot
Comment 4 2016-09-29 18:12:18 PDT
Created attachment 290275 [details] Archive of layout-test-results from ews100 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews100 Port: mac-yosemite Platform: Mac OS X 10.10.5
Build Bot
Comment 5 2016-09-29 18:23:58 PDT
Comment on attachment 290270 [details] Patch Attachment 290270 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/2171684 New failing tests: fast/images/pixel-crack-image-background-webkit-transform-scale.html
Build Bot
Comment 6 2016-09-29 18:24:01 PDT
Created attachment 290280 [details] Archive of layout-test-results from ews106 for mac-yosemite-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews106 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
Nikita Vasilyev
Comment 7 2016-09-30 12:12:00 PDT
Comment on attachment 290270 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=290270&action=review > Source/WebInspectorUI/UserInterface/Views/InlineSwatch.js:65 > + this._ignoreNextClick = false; _isColorPickerActive or _isPopoverVisible. > Source/WebInspectorUI/UserInterface/Views/Popover.js:167 > + this.delegate.beforeDismissPopover(event); We already have willDismissPopover and didDismissPopover. Why don't use those?
Devin Rousso
Comment 8 2016-09-30 16:39:11 PDT
Comment on attachment 290270 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=290270&action=review >> Source/WebInspectorUI/UserInterface/Views/InlineSwatch.js:65 >> + this._ignoreNextClick = false; > > _isColorPickerActive or _isPopoverVisible. Good call. >> Source/WebInspectorUI/UserInterface/Views/Popover.js:167 >> + this.delegate.beforeDismissPopover(event); > > We already have willDismissPopover and didDismissPopover. Why don't use those? The simplest way I found of fixing this issue was to compare the targets of the `click` event for the popover and the `click` event of the swatch. I was thinking that didDismissPopover wouldn't work because it doesn't (currently) have access to the event that caused the dismiss to happen (this defaults to `mousedown` and `scroll`). It would be possible to use willDismissPopover, but it would require adding an `event` parameter to WI.Popover.prototype.dismiss that would let us pass in the event object, and that doesn't really seem like the right approach.
Nikita Vasilyev
Comment 9 2016-10-01 11:43:45 PDT
Comment on attachment 290270 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=290270&action=review > Source/WebInspectorUI/UserInterface/Views/InlineSwatch.js:138 > + } It should go after... > Source/WebInspectorUI/UserInterface/Views/InlineSwatch.js:142 > if (this._type === WebInspector.InlineSwatch.Type.Color && event.shiftKey && this._value) { this if block. Shift-Click should switch color format regardless of popover visibility. r- because of that. >>> Source/WebInspectorUI/UserInterface/Views/Popover.js:167 >>> + this.delegate.beforeDismissPopover(event); >> >> We already have willDismissPopover and didDismissPopover. Why don't use those? > > The simplest way I found of fixing this issue was to compare the targets of the `click` event for the popover and the `click` event of the swatch. I was thinking that didDismissPopover wouldn't work because it doesn't (currently) have access to the event that caused the dismiss to happen (this defaults to `mousedown` and `scroll`). It would be possible to use willDismissPopover, but it would require adding an `event` parameter to WI.Popover.prototype.dismiss that would let us pass in the event object, and that doesn't really seem like the right approach. I see. This seems a bit overly complicated but I don't know how to make it better.
Matt Baker
Comment 10 2016-10-01 17:37:27 PDT
If the popover delegate had a didPresentPover method, InlineSwatch could remove the swatch element event listener when the popover is shown, and add it in didDismissPopover.
Devin Rousso
Comment 11 2016-10-01 23:40:56 PDT
Matt Baker
Comment 12 2016-10-02 21:37:07 PDT
Comment on attachment 290464 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=290464&action=review r=me > Source/WebInspectorUI/UserInterface/Views/InlineSwatch.js:88 > + // Delegate functions for Popover (Protected) This comment should just be "// Popover delegate", to match the other delegate section comments (there are only 24, but they are consistently named).
Devin Rousso
Comment 13 2016-10-02 22:13:07 PDT
WebKit Commit Bot
Comment 14 2016-10-02 22:13:56 PDT
Comment on attachment 290479 [details] Patch Rejecting attachment 290479 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'validate-changelog', '--check-oops', '--non-interactive', 290479, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit ChangeLog entry in Source/WebInspectorUI/ChangeLog contains OOPS!. Full output: http://webkit-queues.webkit.org/results/2206111
Devin Rousso
Comment 15 2016-10-02 22:15:37 PDT
WebKit Commit Bot
Comment 16 2016-10-02 22:47:41 PDT
Comment on attachment 290480 [details] Patch Clearing flags on attachment: 290480 Committed r206729: <http://trac.webkit.org/changeset/206729>
WebKit Commit Bot
Comment 17 2016-10-02 22:47:47 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.