1618567 - Duplicated or Re-Opened Extension Page tabs have no title/TP shield

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P5)

Description

[M8R-p7]

Attachment: duptabtitle.xpi - bug demonstration

STR:

0. Create a new profile.
1. Install the attached extension - it will open its options_ui page automatically.
2. Duplicate the page's tab by middle-clicking the Refresh button.

Expected Results
The tab is duplicated.

Actual Results
The tab is duplicated, but initializes strangely. It lacks a page title (using the URL instead) and the address bar has no Tracking Protection 'shield' icon.
document.title appears to be set correctly, but is not reflected in the tab or window titlebar.
This only happens reliably on the first duplication in the window - further duplicates seem to act as Expected for the window's lifetime.

This also affects the initial Options page tab if closed and re-opened (e.g. with Ctrl+Shift+T).

I've only been able to reproduce this on Linux. I have a much slower Win10 machine that doesn't exhibit this behavior.
I'm filing this bug here in 'DOM: Content Processes' due to the mozregression results, but please move if it's wrong.

mozregression:

Last good revision: bcd20202a38f646ad065ec4b849d8146b66bf888
First bad revision: 2c0229c483d89a8073d426f13cc03ab9e59e23a7
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=bcd20202a38f646ad065ec4b849d8146b66bf888&tochange=2c0229c483d89a8073d426f13cc03ab9e59e23a7

This range has only one bug, bug1578304.

Comment 1

[Chris Peterson [:cpeterson]]

Barret, could this bug be a regression from your document title changes in onLocationChange bug 1578304?

P5 for now unless any other extensions are affected.

Comment 2

[Beth Rennie [:beth] (she/her)]

That doesn't seem likely, due it it just being a typo fix

M8R-p7, could you please provide the source repo for this example extension so that I can build it locally? I'm not super stoked about installing some unknown addon.

Comment 3

[M8R-p7]

Thanks for taking a look.
Testing a little further with this, I can also reproduce this with local files rather than just files bundled in an extension. That handily reduces the demo case to just an HTML file with a <title>, although local files would correctly lack the Tracking Protection Shield.

I don't have a public repository account anywhere I'm afraid - it's a small extension though, so I can provide a git patch file for an empty repo if that's a reasonable suggestion.

Comment 4

[Beth Rennie [:beth] (she/her)]

I used the following testcase:

<title>asdf</title>

and was unable to reproduce this behaviour on Nightly or Release on Windows. However, I was able to reproduce this on Release on Linux. It does not reproduce on Nightly on Linux, however, which leads me to believe that this has since been fixed.

Comment 5

[M8R-p7]

I'm seeing it on Nightly:

Fedora 31:
Version   75.0a1
Build ID  20200303095030
User Agent  Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
OS  Linux 5.5.6-201.fc31.x86_64

Plus I can reproduce the local file test on Windows:

Version   75.0a1
Build ID  20200303095030
User Agent  Mozilla/5.0 (Windows NT 10.0; rv:75.0) Gecko/20100101 Firefox/75.0
OS  Windows_NT 10.0

In both cases if I set the Content Process Limit to 1, the problem goes away.
Is there any specific information you need and/or tests to run?

Comment 6

[BugBot [:suhaib / :marco]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

This seems like it was likely fixed by https://phabricator.services.mozilla.com/D72562 as part of bug 1594752 which changed us to pull the title from the browsingContext rather than manually propagating it. Bug 1890675 is the most recent change to the logic which is probably relevant too.