react-three-fiber
react-three-fiber copied to clipboard
pmndrs
prepareRaycaster breaks when using <Html /> from drei
see the original problem here - https://github.com/pmndrs/drei/issues/191#issuecomment-766432113
TLDR - when hovering over an <Html/>, the mouse event is triggered on the underlying <div> instead of the <canvas>.
The proposed solution will check the event.target type, and perform the necessary logic based on the type of the element.
reproduction in v6: https://codesandbox.io/s/r3f-basic-demo-forked-w2mcv?file=/package.json
got the sandbox from a discord PM, the instructions are:
For some reason it doesn't work on first load, but if you comment out the "cytoscape component" and uncomment again it runs properly There's two cameras, one commented out, and one active. You can see from the front perspective clicks register on the graph properly, while from an angle none of the clicks register where they should
i plan on taking a look tonight
the original problem was fixed in v6 (proof: https://codesandbox.io/s/drei-html-mouse-bug-forked-fixed-0h8i9?file=/src/App.js), however there is another problem (edited sandbox based off my last comment): https://codesandbox.io/s/bug-964-5io6k?file=/src/App.js
for me, the <Html/> element doesn't show up until I move the camera, and the onClick handler never gets called when the <Html/> element is clicked. am looking into it
update: toggling distanceFactor option determines if <Html/> is visible on first load
@johnmarinelli I tested toggling distanceFactor in your sandbox and it seems to be visible in Chrome and Safari, but it isn't visible on first load without the distanceFactor in Firefox.
Hope this helps debug the issue.
@njm222 it definitely does, i am primarily using Firefox so that is probably why
@johnmarinelli does this solve it? https://codesandbox.io/s/gracious-proskuriakova-fuodi?file=/src/App.js
@drmcda yes, this version responds to mouse events successfully. was the solution the computeOffsets function or the states.events.connect(fwdRef.current)?
mostly computeOffsets. r3f uses offsetxy, but that's reliant on the target. if you hover a div offsetxy starts at relative zero. with a flip to clientxy it should work. both clientxy and offsetxy have their ups and downs, if we pick one, usecases for the other will fail. imo allowing users to compute offsets is an easy way to fix all possible usecases.
Should we revisit #965 now that events are done? We can pass layout info into the RN canvas shim so the fix will translate over.
