The warning occurs the first time x21 and y21 both are 0 (so it is a divide by zero error).

A simple way fix it is to change the code to something like:

    if x21 != 0 or y21 != 0:
        u = (x01*x21 + y01*y21) / (x21**2 + y21**2)
        u = np.clip(u, 0, 1)
    else:
        u = 0   # Actually doesn't matter since it will be multiplied by zero anyway...

although the preferred syntax may differ.

thanks @oscargus fror your reply
there is this other possibility :

with np.errstate(divide='ignore'):
    u = (x01*x21 + y01*y21) / (x21**2 + y21**2)

Whatever, I think one of this bugfix should be push in the next release.
Could you please be in charge of that ?
Thanks,
Patrick

Seems like one should use invalid='ignore' as although there is a division by zero, the actual warning is "Invalid..." (probably because it is 0/0). For now, I went with my approach (as I didn't figure out the answer above until after pushing it...), but we'll see what the review leads to.

The warning is triggered when trying to get xyz coordinates for the mouse cursor and one of the axes is exactly orthogonal to the screen, but I wonder whether printing xyz coordinates in the toolbar even makes sense at all? Basically, we pick an arbitrary screen-z-depth for the cursor (based on the distance to the edges -- which is where the warning comes from) and print the corresponding xyz value, but if one e.g. carefully looks at the displayed xyz values while slowly moving the mouse across a (default, non-ortho) 3d axes, one will see that the value suddenly jumps when the mouse goes from "closer to one axis" to "closer to another axis".
In other words, I would suggest to just stop displaying mouse cursor xyz values here. (Also compare with e.g. mayavi, which doesn't display them either.)

I am not convinced the values make sense at all. For example, these are the xyz values printed when dragging the mouse across window (default 3d view) horizontally, along the middle y position:

from pylab import *
from matplotlib.backend_bases import LocationEvent
rcdefaults(); rcParams["axes.unicode_minus"] = False  # use ascii minus
fig = figure()
ax = fig.add_subplot(projection="3d")
fig.canvas.draw()
xyzs = []
screen_ry = .5
# drag mouse across window horizontally, along the middle y position
for screen_rx in np.linspace(0, 1, 1001):
    screen_xy = fig.transFigure.transform((screen_rx, screen_ry))
    pseudo_xy = ax.transData.inverted().transform(screen_xy)
    ev = LocationEvent("", fig.canvas, *screen_xy)
    ev.xdata, ev.ydata = pseudo_xy
    if any([axis.pane.contains(ev)[0] for axis in ax._axis_map.values()]):
        s = ax.format_coord(*pseudo_xy)  # formatted string
        xyzs.append([float(part.split("=")[1]) for part in s.split(",")])  # displayed xyz
    else:  # out of Axes
        xyzs.append((np.nan, np.nan, np.nan))
xyzs = array(xyzs)
close(fig)
plot(xyzs[:, 0], label="x")
plot(xyzs[:, 1], label="y")
plot(xyzs[:, 2], label="z")
legend()
show()

The jumping is... not nice.

when this feature has broken for other reasons, users have noticed and complained

Actually, I have quickly skimmed through the issue list and didn't find anything related, but perhaps you have refs e.g. on the mailing list?

Ok, so I am also having difficulty finding what I was thinking of, but, here are some issues where people expressed interest in having access to 3D coordinate information:

#16156
#11309
https://discourse.matplotlib.org/t/no-zdata-in-motion-notify-event-when-using-a-3d-plot/16201

This isn't a comprehensive listing of such interest, and it shows that users find the information that is displayed by format_coords() to be useful enough to want to know more about how to get it programmatically. While I haven't had time to look closely at what you showed above, that isn't an argument to get rid of it; it is an argument to make it better behaved.

I don't disagree with making it better behaved. However, the value currently displayed is simply worse than useless, it is misleading (it does not correspond to the dot they are pointing to).