1007286 - Using keyboard on inputs causes viewport to resize, shrinking elements that are sized with viewport units (vh), or with a percent-height resolved against viewport height

Status: NEW

(GeckoView :: IME, defect, P3)

Description

[nemo]

I had the idea that vw and vh would be handy to define UI elements that scaled to the width/height of the device, and the orientation.

Now, using this in practice, runs into Chrome and Internet Explorer bugs. For example, http://m8y.org/tmp/testcase272.xhtml

Now I ran into another issue, this time in Firefox.  URL below demos.
http://m8y.org/tmp/testcase374.xhtml

Essentially though, and unlike Chrome on my Nexus 5, Firefox resizes the viewport when the soft keyboard appears.

This causes an annoying flickering of on-screen viewport sized elements as the keyboard appears, and while the keyboard is active, everything sized in vh is about half normal size.

It'd be nice if Firefox didn't do that.  snorp says it is to ensure the edited element is visible. Seems to me you could position it on the page so it'd be at the top of the viewport.  Even if the element is last on the page, seems you could probably kinda scroll past the end.

BTW, Chrome on the Nexus 5 has an irritating bug in this demo where it "loses track" of the size of the elements.  So the text area suddenly jumps down to half its former size, or one or more of the labels.   There appears to be no consistency, but seems to happen at random when I'm unfocusing on the text area and when trying to "toggle" the labels.

Oh well. Mobile is fraught w/ stuff like this, and Chrome does this kinda thing to me all the time.  Witness how they broke positioning for their convenience and without even a -webkit-position prefix.

Comment 1

[(inactive) Jim Chen [:jchen] [:darchons]]

Might get more traction in the zoom and pan component instead of keyboard.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

(In reply to nemo from comment #0)
> It'd be nice if Firefox didn't do that.  snorp says it is to ensure the
> edited element is visible. Seems to me you could position it on the page so
> it'd be at the top of the viewport.  Even if the element is last on the
> page, seems you could probably kinda scroll past the end.

Snorp is right. The "scroll past the end" sounds simple in theory but is pretty hard to implement in practice. We'd also have problems with fixed-position elements not being placed properly.

Comment 3

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 4

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 5

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 6

[Poopooracoocoo]

Does this still apply to Fenix?

Comment 7

[Poopooracoocoo]

hey hiro could you check this out pls? 7 years sure is a long time

Comment 8

[Karl Dubost💡 :karlcow]

• It doesn't reproduce anymore on https://webcompat.com/issues/13348 on latest nightly fenix 85.0a1-20201117094406
• It still reproduces on https://webcompat.com/issues/28446 which is a major difficulty because it prevents the user to log in.

Also this has a similar type of issue https://github.com/webcompat/web-bugs/issues/23660#issuecomment-460844843

Comment 9

[Karl Dubost💡 :karlcow]

See also https://www.chromestatus.com/feature/5656077370654720

Comment 10

[Hiroyuki Ikezoe (:hiro)]

This bug should block bug 1123938.

Unfortunately I don't have enough band-width to work on this right now, once after it turns out this is a high priority thing, I may be able to jump in.

Comment 11

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.

Comment 12

[Poopooracoocoo]

This was not resolved, was it?

Comment 13

[Hiroyuki Ikezoe (:hiro)]

Right, this issue hasn't yet solved. Moving into Layout to avoid being closed by the BMO bot accidentally.

Comment 14

[Kevin Brosnan [Ex-Mozilla]]

Layout should determine priority/severity p5 was set by a bot.

Comment 15

[Frank Griffith Jr]

Hiro, can you take a look at this to assess the issue?

Comment 16

[Hiroyuki Ikezoe (:hiro)]

Dropping https://webcompat.com/issues/13348 since it's a different issue, it's been resolved. (note that the banner in the site specifies "font-size: 2.5vh;" now vh units is stable)

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Dropping https://webcompat.com/issues/28446 too since it looks like it's no longer reproducible as per https://webcompat.com/issues/28446#issuecomment-877119925 .

Comment 18

[Hiroyuki Ikezoe (:hiro)]

I collected information around this kind of issues and I am going to summarize it.

What other browsers do when the software keyboard appears;

• Safari doesn't resize the layout viewport size, instead, overlays the keyboard (based on this comment, I haven't checked since I have no iPhones)
• Chrome does resize the layout viewport size as of today
• Firefox does the same thing what Chrome does

Chrome has been struggling with this issue, they can't simply change their behavior to the Safari's since it will break a bunch of sites based on the current behavior. Given that an input area positioned at the bottom of the page, it will be covered by the software keyboard.

So, Microsoft proposed a mitigating way, Virtual Keyboard API which allows web developer to be opt-in the overlay behavior. Chrome has started implementing the API since the last year (2020).

Our situation is pretty much same as Chrome. We shouldn't simply change our behavior, it will result a lot of complains from web developers.

Though the Virtual Keyboard API hasn't yet been discussed in any working groups, it's worth considering to resolve this issue on our end. If we decided to implement it, I'd be happy to help it.

Note that there's another proposal from Microsoft, Virtual Keyboard Control which has also been implemented in Chrome, though I am unsure this proposal is usefull or not.

Also note that to implement the Virtual Keyboard API there are not so much work in layout, it should mostly be implemented in GeckoView and widget code and DOM APIs. The part of layout stuff would be CSS environment values which should be straight forward.

Comment 19

[Hiroyuki Ikezoe (:hiro)]

Note that I asked masayuki about this issue since he is an expert on our keyboard input handling (regardless whether it's software or hardware). He told me that following the Chrome's approach would be better, he also told me that he hasn't read the API document carefully though.

Next steps would be;

• ask someone who is a security/privacy expert, there's a section about privacy concerns in the explainer
• ask a DOM peer whether the WebIDL definitions look reasonable or not

Back to GeckoView component now and NI to Emily to avoid losing this issue from their radar.

Comment 20

[Emily Toop (:fluffyemily)]

Agi to figure out where this should be sent next

Comment 21

[[ex-Mozilla] Agi Sferro | :agi]

Based on the fact that we're like Chrome, I'd say this is not as high priority as I thought. I'll discuss with the team tomorrow on our planning. Keeping the NI as I still want to follow up with DOM and Privacy.

Comment 22

[[ex-Mozilla] Agi Sferro | :agi]

Didn't mean to change the priority.

Comment 23

[Hiroyuki Ikezoe (:hiro)]

FYI; the virtual keyboard API spec has been moved to w3c; https://w3c.github.io/editing/docs/virtualkeyboard/index.html

Comment 24

[Hiroyuki Ikezoe (:hiro)]

And Chrome will ship the API on Chrome 94 which will be released on this Sep. 21.
https://www.chromestatus.com/feature/5680057076940800

Comment 25

[Chris Peterson [:cpeterson]]

Moving some keyboard bugs to the new GeckoView::IME component.

Comment 27

[Thomas Wisniewski [:twisniewski]]

This is causing a webcompat issue on https://www.meteoam.it, because they size an iframe with height:75vh, and also listen for resize events on that frame. This ends up making it impossible to type in a search input, because their scripts hide the input when the keyboard is brought up and the resize event is handled.

Comment 28

[Daniel Holbert [:dholbert]]

[Adjusting title to make it clearer that viewport units aren't strictly required; my testcases in bug 1826410 just use percent sizes -- no vh -- and hit this same issue.]