Also reported here: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Notifications_freezing_up_on_mobile_Firefox_(Android)

I can confirm that I've had this issue as well.

@Etonkovidova are you able to capture the console output from this particular scenario?

I was looking into this one and T231491: Help panel and Wikipedia beta intefers with each other (both issues about Firefox on Android). I need to re-verify it with test Android device.

This seems to have, if anything, gotten worse. Without thinking I clicked on them this morning (hey, I can't be responsible for what happens before I have my coffee :) ), and it entirely locked up Firefox, to the point no controls were responsive. I had to go in and force-stop and restart Firefox to get it back working.

If there are any logs or further details I can provide that would help in diagnosis, please let me know and I'll certainly do so. It is of course possible that this is a Firefox issue, but I do not run into any similar issues when, for example, clicking on Facebook notifications, and those have a similar dropdown format. I'm certainly happy to help any way I can; it's a bit of a pain to have to wait until I get to a computer to check those.

Thanks for filing this, @Stryn, and for uploading the video. Since multiple users are experiencing this, I think we can assume that several more are also experiencing it but haven't said anything.

I think the Growth team can look into this after our QA Engineer, @Etonkovidova, gives us a more specific read on exactly what's wrong.

In the meantime, @Stryn and @Seraphimblade, I know that a couple of us would appreciate hearing some more about why you prefer to look at notifications on desktop instead of mobile view (or why you're using desktop over mobile in general). CC @ovasileva @alexhollender.

In T223609#5476723, @MMiller_WMF wrote:

I know that a couple of us would appreciate hearing some more about why you prefer to look at notifications on desktop instead of mobile view (or why you're using desktop over mobile in general).

I always use the dekstop view because I work as a steward and I can't quickly revert revisions / block users in mobile view. Also, I need a global block feature and sometimes checkuser, they work much better in desktop mode.

My "home page" in mobile phone is the watchlist, and I always check all edits to pages that I follow since my last visit. I like many things more in desktop mode (like straight open the history link and check all revisions to page since last visit).
Also on fiwiki we have the pending changes feature enabled so I can easily check all pending changes in desktop mode.

So far as the question by @MMiller_WMF , I use the desktop version because:

• It's familiar. I'm used to Monobook for many years. I have no need to faff around with learning a different interface. It works just fine on mobile, aside from the above bug. I really don't care to have a different "mobile interface".
• It's more usable. I just tried clicking an "edit" link on mobile, and that does not support, for example, my Javascript modifications that provide syntax highlighting in wikitext. There might be a way to do the same thing in mobile, but clicking the "Desktop" link is an easy and convenient way to do it.

• I use links to Wikipedia articles for things I'm writing elsewhere. Wikipedia supports the "mobile" site in an outdated way, by putting the ".m." in the URL, and that will screw things up by giving desktop users the mobile site. If I'm using the desktop site, it won't do that.

• The mobile site does not provide an easy interface to administrative functions. Or at least if it does, I don't have the first clue how to use it, nor is it at all intuitive.

So, basically, I'm in the habit of scrolling to the bottom and clicking "Desktop" if I manage to land on the mobile version. There used to be a way to set that permanently (i.e., never see the mobile site at all after clicking that), and I protested when that was gone, but that never seemed to get anyone's attention. The mobile interface is just not really something that I look at and want to use.

The issue is reproducible with Google Pixel mobile device.

• it's impossible to notice that the icons have been clicked
• notifications load slowly - ~20-25s - but they finish loading and get displayed.

On iPhone (iOS 12)

• clicking on the notification badges is responsive
• notifications do not get displayed
  

On repeated attempts, the notifications are displayed briefly and then disappear.

Moving this task into Current Spring (Incoming) on Growth workboard.

@Etonkovidova testwiki seems like a "special" case here, because the layout is completely broken in desktop mode on iOS Safari. If I look at Mediawiki.org or en.wikipedia.org on iOS Safari, the notifications load quickly and without issue. If we work on this task I would propose that we limit the scope to mobile Firefox.

In T223609#5483381, @kostajh wrote:

@Etonkovidova testwiki seems like a "special" case here, because the layout is completely broken in desktop mode on iOS Safari. If I look at Mediawiki.org or en.wikipedia.org on iOS Safari, the notifications load quickly and without issue. If we work on this task I would propose that we limit the scope to mobile Firefox.

Agree, testwiki does look like a special case.

Thanks, @Etonkovidova. Moving this to Ready for Development so we can take a look at it at our next opportunity.

Moving off sprint board in favor of Newcomer Tasks V1.0 tasks.

@Etonkovidova could you please check if this issue is reproducible in Firefox Preview?

I'm curious also if Special:Notifications has the same issue.

There is same slowliness in notification buttons in Firefox Preview.
Special:Notifications seems to open without any problems on normal Firefox mobile version.

I can't even use desktop mode in Android Firefox; it tells me that I need to enable cookies first (but they are already enabled). I'm not familiar with mobile Firefox, is there some extra privacy feature that needs to be disabled?

In T223609#5752831, @Tgr wrote:

I can't even use desktop mode in Android Firefox; it tells me that I need to enable cookies first (but they are already enabled). I'm not familiar with mobile Firefox, is there some extra privacy feature that needs to be disabled?

There is some bug in Firefox mobile since months ago that sometimes it won't allow to save any cookies, usually just opening the browser again will fix it.

In an emulator provided by Android Studio (Pixel 2, Android 10.0) with the most recent version of Firefox from the play store, everything works fine of course :(

@Stryn and @Seraphimblade to confirm, you've been able to reproduce this with safemode in the URL, correct?

The issue is reproducible with Google Pixel mobile device.

@Etonkovidova which version of Android were you running?

In T223609#5754053, @kostajh wrote:

@Stryn and @Seraphimblade to confirm, you've been able to reproduce this with safemode in the URL, correct?

It's not changing anything.

@Stryn what version of Android? What device do you have?

Just as a data point as a thread follower, I'm using an LG G5, Android 7.0, Firefox 68.3.0, on Timeless skin, and I cannot reproduce the problem on en.wp. Either a) the dropdown displays with notifications or b) I beat the JavaScript loading and get dumped on Special:Notifications, where the notifications also display.

I have Samsung Galaxy S9+, Android 9, Firefox 68.3.0 (but same problem in Firefox Beta, Firefox Preview), Vector skin.
I tried to use the timeless skin, and there the notifications opened faster and didn't make the browser to freeze.

@kostajh The issue is reproducible in FF 71 mobile emulator on any device (Android or iPhone) with sufficiently narrow screen.

1. On FF switch into Mobile emulator, but keep the desktop view.
2. Click on the Notification icons - the blank flyout will be displayed

The animated gif shows the notifications flash and disappear:

@Etonkovidova those issues should be sorted out by T241090: Echo rendering issues on desktop Minerva, not usable on mobile. With the emulator, I'm not able to reproduce the slow opening after tapping a notifications button.

In T223609#5773548, @kostajh wrote:

@Etonkovidova those issues should be sorted out by T241090: Echo rendering issues on desktop Minerva, not usable on mobile. With the emulator, I'm not able to reproduce the slow opening after tapping a notifications button.

Re-checked - it does seem that the patch in T241090: Echo rendering issues on desktop Minerva, not usable on mobile fixed the issue. Closing as Resolved.

@Etonkovidova did you mean to close this task also? I'm not sure we should, because from T223609#5754823 it sounds like there is still a problem with that particular Android + browser + Vector and slowness of opening the notifications.

@Stryn sorry to ask you to keep debugging this, but if you have time could you please create a new account and see if the slow JS loading is reproducible with it?

I created a new account but it's a bit difficult to debug because you need more than just a few notifications to see the slowness. More notifications make it more slowlier. Even after a few notifications it gets a bit slowlier and buggy.

I had tested this before with my other account (a bot account), and there's similar slowness as with my main account.

Maybe the emulator that Etonkidova used is not really accurate with my devices as my notifications never disappeared.

I don't see any obvious problems in the code, nor when profiling opening the menu. One option I was experimenting with is rendering the notification widgets (each row, basically) one at a time; currently the code prepares all of the widgets and then renders them at once. I'm not sure it would make such a big difference though.

Maybe the emulator that Etonkidova used is not really accurate with my devices as my notifications never disappeared.

Never disappeared or never appeared?

I created a new account but it's a bit difficult to debug because you need more than just a few notifications to see the slowness. More notifications make it more slowlier. Even after a few notifications it gets a bit slowlier and buggy.

How many exactly? I've been testing locally with about 100 notifications.

After tapping a notification button and encountering the slowness / browser lock-up, then closing the notification window, then tapping the same notification button, is it again slow to open?

From debugging locally, and looking closely at the video @Stryn posted it seems like the unresponsive part is right before the process dialog renders, and indeed looking at a performance profile locally it looks like the slowness is with rendering and not anything with scripting and assembling the notification widgets.

Maybe the emulator that Etonkidova used is not really accurate with my devices as my notifications never disappeared.

Never disappeared or never appeared?

Never disappeared. As you can see from the video I uploaded, you can actually see the notifications. It's not blank for me like it was in a gif by Etonkovidova.

I created a new account but it's a bit difficult to debug because you need more than just a few notifications to see the slowness. More notifications make it more slowlier. Even after a few notifications it gets a bit slowlier and buggy.

How many exactly? I've been testing locally with about 100 notifications.

It should make it already slower.
I have 1144 local alarms (including only talk page messages, because it can't be turnt off) on the Finnish Wikipedia (I turnt off the global ones and all possible notifications from preferences to check if it have any affect). But notices is possible to set to show only for example messages in "structured discussions" boards; anyway even I have only a few of those messages it takes some time to finish rendering. See the video when I have only structured discussions enabled on notifications: https://www.youtube.com/watch?v=ymp4gc5nuKc&
It takes about 15 seconds to load (or render) those notifications. Then after I start scrolling the page the notifications gets a big laggy.

I have an other video where I used my test account (with about 20-30 notifications). It first was loading pretty quickly, but later taking more time, see: https://youtu.be/oj2eYx2Lt1o?t=58

Thanks for the videos @Stryn and for your time on debugging and responding here.

I spent some time doing a broader search for slow Firefox performance on Android and ended up finding quite a bit, supposedly due to be resolved with Firefox Fenix (now in Firefox Preview) but apparently it's not fixed since you tested that. This problem doesn't exist when you use Chrome (or Firefox Focus, based on Chrome's browser engine) correct?

One thing that stands out from the videos you posted is that the rendering of the notification icons seems to cause a significant lag, but that's not the whole problem. It seems like Firefox on Android can't handle redrawing the overlay with content underneath, nor scrolling within the overlay.

Unfortunately given the overall low usage of Firefox on Android for wikimedia sites I'm not sure we can prioritize debugging this much more, much as I personally would like to see this issue fixed for you.

@Stryn @Seraphimblade @Izno -- we really appreciate the effort you've put into helping us try debug this issue. We're frustrated and disappointed that it doesn't look like there's much we can do on our end to fix it, especially given the importance of the work you're doing with notifications from mobile. After putting a lot of time into this, at this point, it looks like the Growth team has to move on to other work and other bugs. Does this sound okay to you?

One more idea might be to check the viewport size (or maybe just OO.ui.isMobile()) and make the dialog a full screen overlay, so the mobile browser has less work to do in rendering during load and scroll time. That's probably the direction I would try next, but for now have to move on to other tasks.

I can't reproduce this problem anymore, so I think this task can be closed.