[bug] Translate UI - wrong placement of circled accelerator keys

From Support
Jump to navigation Jump to search

[bug] Translate UI - wrong placement of circled accelerator keys

Translate UI- wrong placement of circled accelerator keys.png

Accelerator keys in circles displayed in the Translation UI are incorrectly placed. They should not collide with the editable text area where they obscure the text being edited. Ideally they should be placed just below the bottom of their border box, with enough margins, and not above the top border.

And the surrounding circles (actually boxes with large paddings and rounded corners) are too large, given they are also completely opaque: there's no need to have so large paddings.

Finally they should probably be visible only if the input focus is inside the text area, and probably only when we hold the [Alt] or [Super] key (depending on the browser's UI for its platform) to use them by pressing the displayed key (one digit or letter). Without this focus (flashing caret or current text selection) in the editable text area, the accelerator keys should have no effect and should then not be displayed at all. In fact most users will prefer clicking (or tapping on a tactile screen) the suggestion boxes to insert their suggested text into the text area at its current input position.

Now if you zoom in/out with the browser their placement is even worse. They are in fact absolutely positioned in the window instead of being relatively positioned, and their computed absolute position is completely wrong.

Verdy p (talk)01:53, 9 October 2019

They are only visible when one presses ALT. Sometimes they get stuck if we don't key keup event (such as when ALT+Tabbing to another window), but pressing ALT again will make them go away.

Nike (talk)12:55, 9 October 2019

No, they are permanently on screen... Pressing ALT or releasing it does not change the display. This was probably displayed on just a few browsers, but does not work in Google Chrome (the most widely used browser in the world) in Windows (though I don't think this behavior is just tied to Windows).

I found that the bug occurs sometimes after pressing ALT+TAB to switch to another application in Windows, and then returning to Chrome, also with ALT+TAB or with a click. The release event for ALT key is no longer detected, even when pressing and releasing ALT again, or it has no effect for objects already in the interface. Note that there are still multiple warnings displayed in the Developer console, including deprecated interfaces in several component libraries, related to jQuery unsafe/deprecated APIs ,or APIs in Mediawiki itself when they hook some event handlers; may be the same handler has been registered twice or registered in a "lazy" way, possibly the ALT release event is registered too late and not bound correctly in all closures, or this does not work with international keyboards (if the Alt key is confused with AltGr; it may also be incorrect detection of Chrome for Mac keyboards when we use Windows).

I've not seen such issues in other websites using jQuery, where we can safely use common Windows accelerators like ALT+TAB to switch between multiple open windows. And I have a very minimalist number of browser extensions (I have even disabled several extensions preinstalled by Google in Chrome for Windows, and not allowed Microsoft to install its own extensions into Chrome).

There's no such issue if I use Edge Beta (Chromium-based), which is using dramatically less memory than Chrome and is more power-efficient, and loads faster, I'm about to switch to Edge Beta if Microsoft ever releases it instead of its current home-brewed Edge which is an horror breaking many sites.

And anyway the fact that their position is very wrong and is even worse with browser zooming (where circles are going to higher positions when the text and boxes are shifted down when the zoom lever is larger) is a sign that jQuery or similar APIs are wrong, or make unsafe assumption.

Verdy p (talk)13:22, 9 October 2019