1898491 - The resizer is disabled in situations when the it would have space to resize

Status: NEW

(Firefox :: Translations, enhancement)

Description

[Daniel Bodea [:danibodea]]

Attachment: Does not display the resizer when it would have space to resize_edit_0.webm

Note

• The resizer is disabled when the dialog is opened in "flip-mode" (when the user opens the context menu close enough from the bottom of the screen and the dialog is forced to open upwards instead of downwards), so the dialog might not allow resizing even when it might have space to resize.
  The attached demo video shows that opening the dialog on the bottom half of the screen on a system with a 1080 vertical resolution
  results in a dialog with no resizer, even when the dialog has space to resize under it.

Found in

• Nightly v128.0a1

Affected versions

• Nightly v128.0a1

Tested platforms

• Affected platforms: Windows10, MacOS11, Ubuntu22+X11
• Unaffected platforms: Ubuntu22+Wayland (resizer is displayed and working in "flip-mode")

Steps to reproduce

1. Load a webpage that is displayed in a language different from the browser's (and supported by Translations).
2. Select a large enough text (to not fit in the textbox).
3. Right-click on the webpage, on the bottom half of the screen.
4. Observe the "flip-mode" dialog (that opens upwards from the context menu, not downwards)

Expected result

• The dialog should have a functioning resizer when there is space to resize.

Actual result

• The dialog does not have a resizer displayed, even when there's enough space to resize.

Regression range

• Potentially regressed by: 1894935

Additional notes

• This issue still occurs in Ubuntu with X11 window protocol, but will not occur for Ubuntu 22 with Wayland window protocol, because the resizer remains displayed on "flip-mode" dialogs and (fortunately) it does not seem to cause any glitchy behavior when used.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:nordzilla, since you are the author of the regressor, bug 1894935, could you take a look?

For more information, please visit BugBot documentation.

Comment 2

[Erik Nordin [:nordzilla]]

The fundamental issue here is that when the panel position is vertically flipped before opening, it changes the anchor position to one of the panel's bottom corners, instead of the top corner. When the panel is anchored from the bottom, the only place the panel has to expand is upward from the top, and it creates the undesirable effect of the user dragging the textarea resizer downward while the panel is growing upward from its top edge.

The situation is explained here in this comment.

The decision of how the panel is anchored on open is made by the XUL popup management code.

It may be possible to look into ways to re-anchor the panel in this situation, but I consider this a low-priority fix since the textarea scroll bar still functions fully, and this scenario only occurs when translating a large selection of text while also opening the panel near to the bottom of the screen.

I will consider adding a temporary telemetry metric that will track how often this case occurs in the wild, and adjust the priority accordingly.

Comment 3

[Daniel Bodea [:danibodea]]

I apologize, I meant to log this as an enhancement, not a defect, since the resizer was an enhancement itself. In any case, we don't consider this a priority for release.