Modal Operator Bug Causing False MOUSEMOVE Event?

Archive Python API
1

I posted this at BlenderArtists but realized this is probably the better place to ask.

I’m getting behavior I didn’t expect and don’t remember seeing in 2.79 so I was wondering if someone could test this out and see if they’re getting the same thing.

Open the System Console.

Now open the text editor and load up the template: operator_modal.py

Add print(event.type) on line 14

image

Then remove the test call on lines 50/51

Now go to the 3D View and do an operator search (press the x key), type in Simple Modal Operator, and hit Enter.

You should have not touched the mouse at all, only the keyboard.

This is what prints out in the console:

MOUSEMOVE
RET

Having not touched the mouse at all the modal operator is automatically registering a mousemove event that never happened.

This seems like a bug but maybe it’s normal and I just don’t understand the behavior. If it’s supposed to do this can anyone explain why it does this? I’m trying to write an addon that executes something, but only if the mouse moves, and this is kind of short-circuiting the logic I want.

Thanks!

2

yep, happens to me as well. I’d log a bug for it, but in the meantime for your purposes it would be easy enough to set a flag in invoke, then clear it on the first modal pass- and then pick up every other mousemove event afterward.

3

Thanks for testing. I’ll log a bug.

That’s a good idea about setting the flag. I’ll set it up that way for now. :+1:

4

Yep, ran into same behavior. Definitely not normal, but since I normally (always) base the values in the code on mouse_x/y value, the worst thing it did was nothing. But I guess it depends on what you’re trying to do.

In addition to testure’s suggestion you can also just compare current vs previous coordinates to get actual movement.

        if (event.mouse_prev_x != event.mouse_x or 
            event.mouse_prev_y != event.mouse_y):
            print('actual move')

RET on the other hand is correct. If you do a print(event.value) you’ll see it’s the return key being caught in the upstroke. I guess you figured that part already.

5

Yeah, initially the RET confused me because I thought, how can it be picking up something before the operator even runs?! But then I remembered there’s a press and release value. :stuck_out_tongue_closed_eyes:

Ah, ok. So as long as it’s not at the same coord it was last time it checked it returns True, essentially giving you a MOUSEMOVE event. I like that, too. Thanks.

6

Just thought I’d update the topic with my bug report:

https://developer.blender.org/T65337

The issue was closed because it looks like operators force a mousemove event to kick start the operator sometimes. Brecht admits it’s probably not the best way to do it, but, that’s how it works right now.

operators should not rely on interpreting the mousemove event as meaning any kind of meaningful mousemove by the user.

If an action should start based on the user moving a mouse, the operator should check if the mouse has moved beyond some threshold distance.

It’s just such a quirky caveat. There’s so many secret rules! :upside_down_face: