Abstract

The API sessions.getTabValue() called for a duplicated tab returns a value same to the one for the original tab. However now it requires too large delay to get an expected value by a tabs.onCreated listener. On my environment the required delay is 400-600 msec, it is painfully slow. The required delay was 0 or less than 100msec in old versions of Firefox, thus it looks a regression by some recent changes.

Steps to reproduce

1. Go to about:debugging.
2. Load the attached testcase XPI as a temporary addon.
   (The addon registers a listener for the tabs.onCreated, and tries to call sessions.getTabValue() for notified tabs. If it is a duplicated tab, the result must be same to the one for the original tab. This addon measures the delay required to get the value same to the original tab.)
3. Then it opens and closes many tabs. Please wait for a while.
4. After all the result is reported in the active tab.

Actual result

The result says 640msec delay is required (on my environment).

Expected result

The result says success with no delay.

Environment

• Windows 10 Pro 20H2
• Nightly 89.0a1 (build ID: 20210329214331)

Bisection result

The last good build is at 6th March, and the initial bad build is at 7th March.
Sadly I couldn't find out the exact build the problem started at.

I think there are two possible solutions:

A) Make tabs.getValue() returning the value duplicated from the original tab immediately for a duplicated tab.
B) Make the promise returned by tabs.getValue() being resolved after the tab value duplicated from its original tab is completely restored.

A looks better than B for addon compatibility, but B looks to be acceptable if A is impossible.

I've realized that tabs.getValue() returns the expected value when I call it for a tab returned by tabs.duplicate(). In other words, a tabs.onCreated notification looks to be notified too earlier for a duplicated tab.

I'll investigate this.

(In reply to YUKI "Piro" Hiroshi from comment #2)

I've realized that tabs.getValue() returns the expected value when I call it for a tab returned by tabs.duplicate(). In other words, a tabs.onCreated notification looks to be notified too earlier for a duplicated tab.

tabs.duplicate() awaits the completion of the restoration, whereas tabs.onCreated can be firing before the completion of the restoration.

The last good build is at 6th March, and the initial bad build is at 7th March.
Sadly I couldn't find out the exact build the problem started at.

If there is a bug with the mozregression tool (or whatever you use to bisect), could you file a bug report? I know that there has been a period where the tool was temporarily broken.
I tried to bisect using mozregression -g 87 -b 88, but am unable to reproduce on Linux.

Based on the information that you shared:
https://fx-trains.herokuapp.com/api/nightly/?date=20210306 -> de11c0fbd90155ddd1fc8450b45ed99a55c3c2cf
https://fx-trains.herokuapp.com/api/nightly/?date=20210307 -> 74e3d611be8ffae26a5cf2702f5dd21a9c9b4742

Maps to the following revisions: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=de11c0fbd90155ddd1fc8450b45ed99a55c3c2cf&tochange=74e3d611be8ffae26a5cf2702f5dd21a9c9b4742

I recognize a patch that affects the extension API related to discarded tabs and session restore (https://hg.mozilla.org/integration/autoland/rev/c021c6541346f143f726bcb57060525a6c613f63 for bug 1498432), but there is no obvious connection from that change and the reported bug. There have been significant refactorings in session restore code (SHIP), which could also potentially affect observed results.

Could you try to offer more reliable STR or offer a more specific regression range? It can also help if you offer the build numbers shown in about:support, because that allows me to identify the commits of the range more reliably than a date-based guess that I did above.

(In reply to YUKI "Piro" Hiroshi from comment #1)

I think there are two possible solutions:

A) Make tabs.getValue() returning the value duplicated from the original tab immediately for a duplicated tab.
B) Make the promise returned by tabs.getValue() being resolved after the tab value duplicated from its original tab is completely restored.

A looks better than B for addon compatibility, but B looks to be acceptable if A is impossible.

Assuming that you mean sessions.getTabValue: A looks preferable over B to me, because B introduces complexity and potentially undesired delays.

(In reply to Rob Wu [:robwu] from comment #4)

Could you try to offer more reliable STR or offer a more specific regression range? It can also help if you offer the build numbers shown in about:support, because that allows me to identify the commits of the range more reliably than a date-based guess that I did above.

Piro, could you answer this question from comment 4?

Sorry for my too long silence.

I've tried the testcase I attached again. Curiously (for me), the required delay to get expected session data on environments are quite different:

• Windows 10 21H1, Firefox 88.0.1: 13 msec
• Windows 10 21H1, Firefox 89.0: 80 msec
• Windows 10 21H1, Nightly 91.0a1: 160 msec
• Ubuntu 20.04 on VirtualBox, Firefox 88.0.1: 0 msec (no delay)
• Ubuntu 20.04 on VirtualBox, Firefox 89.0: 1067 msec
• Ubuntu 20.04 on VirtualBox, Nightly 91.0a1: 2133 msec

I still cannot find out what triggers this difference, but it looks to be depending on its running environment.

I've tried mozregression again on Ubuntu 20.04 on VirtualBox, because the problem I saw clearly appears on the environment. The result is very curiously: mozregression says that the differential revision is https://phabricator.services.mozilla.com/D108938 landed at 30th March (despite I initially reported the regression range is between 6th March and 7th March). Steps I did:

1. Prepare an Ubuntu 20.04 environment.
2. Download mozregression-gui binary at https://github.com/mozilla/mozregression/releases .
3. Unpack mozregression-gui.tar.gz .
4. Run mozregression-gui with an environment variable DISPLAY=:0.0 (because mozregression-gui doesn't start without it).
5. Start bisection with the config:
   • branch: mozilla-central
   • range: 2020-06-07 - 2021-06-07
6. Test each build with these steps:
   1. Go to about:debugging.
   2. Load the attached testcase.xpi as a temporary extension.
   3. Wait until the testcase extension reports the result.
      • If the result is quite small (10-20msec on my environment), treat it as a good build.
      • If the result is quite large (2500-6000msec on my environment), treat it as a bad build.

I've tried these steps four times and gotten same results on every try. The title of the found revision https://phabricator.services.mozilla.com/D108938 is "Bug 1572084 - Part 3: Force session store flush order", it sounds related to the session information problem.

(needinfo myself to investigate)