[FR] Animate Context Menus — invert animation when menu appears above the cursor

[emvaized]

Is your feature request related to a problem? Please describe. When you open context menu on right click, at appears above the mouse cursor when there is not enough space on the bottom. However, "Animate Context Menus" still plays "move down" animation, which feels visually detached in this case — menu no longer "grows" from the point of right click.

Describe the solution you'd like Some modification to the CSS rules in order to apply different animation if menu is opened above the mouse cursor. In the browser inspector I didn't found any HTML attribute added to the context menu when it is placed above the cursor, so probably some JS calculations are needed after the menu was shown?

[aminomancer]

Yeah that would be nice to fix, but I can't change that behavior. The menu doesn't know how it was constrained, as that's all handled in C++. Letting the JS know if a context menu (anchored on the pointer) was flipped would require changes to this stuff that we can't make with autoconfig hacks, and not everyone would be eager to adopt changes to toolkit code just to support custom hacks, when nothing in the browser needs it.

[emvaized]

Thanks for your detailed response!

I see. Maybe then it could be possible to somehow use getBoundingClientRect in order to calculate if the context menu above or below the mouse pointer?

[aminomancer]

That is possible, but I feel like it would be buggy, because the mouse can probably move a lot in the time between setting where it will open and the popup actually being drawn. The coordinates are set on popupshowing, but the rect can't be checked until popupshown, and the mouse could have moved in the interim. Sometimes the mouse gets flicked pretty fast, so maybe by the time we check it, it's in a completely different place relative to the context menu.

I think we also aren't able to tell in JS whether the menupopup was really opened on the pointer at all. There are other ways to open a menupopup. They can be invoked from JS (openPopup), but then they pass into native code, and that information basically gets sucked into a black hole. Panels give this information back to JS through a DOM event, but not menupopups.

So on the other side, the script (which relies on DOM events) can't be certain that it's dealing with a true context menu at all. I guess we could exclude most menulists by checking their parent, but there are other oddities throughout the browser. Like if you left click and hold on the new tab button. So it seems janky to solve this without direct knowledge of the flip state. Not that I'm a stranger to jank...

@emilio might have some other ideas for how to get this information to chrome JS. I'm pretty new to this area so I might be overlooking something.

[emilio]

@aminomancer anchor position and so on is exposed in the popuppositioned event, right? here

[aminomancer]

@aminomancer anchor position and so on is exposed in the popuppositioned event, right? here

Yeah, alignmentPosition, alignmentOffset, popupAlignment. But we only dispatch the event for type="arrow", and if you give a menupopup that type, the values are basically blank. I'm not exactly sure why, but I guess it must be because there is no mPopupAnchor for stuff like this.