[FIX] pivot: mouse events do not work in pivot text input

[hokolomopo]

Description

We added a behaviour to select the whole text of the measure name input when the input is focused. We select the whole input text on focus event, but we had to stop/prevent the mouseup events, otherwise the event would sometime unselect the text.

It turns out (surprise) that entirely disabling mouseup event on the input was a bad idea: it prevented the user from moving the cursor inside the input when all the text was selected.

This commit changes the way we handle all this:

• if the input is not focused, we disable the mousedown event on it. This prevent the focus event from firing.
• if the input is not focused and we catch a mouseup event on the input, we select the whole text and focus the input manually.
• if the input is focused, we do not touch the events and let the browser handle them.

Task: 4350439

review checklist

• feature is organized in plugin, or UI components
• support of duplicate sheet (deep copy)
• in model/core: ranges are Range object, and can be adapted (adaptRanges)
• in model/UI: ranges are strings (to show the user)
• undo-able commands (uses this.history.update)
• multiuser-able commands (has inverse commands and transformations where needed)
• new/updated/removed commands are documented
• exportable in excel
• translations (_t("qmsdf %s", abc))
• unit tested
• clean commented code
• track breaking changes
• doc is rebuild (npm run doc)
• status is correct in Odoo

[robodoo]

[rrahir]

Have you considered simply relying on the focus event and see if ev.target is the same as ev.relatedTarget
https://developer.mozilla.org/en-US/docs/Web/API/Element/focus_event#event_properties
I think you achieve the same functional result but don't need the convoluted 'stop an event to prevent the following one'

[hokolomopo]

Have you considered simply relying on the focus event and see if ev.target is the same as ev.relatedTarget https://developer.mozilla.org/en-US/docs/Web/API/Element/focus_event#event_properties I think you achieve the same functional result but don't need the convoluted 'stop an event to prevent the following one'

@rrahir reading the spec, I'm not sure why I would compare ev.target and ev.related target ? relatedTarget is the element losing focus, so it should always be different from the element gaining focus (ev.target) right ?

Anyway the reason we do not select the text on focus is that the mouseUp (that is fired after the focus) can sometimes unselect the text. That's why dhrp stopped/prevented the mouseUp event in his original PR :x

[LucasLefevre]

robodoo r+