Simple-tab-groups: (1694699) Firefox 86.⋯: conflict with any of six other extensions: loss of tab content after Simple Tab Groups loads a multi-tab group into an additional new window

Created on 20 Feb 2021  Â·  35Comments  Â·  Source: Drive4ik/simple-tab-groups

Overview (postscript)

Apparent conflict with six or more extensions. Not reproducible with Firefox 85.0.2, fixed in Firefox 87.

Jump to:


Description

With Simple Tab Groups, Duplicate Tabs Closer, FoxyTab and (many) other extensions enabled, grouped tabs are:

  • sometimes apparently detected as duplicates; and
  • later, each one of these becomes a 'New Tab'

– and then if the duplicates (the blanks) are closed, the affected groups become empty (or nearly empty).

As far as I can tell, this problem began after I gained an update to Firefox from 85.0.2 to the first pre-release port to FreeBSD of 86.0.

Reproducibility

I'm struggling to make this consistently reproducible. I aim to do so as soon as possible.

Images

Frames from a screen recording.

1,404 tabs, 111 of which are in the _FreeBSD_ group:

image

109 duplicates, apparently:

image

With the number of duplicates apparently up to 191, after opening other groups into third and fourth windows:

image

After closing the fourth, third and second windows, where previously there were titled duplicates, now it's a mass of 'New Tab':

image

After quitting then reopening Firefox, a click to close the duplicates:

image

– leaving the three recently used groups (_Firefox_, _FreeBSD_ and _helloSystem_) almost completely empty:

image

Environment

Simple Tab Groups 4.7

% pkg query '%o %v %R' firefox
www/firefox 86.0,2 FreeBSD
% freebsd-version -kru
14.0-CURRENT
14.0-CURRENT
14.0-CURRENT
% date ; uname -a
Sat 20 Feb 2021 11:17:28 GMT
FreeBSD mowa219-gjp4-8570p 14.0-CURRENT FreeBSD 14.0-CURRENT #14 main-f44e67d120: Wed Feb 10 23:57:02 GMT 2021     root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
% 

Recently updated extensions:

image

All 35 comments

Good news.

With a _test_ profile, importing from a backup that was produced by my (everyday) _default_ profile, just one other extension enabled (Sidebar Tabs):

  • I can not reproduce the issue.

With my _default_ profile, after disabling a few extensions:

  • the issue seems to be avoidable if I restrict myself to a single window

– the buggy New Tab effect occurs after closing any additional window into which a group has been opened.

I'm inclined to close this, as _not an issue with Simple Tab Groups_, however I'll leave it open a little longer in case it's an extensions conflict.

Unskew My Search

https://addons.mozilla.org/addon/unskew-my-search-ff/ refers to https://www.unskewmysearch.com/ for support, the server is not found. I'll e-mail the developer with reference to this screen recording:

https://user-images.githubusercontent.com/192271/108603745-a16aec00-73a1-11eb-87fe-5192a6ae7d5e.mp4

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/86#changes_for_add-on_developers unless I'm missing something, no explanation for the change in behaviour between version 85.0.2 and 86 of Firefox …

@fregante wrote:

It happens with any other extension enabled,

Not so.

Around one hundred other extensions are enabled without triggering this effect in Simple Tab Groups.

I spent many hours methodically identifying the individual extensions that trigger the effect.

Refined GitHub is in the minority.

https://github.com/Drive4ik/simple-tab-groups/issues/779#issue-812588512

With Simple Tab Groups, Duplicate Tabs Closer, … enabled, grouped tabs are:

  • sometimes apparently detected as duplicates; …

https://github.com/Drive4ik/simple-tab-groups/issues/779#issuecomment-782650906

…
– the buggy New Tab effect occurs after closing any additional window into which a group has been opened.

… extensions conflict.

Duplicate Tabs Closer as an aid to diagnosing the issue

Set the scope of the extension to all windows.

Below, four consecutive frames (split-seconds apart) from the screen recording at https://github.com/sindresorhus/refined-github/issues/4001#issue-812667500

  • in the first two frames, the number 0 on a blue badge (no duplicates)
  • in the third, the number 20
  • in the fourth, the number 20 on a red badge

2021-02-20 16:24:59 frame a

2021-02-20 16:24:59 frame b

2021-02-20 16:24:59 frame c

2021-02-20 16:24:59 frame d

From the titles of tabs alone, it's not possible to tell that duplication has occurred:

  • imagine twenty of the titled tabs having an _underlying New Tab state_.

In this situation, it's possible to prevent loss of the twenty tabs by loading all titled tabs. Either:

  1. click each tab, one by one (and observe the number in the red alert drop, one by one); or
  2. select all tabs in the window then use the tab context menu to reload all tabs.

The same screen recording, five or six seconds later (16:25:05). Two more frames:

2021-02-20 16:25:05 frame a

2021-02-20 16:25:05 frame b

  • uppermost in the first frame is a New Tab with a Firefox icon – this tab is outgoing as part of the normal process through which Simple Tab Groups loads a group into a window
  • uppermost in the group is a tab in the GitHub domain
  • the New Tab at the foot is _not_ in the GitHub domain (it shows the title of the page a split-second later).

