1797488 - "Switch to tab" is sometimes broken

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Alessio Placitelli [:Dexter]]

Attachment: firefox-go-to-tab-bug.gif

I'm attaching the full STR as a gif to this bug. The tl,dr

1. Open a blank tab
2. Type some keyword to have the relevant results show up
3. Click on the result with the "Switch to tab" or "press enter"

Expected outcome

The browser switches to the already opened tab containing the desired result.

Current outcome

Nothing happens

Comment 1

[Marco Bonardo [:mak]]

This happens when we think the tab is open and it's not, or we think the tab is open, but it's not.
When it happens, you could eval this in the console

(async () => {
  let db = await PlacesUtils.promiseLargeCacheDBConnection();
  (await db.execute("SELECT * FROM moz_openpages_temp"))
    .forEach(r => console.log(r.getResultByIndex(0), r.getResultByIndex(1), r.getResultByIndex(2)));
})()

and look for the url not working (you can hold down shift when the result is selected in the urlbar to check the url), it should appear, the second column should be the container ID where it was open, while the third column should be > 0 (number of open tabs)
Then check that page/url is not open in a tab.
That will confirm that the tab on close was not unregistered properly.

The best solution would of course to figure out WHY the tab switcher didn't unregister the tab, but that's complicate, we'll have to add logging for this specific case, I see no logging available atm.

As a workaround, we could detect that tab switch didn't happen, then unregister the open tab and reopen a new tab, at least it would not look completely broken.

Comment 2

[Alessio Placitelli [:Dexter]]

(In reply to Marco Bonardo [:mak] from comment #1)

This happens when we think the tab is open and it's not, or we think the tab is open, but it's not.
When it happens, you could eval this in the console

(async () => {
  let db = await PlacesUtils.promiseLargeCacheDBConnection();
  (await db.execute("SELECT * FROM moz_openpages_temp"))
    .forEach(r => console.log(r.getResultByIndex(0), r.getResultByIndex(1), r.getResultByIndex(2)));
})()

and look for the url not working (you can hold down shift when the result is selected in the urlbar to check the url), it should appear, the second column should be the container ID where it was open, while the third column should be > 0 (number of open tabs)
Then check that page/url is not open in a tab.
That will confirm that the tab on close was not unregistered properly.

Yes, the tab is in that list:

<url> 2 1

Comment 3

[Marco Bonardo [:mak]]

My suspect and theory was some relation with the Multi-Account Container add-on, this kind of bug may happen for example if when we close a tab its container is different from the one we opened the tab with. Though, after many tests, I could not proof that relation or reproduce the bug.
Another possibility is some kind of complex to debug race condition in the tab switcher for which the unregisterOpenTab() API is not invoked before the tab goes away... unlikely since we handle it in destroy, but I have no better ideas atm.

Since I can't find a direct way to reproduce and debug the problem, and it's quite annoying user side (the only workaround is knowing about SHIFT/ALT override, that is unlikely(, I think we should:

1. handle broken switch to tab results by manually unregistering the open page and opening a new tab
2. report to the Browser Console
3. report a new type like broken_switchtab through telemetry, and in the future measure the correlation between this type and installed add-ons, so we could check if effectively the MAC add-on is the one able to activate the problem.
4. file a bug to track the problem for the future in case we find a way to reproduce the problem and we can debug it

Comment 5

[Daniel]

Would it be possible to handle this via workaround:

1. user chooses option to "switch to tab" that does not exists
2. browser checks if the switch really worked out, if not, unregisters such tab / purges / collects up garbage

This would at least guarantee that once this option is used, that tab dissapears forever.

Unfortunately, I have been lately hitting this issue repeatedly with multiple non-existing tabs that are offered in first position instead of the URL from history (that makes sense).

Comment 6

[Marco Bonardo [:mak]]

that's what I suggested in comment 3.

Comment 7

[Dale Harvey (:daleharvey)]

Attachment: Bug 1797488 - Ensure switchtotab loads URL in a tab if record is missing. r=mak

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d47d444e965b
Ensure switchtotab loads URL in a tab if record is missing. r=mak

Comment 9

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/d47d444e965b

Comment 10

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

I tried to reproduce this issue but I was unsuccessful. Switch to tab works on regular/container tabs without any issues. Would you be so kind as to verify this fix on the latest nightly build?
Thank you.

Comment 11

[Alessio Placitelli [:Dexter]]

(In reply to Ardelean Oana, Desktop QA [:oardelean] from comment #10)

I tried to reproduce this issue but I was unsuccessful. Switch to tab works on regular/container tabs without any issues. Would you be so kind as to verify this fix on the latest nightly build?
Thank you.

Sorry, I'm not able to test this on Nightly :(