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.
Unrelated … this is just ios being SUPER annoying. I am going to reduce a few heights now.
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.
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…
I’m on iPhone 7, iOS 11 - glad you found the bug!
I am less glad … this thing just behaves totally randomly … it is mega annoying.
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:
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.
More hax
It seems to be working better than the last round of hacks, so at least there is that.
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:
You need to wait for my latest fixes to land, I fixed this.
Also, you may notice how the address bar shrinks… we need to magically account for that as well.
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.
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
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.
I am not sure anything exists but I would 
be proved wrong, it would make me super happy 
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:
notice how 10.0.0.55 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 
for peace on 
please let us know when this is released to meta and I’ll help test.
Not yet deployed. We’ve got a test failing that’s holding up the deploy. Will update when resolved.
FYI the build is fixed, Meta is up to date now.
