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.
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.
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.
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?
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.
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.
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 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?
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.
Is there anything that can be done on our side to mitigate it?