Using keyboard on inputs causes viewport to resize, shrinking elements based on viewport units.

NEW
Unassigned

Status

()

defect
P5
normal
5 years ago
17 days ago

People

(Reporter: bugs, Unassigned)

Tracking

Trunk
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [webcompat])

(Reporter)

Description

5 years ago
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.
Might get more traction in the zoom and pan component instead of keyboard.
Component: Keyboards and IME → Graphics, Panning and Zooming
(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.
Whiteboard: [webcompat]
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.