iOS 11 makes Discourse buggy?

Support

AI-generated summary

Multiple users have been experiencing issues with Discourse on iOS 11. TSR reported two specific problems: the back button in Safari behaves differently than swiping back, and the text box jumps down a line when trying to merge topics. ChrisBeach also noticed the back swipe lag and mentioned that the cursor doesn’t correspond to the tap location on dialogs.

sam linked to a tweet about the already reported issue of textboxes in position fixed and mentioned that the back swipe issue is an iOS bug. codinghorror agreed that the back swipe is brutal and hoped that iOS 11.1 would fix it.

sam suggested trying out a solution to keep modals fixed but stretch them to the edges of the window, hiding the rest of the content. awesomerobot agreed to try it out, and sam later mentioned that a dedicated login page could be a better solution.

The issue was “fixed” with a workaround in this commit, as sam explained. However, users are still experiencing other issues, such as cursor positioning problems and keyboard-related bugs.

ChrisBeach thanked sam for the fix and expressed frustration with Apple for the Safari bug. ljpp reported another issue with the composer’s last row falling behind the keyboard on iPhone SE.

sam explained that this is a general issue with iOS 11 and Apple’s refusal to provide APIs to detect the keyboard’s presence. tmm1 reported a small issue with the scroll jumping when moving between fields, and sam promised to look into it.

ChrisBeach reported text cursor positioning issues and backswipe lag, which Mittineague also experienced with the Staff Notes plugin. sam acknowledged the issue and ChrisBeach emphasized its importance.

ljpp reported random cursor or tap positioning issues on iPhone SE, and sam explained that it’s not their fault but rather Apple’s buggy Safari. codinghorror jokingly suggested that a test engineer would need to go to Cupertino to fix the issue.

sam shared links to articles about iOS 11 issues, and ChrisBeach found a reliable repro for the cursor positioning issue. sam reported that the swipe issue is fixed with iOS 11.3, which codinghorror found surprising.

1

Hello, long time reader, first time poster.

I’ve noticed iOS 11has managed to make Discourse a bit screwy in two ways.

A) press the back button in Safari has a different behaviour to swiping back. Back button is almost instant whereas swipe back goes to white page before showing previous page. A delay of a second or two.
B) When trying to merge to a different topic, the text box keeps jumping down a line until you are typing over boxes and buttons

Anyone else have here any of these bugs? I know it’s replicated by other users on a community I’m involved with.

2

I’ve noticed the back swipe lag too.

And when dialogs eg Change Timestamp are shown on iPhone, the cursor doesn’t correspond to the tap location on the dialog making it almost impossible to use.

3

Textboxes in position fixed is already reported

Back swipe is also an iOS bug, reproducible on mobile twitter or any site with lots of js

4

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

So far so bad.. no fixes in sight.

5

@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.

6

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?

7

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.

8

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.

9

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.

10

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.

11

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

IMG_0112
IMG_0112638×947 49.9 KB

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

12

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.

13

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.

14

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.

17

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.

18

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?

19

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

20

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.

21

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

22

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.