With the GitHub domain in the first (uppermost) tab that will be lost, does this help to understand why the Refined GitHub extension is involved in the conflict in my case?

From the description of Mozilla bug 1692501 - reopen all windows doesn't restore all tabs:

[Actual result:]

Both windows are opened but one has only one tab open.

– regressed by 1589102 - Fix loads that inherit principals - about:blank and about:srcdoc - and make them go via DocumentChannel (Milestone: 82 Branch)

If I ignore the branch (82), the _written actual result_ is vaguely comparable to what's observed in this issue #779 however the video for bug 1692501 shows that the one tab is about:blank – in other words, _all_ tabs of the required window are lost.

Here in #779 one tab is not lost.

Vaguely comparable, but I don't suspect a common root cause. I'll hide this comment as off-topic.

… With the GitHub domain in the first (uppermost) tab that will be lost, does this help to understand why the Refined GitHub extension is involved in the conflict in my case?

As far as I can tell: that's not a factor.

The issue is reproducible with a clean (refreshed) profile with no import of any tab, and no GitHub tab in a window from which tabs are lost.


Confirmed not reproducible with Firefox 85.0.2 on FreeBSD-CURRENT.

A screen recording of the same profile, bug-free, after booting an environment that preceded the update to Firefox:

https://user-images.githubusercontent.com/192271/108629955-434e0f80-745a-11eb-9e59-5ad3dde915ab.mp4

Reproducible with version 20.9.10 of Refined GitHub, from the foot of https://addons.mozilla.org/addon/refined-github-/versions/

Older versions exist however https://github.com/Rob--W/crxviewer/issues/105 I can not easily get their URLs at the moment.

Reproducible with current version 21.2.19 of Refined GitHub with outdated (previous) version 4.6.2 of Simple Tab Groups.

At this point I realised: probably no loss when quitting Firefox. If users quit more often than they close windows, this might explain why encounters of the issue are not widespread.

Next up: debug logging with the current version.

Debug logging

Initially – with a test profile (very few tabs, probably less than ten)

Whilst the debug feature of Simple Tab Groups 4.7 was enabled:

  • the bug was not reproducible.

After debugging was disabled:

  1. decline the invitation to save the log
  2. the bug became immediately reproducible.

With my everyday profile (1,394 tabs at the time of writing)

With the debug feature of Simple Tab Groups 4.7 enabled:

  • the bug is reproducible …

@Drive4ik and friends hi, here's a debug log. .json renamed to .json.txt for compatibility with GitHub.

In this case, the bug – with Refined GitHub enabled – was observed in a new window after loading group 100, which comprises eight tabs.

"load-group-100"

  • first appearance at line 2,761 of 3,901
  • second and final appearance at line 3,659

STG-debug-logs.json.txt

  • logged with my very heavily loaded profile.

NB https://github.com/Drive4ik/simple-tab-groups/issues/779#issuecomment-783691509 whilst the issue _is_ consistently reproducible with very few tabs, it is _not_ reproducible with so few tabs whilst debugging is enabled.


Confirmed, for me: the issue is not reproducible with Firefox 85.0.2.

Yesterday I corresponded with someone at Mozilla, they suggested raising a bug there to tell what (if anything) has changed to cause or expose this extensions conflict.

Re: https://www.freshports.org/www/firefox/#history (currently _switch to rc2_ with reference to https://hg.mozilla.org/releases/mozilla-release/pushloghtml?startdate=2021-02-16&enddate=2021-02-18), it will probably make sense for me to wait until the port to FreeBSD is based on _release_ 86.0 of Firefox.

Re: https://old.reddit.com/r/firefox/comments/loptje/firefox_86_extension_conflicts/go7pmdd/ early indications are that at least one other user, not with FreeBSD, may be affected; "… pretty sure it never happened before 86 beta. …".

https://github.com/Drive4ik/simple-tab-groups/issues/779#issuecomment-783684125

… probably no loss when quitting Firefox. If users quit more often than they close windows, this might explain why encounters of the issue are not widespread. …"

https://github.com/Drive4ik/simple-tab-groups/issues/779#issuecomment-783606367

Reproducible with version 20.9.10 of Refined GitHub, …

Not reproducible with archaic version 1.19.0 of Refined GitHub – https://addons.mozilla.org/firefox/downloads/file/653773/refined_github-1.19.0-an+fx.xpi

  • from 2017
  • I do not suggest use of so old a version
  • the comparison is for test purposes only.

Does this mean I'm better quickly change the update method of Firefox to manual? (I already did, just in case)
Because 86 has been rolled out today

Good question. I shouldn't be alarmist.

If you don't use any of the six extensions with which I find a conflict, you might be OK.

Duplicate Tabs Closer seems to be an ideal barometer:

  • customise your toolbar, place the extension's button somewhere prominent
  • set the scope of the extension to all windows.

Then if you update to Firefox 86.0:

  • a red alert from Duplicate Tabs Closer – when you load a group into a window – may indicate that the bug is biting.

