Page MenuHomePhabricator

The messages panel cannot be closed anymore on iOS
Closed, ResolvedPublic


There is an annoying bug in Wikipedia. This seems to be a recent regression.

I am on some page on http(s)://
I click the Message button at the top.
Over the page, comes the messages panel.
Then, I click again the Message button at the top.

Usually, that closes the messages panel.

Now, that does nothing.

Clicking on the page outside of the messages panel does nothing either.

So I cannot anymore close the messages panel.

I expect to have a way to close the messages panel.

It would be nice to repair that.

Thank you.


Event Timeline

Nnemo raised the priority of this task from to Needs Triage.
Nnemo updated the task description. (Show Details)
Nnemo added a project: MediaWiki-General.
Nnemo added a subscriber: Nnemo.

I have Safari on iOS 8.2 on an iPad in landscape, with the reading list open on the left.

Nnemo set Security to None.

I expect to have a way to close the messages panel.

I too am experiencing the same issue across all ios devices while using the desktop mode. Tried both safari and chrome. Works fine on android.

Mattflaschen-WMF renamed this task from The messages panel cannot be closed anymore to The messages panel cannot be closed anymore on iOS.Sep 29 2015, 7:00 PM

Confirmed(iPad mini iOS 8.2 Safari/600.1.4 and other)

  1. The issue is present in Desktop mode; MobileView works
  2. In Desktop mode - the notification overlay get stuck - until a page is refreshed.
  3. betalabs - clicking on the Alerts/Messages icons - the overlay goes away; clicking outside of the overlay - does nothing.

The issue is twofold:

  1. The Echo popup should be closed when you click the badge again. This is/was a general bug that is fixed in master and will be deployed everywhere this week.
    • This also is fixed in iOS safari. The popup can be toggled on/off using the badge (With the new fix)
  2. OO.ui.PopupWidget (in general) seem to have a general bug in iOS Safari where they can't be dismissed when losing focus despite the configuration option. This is an OOUI bug. You can reproduce it by loading the ooui demo page in iOS Safari and see that all popups cannot be dismissed with mouseclicks on the page itself, even though they do that when viewed in any other browser.

The first issue will be fixed in the next deployment. The second should be fixed in OOUI.

Change 244592 had a related patch set uploaded (by Mooeypoo):
PopupWidget: Listen to 'touchstart' for 'mousedown' events

@Mooeypoo: This task has been "Unbreak Now" priority for two months. The Gerrit change has not seen any updates for six weeks.
Are there any news / progress to share?
Is the current priority correct (does not seem so)? Thanks.

Catrope lowered the priority of this task from Unbreak Now! to High.Dec 16 2015, 2:02 AM
Catrope added a subscriber: Catrope.

We've changed the priority, but we need to make a decision here, and the notes on the gerrit patch are a little confusing.

First of all, this bug is slightly misleading. As far as I could see, the main bug (about not being able to close the popup at all) was partially fixed by us making sure that clicking the BADGE closes the popup. This, as far as I can see, works on all platforms, as do all buttons.

In that aspect, this ticket is not as urgent as it was before this fix.

However, we still need to come up with a proper solution here, but the options are not encouraging (?)

Here's a brief summary as far as I understand it, let's try and see how to work through this:

  • We have a problem where Safari iOS, and it ALONE (no other browser and OS) does not understand 'mousedown' events.
  • Listening to 'touchstart' event so that Safari iOS behaves nicely produces regressions in other browsers. That's not a proper solution.
  • Listening to both 'touchstart' and 'touchend' produce issues with scrolling. If we do use those, we should also implement 'touchmove' (@matmarex, please correct me if I'm wrong)
  • Listening to 'click' won't be the best solution either, for the same reason as above, in terms of scrolling (again, correct me please if needed)

What do we do, then? It sounds like this is a general issue of popups that we will have to rewrite the way the events are handled. We either have some sort of "iOS only detection" for mousedowns (meh solution, to say the least) or we have to find something that works across the board, consistently, with all browsers -- or at least as much as possible. That will also probably require rewriting some of OOUI.

Speaking of which, now that Echo popup is closing with clicking the bagde, this bug should probably be tagged as an OOUI bug, as it is probably affecting all popups.

@matmarex and @Catrope, your input please on how to proceed here.

Assuming that it works reliably on iOS Safari, I think changing OOjs
UI to listen to click rather than mousedown here would be the best
solution. I don't think it interferes with scrolling - browsers
apparently delay the click event while waiting to see if you begin
scrolling, but that's okay.

If that won't work, we can instead listen to touch events and detect
scrolling ourselves - touchstart sets a global counter to 0, touchmove
increments it, and touchend closes the popup if the counter is 0. Not
sure if we need anything more sophisticated?

Pinging @Catrope re strategy on fixing this and prioritization for implementing whichever solution.

Pinging @Catrope re strategy on fixing this and prioritization for implementing whichever solution.

@Catrope: Any feedback?

Looks like this task gets postponed every quarter again, though the comment in 2015 says "we need to make a decision here"...? :)

Change 437765 abandoned by Mooeypoo:
PopupWidget: Listen to 'click' for 'mousedown' events in iOS

This was supposed to be an override of an older commit rather than its own, see Ib4550f3c15eecca56a11a739a57d4cd920e3db73

Change 244592 merged by jenkins-bot:
[oojs/ui@master] PopupWidget: Listen to 'click' for 'mousedown' events in iOS

Re-checked - the issue is not present anymore.