Firefox 55.0.3 repeatedly almost entirely unresponsive on KDE Plasma 5 (5.10.5) with KWin from Area 51, worked around by disabling an extension (Multi-Account Containers 4.0.1)

grahamperrin · October 5, 2017, 2:59am

https://github.com/mozilla/testpilot-containers/milestone/6 was the AMO Launch milestone. Please, will the launch be mentioned at https://testpilot.firefox.com/experiments/containers or amongst the Latest updates at https://testpilot.firefox.com/experiments?

https://github.com/mozilla/testpilot-containers/commits/master I see 4.0.0 but no mention of 4.0.1.

If 4.0.0 was installed before the transition to addons.mozilla.org: how might I tell when it was installed?

If not 4.0.0: how might I tell when any recent predecessor to 4.0.1 was installed?

https://addons.mozilla.org/firefox/addon/multi-account-containers/versions/?page=1#version-4.0.1 no release notes, will notes be provided?

Apparent issue with 4.0.1

https://addons.mozilla.org/firefox/compatibility/reporter/@testpilot-containers?works_properly=0&appver=55.0

With 682 tabs across 12 windows, Firefox repeatedly, consistently failed to restore the session. The first successful restoration occurred immediately after I disabled Firefox Multi-Account Containers (leaving 86 other extensions enabled).

Firefox 55.0.3 (64-bit) on FreeBSD-CURRENT. The first three screenshots below show some of the symptoms. Essentially:

on every occasion, the application became almost entirely unresponsive

– it might have been possible to close a window, with a very slow response to the close action, but it was not possible to quit. Memory leaking might have been a factor – if left long enough, there’d be excessive use of memory followed by a crash of Firefox. On some occasions instead of waiting for the crash, I chose to (SIGTERM) kill the process.

Following the successful restoration (with Firefox Multi-Account Containers 4.0.1 disabled), a Session Manager retrospective of some recorded crashes:

groovecoder · September 7, 2017, 1:34pm

Please, will the launch be mentioned at https://testpilot.firefox.com/experiments/containers or amongst the Latest updates at https://testpilot.firefox.com/experiments?

Yes. We are testing the 4.x release on AMO right now, and when we’re comfortable with it, we will update the Test Pilot pages with “graduation” posts - like past experiments.

If 4.0.0 was installed before the transition to addons.mozilla.org: how might I tell when it was installed? If not 4.0.0: how might I tell when any recent predecessor to 4.0.1 was installed?

Were you automatically updated to 4.x on Test Pilot? Right now you should only get the 4.x release on AMO or by installing it manually from the GitHub releases.

When we’re comfortable with 4.x on AMO, we will ship a last 3.x update via Test Pilot which will remove the Test Pilot updateURL - effectively switching all Test Pilot users over to future updates from AMO.

Apparent issue with 4.0.1

Can you file this on the GitHub repo?

grahamperrin · September 7, 2017, 6:48pm

~~Apparently so. I mean, it was a surprise to find an installation associated with AMO.~~

Afterthought: the automation was probably with Firefox Sync.

From about:support on 2017-08-29:

Name: Testpilot containers
Version: 3.1.0
Enabled: true
ID: @testpilot-containers

The same ID is used for the extension with the different name on AMO.

Is there any way to tell the installation history for an extension?

groovecoder · September 7, 2017, 6:54pm

We used the same ID on purpose to make the migration from Test Pilot to AMO smooth - apparently we made it TOO smooth!

Not sure how to find installation history for extensions.

grahamperrin · September 8, 2017, 3:39am

Understood, thanks.

tl;dr this type of bug will probably be hideously difficult to reproduce. In this situation I’d normally shelve the issue, without a proper report, but the overall behaviour of Firefox – not entirely unresponsive – made me curious, so this morning I spent around three hours troubleshooting. Twenty-eight screenshots, and so on …

… if I attempt a set of written notes, I’ll lose the mental overview. Instead I’ll make a separate post (below) with just two of the twenty-eight shots.

Side note: AMO and restraint

If you want an example of restraint, where a more recent version of an extension is available but automation does not apply, maybe consider Diigo. https://addons.mozilla.org/addon/diigo-web-collector/versions/ – Diigo Toolbar (2013-02-27) was succeeded by Diigo Web Collector - Capture and Annotate (2017-07-19). Neither automated nor manual checks drew attention to this year’s major update …

… I guess, because the start of the Version string is numerically inferior to its predecessor:

Name: Diigo Toolbar
Version: 5.1.0.38.1-signed.1-signed
Enabled: true
ID: {fc2b8f80-d9a5-4f51-8076-7c7ce3c67ee3}

Name: Diigo Web Collector - Capture and Annotate
Version: 3.3.56
Enabled: true
ID: {fc2b8f80-d9a5-4f51-8076-7c7ce3c67ee3}

