Per https://webkit.org/blog/8262/visualizing-layers-in-web-inspector/: > We might begin by exploring the visualization to understand each layer’s position, size, and rendering order. To navigate, use left-drag to rotate, right-drag to pan, and scroll to zoom. Right-click dragging is very tricky on a trackpad. You have to touch two fingers to the trackpad, click with a third, and move the third without releasing the first two. As such, per macOS conventions, holding down the control key and clicking the trackpad should function as a right-click. Therefore, holding control while dragging should pan the layers wireframe. Bug submitted per recommendation from Ross Kirsling: https://twitter.com/rkirsling/status/990052211479666688
This will be a trivial fix but it's currently blocked by a limitation in three.js' OrbitControls. Rather than fork that module, I'm working on getting it updated: https://github.com/mrdoob/three.js/issues/13970
Created attachment 344132 [details] Patch
Comment on attachment 344132 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=344132&action=review Was is possible to pan before this change? The pull request for three.js mentions right-dragging, but I can't tell what that is. Also I think geometry in the scene shouldn't be selectable when clicking as part of a pan operation. This would cause a user's selection to change when panning to get a better view. r- for now, due to the selection issue. > Source/WebInspectorUI/UserInterface/Views/Layers3DContentView.js:160 > + this._controls.screenSpacePanning = true; I'd like to see a high-level explanation for why the default values for panSpeed and screenSpacePanning aren't used. It looks like screenSpacePanning controls the axes on which the camera pans, and the default is to pan only on the horizontal axis of the plane parallel to the scene. That seems like strange default behavior in any case, but maybe I'm missing something.
(In reply to Matt Baker from comment #3) > Comment on attachment 344132 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=344132&action=review > > Was is possible to pan before this change? The pull request for three.js > mentions right-dragging, but I can't tell what that is. Also I think > geometry in the scene shouldn't be selectable when clicking as part of a pan > operation. This would cause a user's selection to change when panning to get > a better view. r- for now, due to the selection issue. As mentioned on IRC, this part is unchanged from before -- I'd be happy to address it in a subsequent patch, if that's alright? > > Source/WebInspectorUI/UserInterface/Views/Layers3DContentView.js:160 > > + this._controls.screenSpacePanning = true; > > I'd like to see a high-level explanation for why the default values for > panSpeed and screenSpacePanning aren't used. It looks like > screenSpacePanning controls the axes on which the camera pans, and the > default is to pan only on the horizontal axis of the plane parallel to the > scene. That seems like strange default behavior in any case, but maybe I'm > missing something. Both of these fields were introduced in recent releases so I'm just setting them so as to maintain our existing behavior. I'm not really clear on the motivation behind the change in default panning mode (https://github.com/mrdoob/three.js/pull/13242, https://github.com/mrdoob/three.js/pull/13720); we might be able to rework the scene in order to align with the new default but it's doubtful that cost would justify benefit.
Created https://bugs.webkit.org/show_bug.cgi?id=187488 to track the unintentional selection issue.
Comment on attachment 344132 [details] Patch Clearing flags on attachment: 344132 Committed r233695: <https://trac.webkit.org/changeset/233695>
All reviewed patches have been landed. Closing bug.
<rdar://problem/42036967>