Hi, I tested on macOS - it still doesn't work on Safari. However in light of your idea I tested a little bit more and this seems to fix it on Safari:
Both canvas and rubberband_canvas have to be "pointer-events: none;" - this is needed for Safari to make the div resizable. Then I changed all event listeners in your commit from canvas to canvas_div (essentially going one layer deeper, letting the div be the receiver of mouse events. Fortunately a closure is used so no other change is needed).
I added ".mpl-canvas{ pointer-events: none; }" to boilerplate.css. After all these I tested briefly and it seemed to be finally working now.

I added ".mpl-canvas{ pointer-events: none; }" to boilerplate.css.

To be precise: I added this line in the dev tool temporarily just for testing. Adding this line to the actual file backends/web_backend/css/boilerplate.css somehow didn't work (canvas just doesn't have that style). Is there some sort of caching?

Well, that's interesting, but unfortunately doing so breaks the resize in Firefox because the mouse event handlers steal it from the resize if it's on the same element. I'll have to see if there's some additional setting we can do to work everywhere.

OK, I've found that Firefox broke because we call preventDefault in the mouse event handler:

The only reason to prevent default mouse event handling I can think of is for the context menu, but we do that in the 'contextmenu' event now. Can you think of any other reason to keep this?

OK, I've found that Firefox broke because we call preventDefault in the mouse event handler:

Did some test here on Safari: if the mouse event receiver is a canvas then commenting out preventDefault has no effect, but if it's a div then commenting it out will indeed make the cursor an "I" when pressing the button.

If we want to make canvas_div the receiver while Firefox doesn't need preventDefault, do you think it makes sense if as a last resort we do something like

    function on_mouse_event_closure(name) {
        if(is Firefox) 
            return function (event) { 
                return fig.mouse_event(event, name); 
            };
        else 
            return function (event) {
	        event.preventDefault();
                return fig.mouse_event(event, name);
            };
    }

This may hopefully handle both cases while not introducing overhead to the mouse handler.

After several tries, I've given up on trying to make a universal setup, due to the bugs [1, 2] I've found above in WebKit. So this does end up doing a bit of browser sniffing, but it's just to prevent the selection from appearing over everything in WebKit. If that breaks, everything will still work but with a slightly annoying selection that can be dismissed after pan/zoom.

I confirmed this fixes the problem in Midori (WebKit-based) without breaking Firefox or Chromium. I was able to reproduce the cursor problem in WebKit as well, so that's why I had to do the preventDefault stuff. This also works in #23540.

I double-checked on a HiDPI screen today and noticed this broke it, so pushed a change that should work again, and added a comment so that it's clear why that code is there.

running exapmles/user_interfaces/embedding_webagg_sgskip.py this does work, but the handle is not always visible.

Unfortunately, nothing I can do about that due to the above bugs in WebKit. We might want to consider adding an overlay sort of triangle ourselves, maybe.

As a user I think I can live with not having the handle (rather than not functioning at all, or having extra overhead just for visual purpose).. Of course, just my $0.01 the decision is yours :)

As a user I think I can live with not having the handle

Fair, but I almost posted "does not work in safari". But as a matter of completeness I also installed chrome (to check that my check was actually working at all) and when I connected to the same server with that I saw the handle flash in safari.

the handle flash in safari.

Yes, it's also what I observed- I guess there's no easy way around this than pushing WebKit to fix the bugs.

Besides, I still recall the earlier versions when it worked (pre-3.3.0-ish, using jQuery); but I don't recall or I didn't pay attention to whether the handle and the cursor change worked in Safari back then.