Page MenuHome

The Tool Selector Window close one time every two times, when opened too closed to the bottom border of the screen
Open, Confirmed, MediumPublic

Description

System Information
Operating system: Windows 10
Graphics card: GTX 1080

Blender Version
Broken: 2.80
Worked: (optional)

Short description of error
The Tool Window, open and close immediately, choosing the tool under the mouse cursor, if the tool window is opened too close from the bottom of the screen.

Exact steps for others to reproduce the error

  1. In Edit > Preferences > Keymap, set the "Space Bar action" to "Tools"
  2. On the 3D viewport, place your mouse cursor in the top area of the viewport
  3. press the spacebar, the tool menu open without any problem, and you can choose a tool with a shortcut key (for example press B to choose the Box selection)
  4. You can repeat that several times in a row without any problems.
  5. Now move your mouse cursor much more closer to the bottom border of the screen, so that you know that the tool window will have to be shifted upward to be displayed correctly.
  6. Press the spacebar a first time. This is ok, you can select your tool
  7. Now press the spacebar a second time. This time, the tool window open and intermediately closed, and the tool selected is the one that is under your mouse cursor.
  8. Press the spacebar again: the tool window open normally
  9. Press the spacebar again: the bug reappear
  10. Now on, every one time over two, the bug appear.

Expected behavior
The Tool Window should open and stay opened consistently, no matter where the mouse cursor is placed on the screen, when the spacebar is pressed.

Details

Type
Bug

Event Timeline

More precision on how to reproduce the bug:

The bug can also appear if you press the space bar near the top of the screen, and the tool window has to be shifted downward to be displayed. Basically, it depends on which tool is currently selected when you press the space bar. For example if the "Box Selection" tool is selected (the top tool in the list), then you can reproduce the bug as described above, by placing the mouse close to the bottom of the screen.

Symmetrically, if you select the "Rip Region" tool (in "Edit mode", in order to have a long list of tools), and then place your mouse cursor next to the top of the screen, you can also reproduce the same bug, by pressing the spacebar.

Campbell Barton (campbellbarton) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.

This is the same as T49029 I think. This happens with all kinds of menus as far as I know : lists, popovers, pies. It would be nice to allow them to be drawn partly offscreen.

While it's a related issue, we can not assume the user manually moved their cursor over an item in the case the menu has been re-positioned.

Even though the same fix could be applied for both, they would be done separately, so keeping both reports open is fine.

Thanks for the comments.

Moreover, while the bug could be understandable in case of a pie menu (because pie menu items can be selected with only a mouse move), in the case of the tool selection menu, that doesn't make sens, because when that menu popup, user needs to actually click on a item of the menu to select it (in case you don't choose to use a shortcut key).

Therefore for that kind of menu (that need a click, and that cannot be selected with just a mouse move), user don't understand why the menu close immediately.

So I think it may deserve a different fix: for this kind of menu you could allow the menu to be repositionned (but don't close), and maybe for the same situation for a pie menu, you could update the start mouse position with the same amount of shift that was apply to the menu, in order to not detect a move, if the menu was shift programmatically.

Thanks a lot.

One thing to keep in mind is that menu items can be selected with "mouse release" events and "key release" events as well (hold spacebar, release with mouse cursor over an item to select it).

Alban Nanty (banban) added a comment.EditedAug 9 2019, 5:18 AM

Ah yes, you're right!! Didn't realize you could also do that with that menu. :-)

In that case, I think the fix is simple and global for all menus: when a menu appears, if it needs to be shifted, then that shift (translation) should also be added to the start mouse position recorded internally to compute the mouse move vector.

Basically, what I'm trying to say, is that any move (of the menu or the mouse cursor) done programatically, is not a USER input, therefore should not be taken into consideration for analyzing user mouse input.

Yours.