Issue with chat on iPads running iOS 12.5

Love the plugin. Great work.

I’ve found an issue with Discourse Chat on iPads running iOS 12.5. I recognise that Discourse is dropping support for this in January but as it is currently ‘supported’ I wanted to report it.

The issue presents as a UI problem but it appears to be deeper than that.

The UI Problem

The text entry space is not tall enough. This makes placing the cursor in the space very difficult.

See here…

Zoomed in…

The Usability Issue

The other issue, which may be related, is that even if you place the cursor in the space it does not signal that the chat message has been read. The blue/green read indicator at the top of the screen remains even if you’ve visited the chat channel. This obviously makes the chat difficult to use as you cannot draw someone’s attention to a message because the indicator is always on.


These issues both present themselves most of the time but I have also - occasionally - seen circumstances where the text entry space appears normal and placing the cursor in there clears the read indicator.

I can’t find a pattern for this inconsistency but it may be related to the differences between Personal Chat and Channels - but that may also be a read herring (pun intended).

The reason this is such an issue for me is that this instance of Discourse is used within a school by 10-12 users that have all been given iPads. I’ve asked that these be upgraded but they old and are maxed at iOS ~12.5. I’m told we’re stuck with these for a while yet - which is certainly going to give me an issue after January.


1 Like

Whilst I see this has been moved to a UX discussion category instead of a bug, I wanted to stress that this is not just a user interface / cosmetic issue.

As I mentioned above, the chat notification indicator does not clear even if the channel is visited and the cursor placed in the text entry space.

It’s as if a focus or similar event is not firing.


Support for iOS 12.5 ends in January. Discourse 3.0 is the last version which will support it, after which time users are going to see the read-only view.

As chat currently resides in a plugin I’m not sure how much effort is going to go into propping up chat on such old devices for only 3-4 months. Maybe one of the team can comment.

Thanks for the response, @Stephen.

Yeah, I can understand that - and I acknowledged their imminent end-of-life in the opening post. I was really looking for a formal position so I could make some plans.

I’d also like to know what’s involved. I can imagine that supporting such an old platform may just be too difficult but if it were a simple fix I’d love to see it implemented. I’d also be glad to help - if it fits within my limited skill set.

A couple of comments though.

When you say “only 3-4 months”, I would suggest that it would be possible (if maybe not desirable) to pin Discourse and the Chat Plugin to specific versions and run ‘happily’ for longer than that.

Obviously, I would need to consider the impact of not taking security updates, but budgets in UK schools are very tight and upgrading the iPads before, say, July of next year is unlikely to be an option.

Thanks again for sharing your thoughts.

tl;dr I’ve created a theme component that appears to get around the problem but would like to validate the CSS / approach I’ve used.


An update on this. I’ve created a simple theme component that I’m going to test live tomorrow but it looks like it makes Discourse Chat workable on iOS 12.5.

Shout-out to the good people at BrowserStack who graciously provided debug access to a cloud-based iPad running 12.x under their open-source program.

Whilst this solution seems workable, I’d really appreciate a review by anyone with real CSS knowledge as I’ve simply guessed and Google’d my way to this point.

What was happening?

I mentioned that the issue seemed to be somewhat ‘random’. It turns out that the size of the chat composer entry box is inversely proportionate to the entire height of the scrollable text (not just the visible text) in the chat messages container div.

So, if there aren’t many messages in a particular channel, the chat composer height appears normal. As more messages appear in the channel, so the chat composer height shrinks.

Additional issue

In addition to the shrinking textarea problem, I also noticed that the “back to channels” button (chevron / less than) was slightly out of alignment.

The solution?

For the “back to channels” button, the following CSS places it back in alignment…

div.topic-chat-float-container .chat-drawer .topic-chat-drawer-header {
    align-items: center;


Using BrowserStack I was able to target the shrinking chat composer container `div. I found that if I applied this CSS…

.chat-composer-container {
    flex-shrink: 0;

…it maintains the height of the chat composer container no matter what the size of the chat content.

Like so…

I’m happy to maintain the theme component for my iPad users on 12.5, but would just like to know if this CSS approach is valid / optimum / dangerous.



Good stuff!

I can’t comment immediately on that, but I have it on my list to discuss the questions you’ve raised more generally so we can respond here with a bit more clarity. It may take another week or two before we can respond to that more definitively though.


My general concern is that this is long term not feasible

Once we drop support from core in January, JS can start failing and this will not be fixable in a theme component


Yes, that makes sense.

For me, this will be a mid-term sticking plaster to get me into the next budget year when the school can hopefully get my users more capable iPads.

In fact, if Discourse Chat hadn’t been such a big hit with our users I would just ignore it, but it plays a perfect role in some of the processes we’ve automated.

I’m hoping to pin a working commit id for Chat and Discourse in app.yml come January and then try to limp across the line.


Thank you for providing context. Yes this certainly makes sense. I wish it was easier to support these devices or that Apple kept upgrading browsers independent of iOS.

Android do not have this problem … it is such an “Apple problem”