Guessing the keyboard height on iOS

(Chris Beach) #1

Not sure if it’s related to the upgrade but the notorious iPhone discourse editor height issue is back when “Predictive” is enabled (and I believe the iOS default is Predictive enabled):

As you can see, the important “reply” button is obscured, which will be very confusing for new users.

The discourse editor is fine with Predictive disabled.

When should Discourse upgrade to Rails 5?
(Sam Saffron) #2

Unrelated … this is just ios being SUPER annoying. I am going to reduce a few heights now.

(Sam Saffron) #3

What device are you using there? I tested on iOS 11 iPhone 7 and @codinghorror tested on iOS 11 iPhone 8 plus.

Going to test iPads now.

(Sam Saffron) #4

GRRR bingo … found the bug … this is such a nightmare… there are 2 inner heights I need to work with … one when the bottom < > etc is showing … and one when it is not…

(Chris Beach) #5

I’m on iPhone 7, iOS 11 - glad you found the bug!

(Sam Saffron) #6

I am less glad … this thing just behaves totally randomly … it is mega annoying.

(Chris Beach) #7

Good stuff, @sam. It’s once again usable on iOS.

While you’re looking at it, is there any way the editor could resize to always fill this space when Predictive is disabled?

It does seem to fill this space when replying sometimes:

(Sam Saffron) #8

No, it is impossible for me to “predict” if predictive text is enabled or not.

Closest I could do is pass it in via the app so we reduce the fudge factor once it is disabled.

(Sam Saffron) #9

More hax

It seems to be working better than the last round of hacks, so at least there is that.

Empty space in iOS11 when Smart Keyboard is used
(Chris Beach) #10

I think there’s different behaviour between the reply-to-topic and reply-to-post

This is reply-to-topic with Predictive enabled:

But reply-to-post is fine now:

(Sam Saffron) #11

You need to wait for my latest fixes to land, I fixed this.

(Sam Saffron) #12

Also, you may notice how the address bar shrinks… we need to magically account for that as well.

(Chris Beach) #13

Yikes. I don’t envy you guys here. It’s a really complex problem to solve.

I wonder if the best solution is a radical one. Move the Reply and Upload buttons to the top (position them absolutely so they’re not affected by scrolling). Then make the text box big - if it flows offscreen, this won’t be an issue provided we can keep the user’s cursor in view at all times.

(Sam Saffron) #14

Position fixed takes a break when you are entering text in a box

Go to Search results for '' - Discourse Meta start typing in box, notice how header is no longer fixed

(Chris Beach) #15

Ah, bummer, yes. I assume the same is true of a multi-line text box.

Perhaps there’s another way to position elements that is not overriden by text entry on smartphones.

I’ll have a fiddle and report back.

(Sam Saffron) #16

I am not sure anything exists but I would :heart: be proved wrong, it would make me super happy :sake: :sailboat:

In the meantime I just committed an amendment to that hack that accounts for “shrunk vs non-shrunk” address bar. It makes me feel quite bad about myself, but hey it works provided you are using a default keyboard and have predictive text on.

BIG address bar:

Small address bar:

:arrow_double_up: notice how is big in the top picture and smaller in the second one. When it is big … you also happen to have a footer on the page that eats up visible space for nav, so we just plug in numbers and :pray: for peace on :earth_asia:

(Chris Beach) #17

:+1: please let us know when this is released to meta and I’ll help test.

(Joshua Rosenfeld) #18

Not yet deployed. We’ve got a test failing that’s holding up the deploy. Will update when resolved.

(Joshua Rosenfeld) #19

FYI the build is fixed, Meta is up to date now.

(Chris Beach) #20

Looking better now. Still the gap (see screenshot) if Predictive is turned off, but no problems with buttons being hidden: