Summary: | Web Inspector: Layers visualization shouldn't select on mousedown | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ross Kirsling <ross.kirsling> | ||||||||||||||
Component: | Web Inspector | Assignee: | Ross Kirsling <ross.kirsling> | ||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||
Severity: | Normal | CC: | commit-queue, ews-watchlist, inspector-bugzilla-changes, mattbaker, webkit-bug-importer | ||||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||||
Hardware: | All | ||||||||||||||||
OS: | All | ||||||||||||||||
Attachments: |
|
Description
Ross Kirsling
2018-07-09 16:07:31 PDT
Created attachment 344710 [details]
Patch
Comment on attachment 344710 [details] Patch Attachment 344710 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/8501051 New failing tests: http/tests/security/canvas-remote-read-remote-video-localhost.html Created attachment 344748 [details]
Archive of layout-test-results from ews201 for win-future
The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews201 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Comment on attachment 344710 [details]
Patch
This patch does what the bug describes: it only selects on mouseup, and only when the mouseup and mousedown targets match. However, I was expecting selection to not work *at all* when performing a pan or rotate. Just to clarify, what is the intended behavior?
Created attachment 345023 [details]
Patch
(In reply to Matt Baker from comment #4) > Comment on attachment 344710 [details] > Patch > > This patch does what the bug describes: it only selects on mouseup, and only > when the mouseup and mousedown targets match. However, I was expecting > selection to not work *at all* when performing a pan or rotate. Just to > clarify, what is the intended behavior? Well, that is intentional in the sense that it's a fix that I'd intended to make half a year ago but evidently let slip. 😅 I decided to start there since I thought it might match the spirit of your concern -- the inspiration for that behavior is that of a button, which allows you to move away and back between mousedown and mouseup. To match the specific behavior you mentioned, I've tried adding an extra condition that the mouse position be near-equal before and after. Let me know what you think. :) Created attachment 345045 [details]
Patch
(In reply to Ross Kirsling from comment #6) > To match the specific behavior you mentioned, I've tried adding an extra > condition that the mouse position be near-equal before and after. Let me > know what you think. :) Derp. Realized it's simpler and more accurate to just clear the candidate selection via a one-shot mousemove handler... Comment on attachment 345045 [details] Patch Attachment 345045 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/8540266 New failing tests: http/tests/security/canvas-remote-read-remote-video-localhost.html Created attachment 345049 [details]
Archive of layout-test-results from ews206 for win-future
The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews206 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Comment on attachment 345045 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=345045&action=review Works great! r=me, with a few style suggestions to consider. > Source/WebInspectorUI/UserInterface/Views/Layers3DContentView.js:166 > this._mouse = new THREE.Vector2; Does this really need to be part of the class state? It's only used in _findHoveredLayerGroup, and is recalculated each time. > Source/WebInspectorUI/UserInterface/Views/Layers3DContentView.js:318 > + this._candidateSelection = {layerGroup: this._findHoveredLayerGroup(event)}; Since layerGroup is the only property of _candidateSelection, I'd just store it directly: this._candidateSelection = this._findHoveredLayerGroup(event.offsetX, event.offsetY); > Source/WebInspectorUI/UserInterface/Views/Layers3DContentView.js:342 > + _findHoveredLayerGroup({offsetX, offsetY, target: {width, height}}) I think this method could be cleaned up a bit. Do we really need to pass the width and height from the event object? How about: _findHoveredLayerGroup(offsetX, offsetY) { let canvas = this._renderer.domElement; let x = (offsetX / canvas.offsetWidth) * 2 - 1; let y = -(offsetY / canvas.offsetHeight) * 2 + 1; this._raycaster.setFromCamera(new THREE.Vector2(x, y), this._camera); const recursive = true; let intersects = this._raycaster.intersectObjects(this._scene.children, recursive); return intersects.length ? intersects[0].object.parent : null; } (In reply to Matt Baker from comment #11) > > Source/WebInspectorUI/UserInterface/Views/Layers3DContentView.js:318 > > + this._candidateSelection = {layerGroup: this._findHoveredLayerGroup(event)}; > > Since layerGroup is the only property of _candidateSelection, I'd just store > it directly: > > this._candidateSelection = this._findHoveredLayerGroup(event.offsetX, > event.offsetY); The reason for this one is because I'm distinguishing `{layerGroup: null}` (attempting to deselect by clicking on open space) from `null` (no attempt in progress). Created attachment 345423 [details]
Patch for landing
Comment on attachment 345423 [details] Patch for landing Clearing flags on attachment: 345423 Committed r234021: <https://trac.webkit.org/changeset/234021> All reviewed patches have been landed. Closing bug. |