If you don't use any of the six extensions with which I find a conflict, you might be OK.

I haven't found the 6 extensions. Could you link a comment where you have listed them?
Also, I use a ton of extensions so it might be dangerous.

Oh they're in the reddit post. Why was the first 6 extension striked through?

https://old.reddit.com/r/firefox/comments/loptje/firefox_86_extension_conflicts/go7hyx0/ refers to a developer-provided shortlist of six extensions that are _generally_ conflicted. Those are the six that I struck through.

The six extensions that appear to be in conflict with Simple Tab Groups with Firefox 86.0

See above, under https://github.com/Drive4ik/simple-tab-groups/issues/779#issuecomment-782650906 – linked (cross-referenced) issues for five of the six.

Without links, the shortlist:

  • Open in Reader View
  • Refined GitHub
  • Threads for YouTube
  • Translate Web Pages
  • Unskew My Search
  • Want My RSS

https://github.com/Drive4ik/simple-tab-groups/issues/779#issuecomment-785432989

… I use a ton of extensions …

Would you like to share a list of enabled extensions?

You can use Add-on List-o-matic 9000:

  • just the names
  • hide disabled add-ons
  • sort by name.

NB just the names, please don't include version info or any other information. Thanks.

I wouldn't really feel safe after publishing my list of extensions, but also I'm still on 85.0.2 so I don't know if STG would break by any of the other extensions that I use.

When I raised this issue, I used a pre-release version of Firefox 86.0 on Tier-3 FreeBSD 14.0-CURRENT.

The conflict is now reproducible with:

  • Refined GitHub 21.2.23
  • Simple Tab Groups 4.7

– added to Firefox 86.0 on 64-bit Manjaro Linux.

Regression in Firefox

â–¶ Mozilla bug 1694699 - Investigate tabs API regression in Firefox 86

RESOLVED FIXED

88 Branch

https://wiki.mozilla.org/Release_Management/Calendar#Future_branch_dates = 2021-04-20 for Firefox 88.

Awaiting advice about the possibility of mitigating in the meantime:

Regression in Firefox

â–¶ Mozilla bug 1694699 - Investigate tabs API regression in Firefox 86

RESOLVED FIXED

88 Branch

So the fix will come in 88. That means that I better not update until that, right?
Also, from this comment it seems like that besides normal STG usage, the bug only occurs if a tab is unhidden in a different window than in which it was hidden, AND it's url is read after the moving of it, but before unhiding. Do I understand it correctly?

@MPeti1 what's your operating system?

I'm using Windows. I always have 2 windows of Firefox open, sometimes more.

https://bugzilla.mozilla.org/show_bug.cgi?id=1694699#c26

Beta/Release Uplift Approval Request

@MPeti1 if you like:

  1. https://support.mozilla.org/kb/install-older-version-firefox set aside a full installer for Firefox 85.0.2
  2. exit Firefox
  3. backup your profile
  4. try Firefox 86.0.

Minimal steps to reproduce (STR) the Firefox bug are at https://bugzilla.mozilla.org/show_bug.cgi?id=1694699#c20.

My long STR, from which the minimal steps were confirmed, are at https://gist.github.com/grahamperrin/d0eddafbbd838d60dad3d44ae4ab3a0a/. The steps are numerous however if you're familiar with the extension, they should be easy to understand.

From https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253886#c0 for the port to FreeBSD:

Symptoms (oversimplified): loss of nearly all tabs from any group, if load of the group into a new window is followed by closure of the window.

Downgrade protection

Mozilla's support page (above) describes the protection; it's a good thing.

If you find yourself bugged with Firefox 86.0 – through performing steps to reduce the bug immediately after upgrading – you should be able to exit, restore from the backup of your profile, uninstall 86.0 then install 85.0.2. That's a simple restoration not involving a downgrade of the profile.

If for any reason you do find the need to downgrade your profile, I can let you have the command line option to run Firefox and allow a downgrade. It's not recommended, and I would not be able to support you if a problem _did_ arise from a downgraded profile, but I did downgrade my own profile (after encountering the bug) and touch wood, no ill effects.

HTH

backup your profile

How is that done? Earlier I was searching for such an option, but all I found is that the only tool that made it possible is not developed anymore and is incompatible with modern versions of Firefox.

  1. about:profiles
  2. root directory
  3. open directory
  4. exit Firefox

– then backup the directory (folder) in whatever way you like.

Officially: http://mzl.la/1xKrFsk

Firefox 87 fixed

Extension mitigation possibilities for bugged builds of Firefox 86.⋯

… Extensions in the first group cannot easily work around this. …

– this group includes Simple Tab Groups, so I'll close this issue and look forward to the fix in Firefox.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

EstherMoellman picture EstherMoellman  Â·  4Comments

tomaszkane picture tomaszkane  Â·  3Comments

mzelyony picture mzelyony  Â·  6Comments

kstev99 picture kstev99  Â·  4Comments

victoriastuart picture victoriastuart  Â·  5Comments