Notes to self:

diigo_toolbar_annotate_screenshot_bookmark-5.1.0.38-fx.xpi set aside 2017-08-26
3.3.56 abandoned yesterday (back to the 2013 version with its superior set of features).

grahamperrin · September 8, 2017, 5:45pm

From this morning’s test session

rough notes
not intended to be comprehensive
expect edits to this post.

02:49
Virtual desktop 5, not long after ceasing Folder View for the wallpaper of the non-primary display where part of a window of Firefox is invisible

some time before that screenshot, I clicked the NEW-badged toolbar button for (WebExtensions) Diigo … 3.3.56
the button gained its clicked/pressed appearance but its menu failed to drop down
attention to the non-primary display, which should have showed part of the right-hand part of the window, including the toolbar button for another extension
immediately after I changed the wallpaper for that display, the visible part of the window (in the other display, to the left) redrew, with the page about Diigo, and Firefox became responsive
icons for containers are within the sidebar of Vertical Tabs Reloaded.

03:36
Overview of virtual desktop 5, pointing at the fifth window of Firefox

from the miniaturised view of that window, I could tell that it would not fit in either display
no longer using the Firefox 57-compatible version of Diigo
using legacy Diigo Toolbar.

03:38
Virtual desktop 5, fifth window of Firefox

grahamperrin · September 8, 2017, 10:04pm

My local records of about:support show:

Containers Experiment 2.4.1 present 2017-08-13 05:45
Testpilot containers 3.1.0 present 2017-08-28 10:13.

Plus:

3.1.0 was mentioned on 2017-08-22 at https://github.com/mozilla/testpilot-containers/issues/665#issuecomment-324087823
I have ZFS snapshots of my home directory, e.g. @20170901-1310 and @20170906-1111, which will include version information for the extension at those times, but I don’t plan to delve so deep.

@groovecoder please, is there any quick and easy way to summarise changes between … let’s say, 3.1.0 and 4.0.1? Or between 3.1.0 and 4.0.0, or 4.0.0 and 4.0.1? (If no quick and easy way, I guess that https://github.com/mozilla/testpilot-containers/commits/master is the place to look.)

From the fourth screenshot in the opening post it appears that 4.0.1 was installed after problems began. Whilst it’s certain that problems ended after I disabled that version of the extension, I can’t tell whether installation of something between 3.1.0 and 4.0.1 was contributory to the beginning of problems.

groovecoder · September 11, 2017, 12:14pm

We’ve done a better job of tagging the recent releases, so you can use the GitHub compare feature and provide the version numbers. E.g.:

will show all the commits between 3.1.0 and 4.0.1

grahamperrin · September 11, 2017, 8:29pm

Cool. Thanks.

I see https://github.com/mozilla/testpilot-containers/commit/da3fc2ede27482ca4042b21aa9cf96d321b994fe bump version to 4.0.0 on 2017-09-05 …

… and through browsing raw data at about:healthreport I find that the step from 3.1.0 to 4.0.1 (no sign of 4.0.0) occurred a day or two later. The head of the relevant .main.jsonlz4 file, which I have set aside:

{
  "type": "main",
  "id": "26e821a1-296b-4a96-ab21-78115afaf905",
  "creationDate": "2017-09-07T00:20:37.668Z",
  "version": 4,
  "application": {
…

I have half an eye on a very recent containers icon-related comment in sidebar-related Mozilla bug 1385630:

… think the restart path used by updates is breaking both the sidebar and the Containers test pilot.

With what I found in the datareporting area of my profile, I’m now more certain that the update from 3.1.0 to 4.0.1 simply occurred in the midst of problems; and that I got lucky when disabling 4.0.1 allowed things to return to normal.

Since then, with 4.0.1 enabled, I have had no session restoration difficulty that can be associated with 4.0.1.

grahamperrin · October 2, 2017, 6:58am

I changed the category and title of this topic.

tl;dr non-conclusive, but I suspect that the problem(s) affecting responsiveness of Firefox will not recur with versions 5.10.95 or 5.11 of KDE Plasma.

The few points below may be most relevant.

https://matrix.to/#/!GdmnfkDxuKZAICnOhe:matrix.org/$15055006087348547uRNWp:matrix.org (2017-09-15) reminds me that in mid-September I gained, from Area 51, an update from Plasma 5.10.5 to (beta) 5.10.95 and since then, I have found nothing like the sets of symptom that were found when I began this topic.

In particular:

– nothing like that invisibility. Instead, it seems to me that kwin with Plasma 5.10.95 is more likely to occasionally produce windows that are unusually small when restoring a session of Firefox with many windows.

An example of that smallness is in this overview (2017-09-22 08:44:34):

– most noticeable in the first quarter of the fifth virtual desktop.