Simplified repro:
1. open the attached test.html
2. zoom the page to less than 100% e.g. to 90%
3. type any letter like "a"

Expected: "input" text appears below the buttons
Observed: nothing

Bisect info: 377247 (good) - 377255 (bad)
https://chromium.googlesource.com/chromium/src/+log/109c974a..80478c42?pretty=fuller
Tentatively suspecting 80478c4257e298248e380b62e941ab4c2f775b12
"Editor::selectionForCommand is used to get selection before exec commands"
Landed in 50.0.2659.0

A weird workaround is to remove "line-height: 1px" from the textarea style.

Deleted: test.html 828 bytes

test.html 828 bytes View Download

oh the workaround is very useful to me, thanks.
Sorry i did not simplify the case enough, but that is the use i make of the textarea, and i wanted to be sure that particular situation is captured when the big is eventually fixed.

Able reproduce the issue on reported chrome version #68.0.3440.84 on Ubuntu 17.10.
Note: The issue seems specific to Linux, as it is not reproduced on Mac 10.13.5 and Windows 7

As per comment #1, assigning it to the yoichio@ for further inputs on this issue.

yoichio@ :Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks.!

my submitted test case is reproducible on MACOSX.

I ll try a windows machine too.

No textarea shows at the fiddle. If the element is not layouted, no focus
on the element.
I don't understand the intention of the code.

yoichio@, the textarea is small and transparent as you can easily see in the code, but it's focused.
This setup is very often used to get the keyboard input for things like text editors or incremental search.

Is also not a layout problem too much. If the textare is invisible but does not have line-height: 1px, then everything works.

Also the cause of the bug is zoom less than 100% and empty textbox.

it means that something is off. If it should not fire the event, it should be either at any zoom level at any string length.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I guess Blink doesn't focus a element that's height is less than 1px physically because nothing should be rendered.
So, if a element has 1px height and you zoom less than 100%, like 90%,
the height gets 1px*90% = 0.9px.

To me, setting style="opacity: 0;" is enough to get user input while hidden its actual input.
Also I think line-height:1px is hacky.
Could you feedback more about what you want exactly while you want to avoid
what?
Maybe we can have better APIs for that.

Oh, I found it was more general.
http://jsfiddle.net/3ej7xv8o/
Updated the description.

Memo: current Blink focusing code through VisiblePosition depends on LayoutObject's height:
https://cs.chromium.org/search/?q=logicalheight+file:%5Esrc/third_party/blink/renderer/core/editing/+package:%5Echromium$&type=cs

We should fix at least FrameSelection::SelectionHasFocus and editor_command.cc::EnabledVisibleSelection return true for such element but I guess many code around Editing assumes input target element has valid height,,,

Adding "body { zoom: 50% }" to <style> also causes this issue.

Also the strange part is that if you write at zoom 100 and write a word, then zoom at 50% it continue working.
If the textarea gets edited then to no text, is not possible to edit anymore.

I do not think rendering anything is important, but firing the events is.

 Issue 892789  has been merged into this issue.