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.

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: UX: iOS 11 modals now hide all background committed 08:31PM - 07 Nov 17 UTC (UTC) [תמונה] SamSaffron +30 -0 This fixes issues where login looks very buggy on iOS see also: https://meta.di…scourse.org/t/ios-11-makes-discourse-buggy/71140/7 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? [IMG_0112] On the iPhone SE the composer’s last row falls behind the keyboard. iOS 11 + Discourse 1.8.

[תמונה] ljpp: 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.

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?

iOS 11 makes Discourse buggy?

Product Support

sam (Sam Saffron) 7 בנובמבר,‏ 2017,‏ 9:18pm 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.

נושא		תגובות	צפיות
Mobile Safari login woes Bug	1	958	31 באוקטובר,‏ 2017
iOS 26 bugs with fixed position elements in Discourse Announcements ios , ios-26	67	10563	7 בנובמבר,‏ 2025
iOS 26 bugs still persist on 26.1 Product Support ios , bug , ios-26	17	1474	23 בדצמבר,‏ 2025
Discourse Mobile App Product Support mobile , ios-app	1	333	24 בספטמבר,‏ 2025
Dealing with iOS 8 Mobile Safari bugs? Feature	63	31442	12 ביוני,‏ 2017

iOS 11 makes Discourse buggy?

נושאים קשורים