kirbydesign / designsystem

Kirby Design System
https://cookbook.kirby.design
MIT License
85 stars 23 forks source link

[BUG] Textarea & input is covered by on-screen keyboard #2151

Closed jkaltoft closed 2 years ago

jkaltoft commented 2 years ago

Describe the bug and how to reproduce it

  1. Textarea is close to the bottom of the device screen
  2. Tap the textarea and the keyboard appears
  3. First time you tap, the keyboard covers the textarea ⬅️ This is the bug 🐞
  4. Tap outside the textarea and the keyboard ➡️ Keyboard closes
  5. Second time you tap the textarea, the keyboard appears while the content is pushed up ➡️ textarea is not covered by keyboard

Which Kirby version was used?

?

What was the expected behavior?

Textarea is not covered by keyboard

Add any screenshots

Please complete the following information:

Are there any additional context?


Checklist:

The following tasks should be carried out in sequence in order to follow the process of contributing correctly.

Verification

To make sure the bug is not intended behaviour; it should be verified by a member of team Kirby before moving on to implementation.

Implementation

The contributor who wants to implement this issue should:

Review

Once the issue has been implemented and is ready for review:

RasmusKjeldgaard commented 2 years ago

Same problem is described in #2161, with a video and some additional details.

jonas-jyskebank-dk commented 2 years ago

I am experiencing a similar issue: When going to next input field from previous input, the page does not scroll into view, causing an issue where the keyboard that is still showing and waiting for input on the next input field, is blocking the view of that input field. Note: The issue seems to be when the input field receives focus through pressing next on the virtual keyboard (implementation is different on devices with differing virtual keyboards, iOS have up/down arrows, while on some android its ->| ). If you on the other hand click on next input field it seems to scroll into view as expected.

On devices it is my understanding that the default behaviour is that it scrolls into view unless you have explicitly told not to. It should be noted the next input field does receive focus, as you can type in it, it just doesn't get scrolled into view.

Simple setup to reproduce: I have a component thats a modal (not tested if this is relevant). As a minimum example:

<kirby-page-title>Testing Input Fields</kirby-page-title>

<kirby-card [hasPadding]="true">
  <kirby-card-header
    title="I am just a title for testing purposes"
    subtitle="I am an even longer title for testing purposes, although im a subtitle"
  ></kirby-card-header>

  <p>
    Lorem, ipsum dolor sit amet consectetur adipisicing elit. Mollitia facere
    molestias recusandae necessitatibus ab veniam repellendus doloremque culpa
    quam libero, est quo accusamus cumque, in quia itaque cupiditate ratione
    repellat!
  </p>
  <br />
  <p>
    Lorem, ipsum dolor sit amet consectetur adipisicing elit. Mollitia facere
    molestias recusandae necessitatibus ab veniam repellendus doloremque culpa
    quam libero, est quo accusamus cumque, in quia itaque cupiditate ratione
    repellat!
  </p>
</kirby-card>

<form [formGroup]="form">
  <jbi-first-input ></jbi-first-input>
  <jbi-second-input ></jbi-second-input>
  <jbi-third-input ></jbi-third-input>
</form>

Where the Kirby card is added as filler to produce enough space to see the issue. This component use 3 custom input components, that are using kirbys form field. The 3 input components are separate and very simple components like below:

<kirby-form-field>
  <input type="number" kirby-input />
</kirby-form-field>
<kirby-form-field>
  <input type="text" kirby-input placeholder="Some placeholder text" />
</kirby-form-field>

Expected behaviour: Input field is scrolled into view when it receives focus, in cases like described above, as is the default behaviour unless you have explicitly made action to prevent this.

OS and Devices: I think it concerns all, have tested on iPhone 11 Pro (iOS 16), Google Pixel 4XL (Android 13) and OnePlus Nord2 5G (Android 12 / Oxygen build: DN2103_11_C.10)

mark-drastrup commented 2 years ago

Both @RasmusKjeldgaard and I haven't been able to reproduce the original bug, but I have been able to reproduce the bug that @joroJB has described above. It seems like the issue lies with the Capacitor keyboard plugin. If I run an application without the capacitor keyboard, then the previous and next arrows (provided by the default keyboard) in the accessory bar works as expected. But if I run an application that uses the Capacitor keyboard, then the bug occurs. I also tried to use the Ionic input instead of kirby-input to see if their input shim logic would kick in and fix the error, but the result was the same.

I have created an issue in the Capacitor plugin repo: https://github.com/ionic-team/capacitor-plugins/issues/1255

mark-drastrup commented 2 years ago

A member of the Capacitor team closed the issue mentioned above with this comment.

So it seems like it's related this WebKit issue

RasmusKjeldgaard commented 2 years ago

Closing this one then, unfortunately there is nothing we can do about it right now @jonas-jyskebank-dk as there seems to be no workaround.