iOS 11 makes Discourse buggy?

Yeah the back swipe is brutal, maybe iOS 11.1 will fix? Back button works fine.

So far so bad… no fixes in sight.


@awesomerobot I wonder, can we try out:

What we found to be the best solution in our case is to keep the modal fixed, but to stretch it to the edges of the window, hiding the rest of the content in the body with display: none;. This would remove the problem of the body height being higher than the viewport and there would be no background scrolling when focusing on the input.

The bug here is really brutal on ios and its been more than a month now and still no fix.

Besides hiding stuff behind modal more aggressively on mobile seems like a good idea anyway.

1 Like

Sure we can try it out, looks like it should work — ultimately from a user’s perspective they’re no longer modals at that point. Would it be significantly more work to make those modals separate pages on mobile?


iOS 11.1 was released today, and the issue is still present.

Personally I think a dedicated login page would be ideal, but I’m happy to help implement either approach.


Wow, well if you want to give it a shot I am super happy to have mobile use a dedicated route / page for login. Warning though, the Ember stuff is like entering another world when you come from a server generated pages background, there is quite a curve getting used to double routers and so on.

It resolves the issue for ios mobile but would still leave some gaps on ios desktop (iPad).

I would recommend giving the modal hack on ios a shot first (always hide body when modals are open on ios) cause it is way easier of a change. Then see if you feel up to the whole dedicated route thing for mobile.


OK, this is “fixed” per:

I am using the term “fixed” here because it technically is Apple’s bug and I dislike contorting for them, that said, we just can’t have our “first experience” with Discourse be so flaky on a super popular device. It hurts us.

I think overall even without the existing iOS bug the experience on mobile is better, there is just almost no value in showing the “faded” page behind. That said it can probably be hacked so it’s positioned absolutely with an offset if the hack was a bit more sophisticated.

The hack applies to both IPhone and IPad.


Thank you @sam - definitely the right thing to do for the sake of users.

I’m very annoyed at Apple for this Safari bug and will keep an eye out for any forthcoming fix from them.

Is this a part of the generic iOS 11 woes, or a separate issue?

On the iPhone SE the composer’s last row falls behind the keyboard. iOS 11 + Discourse 1.8.

Yeah this is general woes, it is due to to apple refusing to give us APIs to tell us if the keyboard is there or how big it is.


Thanks @sam, it’s definitely much more usable now.

I did notice a small issue still… if you have external login buttons enabled, the scroll jumps a little when moving from the username to the password field, and the cursor on the password field is not visible.

This happens if you tap on the password field after entering your username, or if you use the down caret button in the keyboard toolbar to move to the next field.

If you tap the password field again after it gains focus, the cursor appears.


Hmm … I have no idea where iOS is putting the cursor.

After I click “email” and keyboard shows up, I can not see the cursor, start typing and suddenly the cursor appears again.

I may be able to trigger one extra focus event to work around this, not sure.

I don’t notice this when moving between fields on iOS 11.1, just when I first click the field and keyboard first shows up. Will see if there is a workaround.


The backswipe lag is still killing me :frowning: Is there anything that can be done on our side to mitigate it?

I’m also finding text cursor positioning issues. Am using the Discourse app, iPhone X. Seems the cursor doesn’t always correspond to where I tap when using the composer.

No doubt this is a problem caused by Apple rather than the Discourse team, but it would be good to find a workaround.

1 Like

I have seen some cursor positioning issues with the Staff Notes plugin. When the amount of content exceeds what can be displayed inside the textarea the cursor is sometimes located outside of the textarea.

It’s only a minor annoyance since I am able to scroll the content so that it’s inside the textarea on the rare times there is more than only a small amount of text.

You are having similar issues with the Core post composer textarea?

It happens sometimes, its not consistent, but when it does it is fairly annoying.

1 Like

It’s really, really annoying. The kind of problem I can live with as a committed and highly-invested user, but may be a dealbreaker for new / casual users.

1 Like

I don’t really agree with that, this is me replying from my iPhone X and it is very smooth, I have seen issues but do not have a clear repro

He’s referring to backswipe being a 4 second operation in iOS11. It is annoying, but the workaround is trivial: use the back button instead.

Oh I never use backswipe, that is why I don’t notice it

1 Like

iPhone SE has random but regular cursor or tap positioning issues. I have not found out what triggers them, but happens on daily basis. Somewhat annoying, especially for a moderator or admin.

If you guys have a test engineer on payroll, it might be and idea to perform thorough exploratory testing using this HW.

It is not our fault Apple ship buggy safari. I spent weeks already working around Apple bugs

How is a test engineer going to help here?