User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

I started Firefox 109.0a1 20221126212735 on Wayland in Plasma 5.26.3 in a Fedora 37 KDE Plasma installation. I hovered the cursor over various buttons that show tooltips such as the Close tab x in the tab bar, buttons in the address bar, and toolbar many times.

Actual results:

Tooltips occasionally appeared without text and were longer vertically than horizontally in Firefox 109.0a1 on Wayland. This problem happened about 10-20% of the times a tooltip was shown. The problem might be more frequent right after Firefox was started. I'm attaching a recording of starting 109.0a1 20221126212735 on Wayland in Plasma 5.26.3 and hovering the cursor over the close tab x in the tab. The tooltip contained no text and had a much longer vertical length than horizontal width. I have seen this problem only with 109.0a1 builds from the last 2 or so days, so it is likely a regression. I could try to bisect it.

Expected results:

The tooltips should contain text each time, and they should be longer horizontally than vertically.

109.0a1 20221122214324 on Wayland didn't have this problem when I hovered over the Close tab x button in the tab bar right after Firefox started, but 109.0a1 20221123213526 on Wayland had the problem when doing so. I ran MOZ_ENABLE_WAYLAND=1 mozregression --good 2022-11-22 --bad 2022-11-23 --persist /tmp/mozregression -p ~/.mozilla/firefox/rgdja60u.default-nightly-1

I hovered over the Close tab button in the tab bar right after Firefox started at each step of the bisection and retried until either the problem happened or I had retried 20 times. The pushlog had 8 changes from 3 bugs. Bug 1760029 had the description "Two of the strings in this file are formatted during startup: tabs.closeTab and tabs.emptyTabTitle." So the migration of the tabbrowser strings to Fluent might be involved, as the problem is more apparent right after startup. I'm setting Regressed by to 1760029 as that looks like the most likely one.

4b4c0eff34dd42562e0e9ed7c958f038da5b40ea Eemeli Aro — Bug 1760029 - Remove tabbrowser.properties as empty. r=dao
92bf4a86ee9e375f0a823b648a24760a911bb319 Eemeli Aro — Bug 1760029 - Migrate tabbrowser.properties strings used by OpenInTabsUtils.jsm to Fluent. r=dao,fluent-reviewers,flod
1f17188d8d52961a55191af54ffcda3a740d4b13 Eemeli Aro — Bug 1760029 - Migrate tabbrowser.properties strings used by BrowserGlue.jsm to Fluent. r=dao,fluent-reviewers,flod
06e5c879218fece6db1e4602a496b80352ae93b6 Eemeli Aro — Bug 1760029 - Migrate tabbrowser.properties strings used by tabbrowser-tabs.js to Fluent. r=gregtatum,dao,fluent-reviewers,flod
a7f41e6769562e29e908f2842785e9092163dab8 Eemeli Aro — Bug 1760029 - Migrate browser.properties strings used by tabbrowser.js to Fluent. r=dao,fluent-reviewers,flod
6e7525de80a242daf9c72a2c95f0550db4d83f56 Eemeli Aro — Bug 1760029 - Migrate tabbrowser.properties strings used by tabbrowser.js to Fluent. r=dao,fluent-reviewers,flod
5ca9d371d075cd69a31c82d79cef3cb3681db830 Eemeli Aro — Bug 1799877 - Allow using { l10n-id, l10n-args } object when setting notification label. r=dao,mstriemer
2be56c37e28d113df40f9ce69c2a6797f860bd7a Emilio Cobos Álvarez — Bug 1801844 - Remove some min-widget-size for various menuitem bits. r=cmartin

25:52.73 INFO: Narrowed integration regression window from [82670c05, 4b4c0eff] (3 builds) to [acc3cfe9, 4b4c0eff] (2 builds) (~1 steps left)
25:52.73 INFO: No more integration revisions, bisection finished.
25:52.73 INFO: Last good revision: acc3cfe99446c49093646718e406978e1e11518a
25:52.73 INFO: First bad revision: 4b4c0eff34dd42562e0e9ed7c958f038da5b40ea
25:52.73 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=acc3cfe99446c49093646718e406978e1e11518a&tochange=4b4c0eff34dd42562e0e9ed7c958f038da5b40ea

:eemeli, since you are the author of the regressor, bug 1760029, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

I started first with an idea that reintroducing the caching for emptyTabTitle might do something here, but on further thought that probably does nothing. Instead, my latest guess would be that we're not updating the tooltip contents in your environment if Fluent takes a bit longer than usual to complete the formatting.

Matt, would you be able to apply the following patch to your browser/base/content/tabbrowser.js and seeing if that makes this error happen more consistently? On my machine (macOS 13 on M1), the tooltip text gets updated a little bit after it's first rendered, but if my hunch is right then that update never happens for you and e.g. moving between the tab's main area and the close button will provide an incorrect tooltip:

--- a/browser/base/content/tabbrowser.js
+++ b/browser/base/content/tabbrowser.js
@@ -5634,7 +5634,10 @@
         l10nArgs = { title: this.getTabTooltip(tab, true) };
       }

-      document.l10n.setAttributes(event.target, l10nId, l10nArgs);
+      setTimeout(
+        () => document.l10n.setAttributes(event.target, l10nId, l10nArgs),
+        1000
+      );
     },

     handleEvent(aEvent) {

(In reply to Eemeli Aro [:eemeli] from comment #4)

I started first with an idea that reintroducing the caching for emptyTabTitle might do something here, but on further thought that probably does nothing. Instead, my latest guess would be that we're not updating the tooltip contents in your environment if Fluent takes a bit longer than usual to complete the formatting.

Matt, would you be able to apply the following patch to your browser/base/content/tabbrowser.js and seeing if that makes this error happen more consistently? On my machine (macOS 13 on M1), the tooltip text gets updated a little bit after it's first rendered, but if my hunch is right then that update never happens for you and e.g. moving between the tab's main area and the close button will provide an incorrect tooltip:

--- a/browser/base/content/tabbrowser.js
+++ b/browser/base/content/tabbrowser.js
@@ -5634,7 +5634,10 @@
         l10nArgs = { title: this.getTabTooltip(tab, true) };
       }

-      document.l10n.setAttributes(event.target, l10nId, l10nArgs);
+      setTimeout(
+        () => document.l10n.setAttributes(event.target, l10nId, l10nArgs),
+        1000
+      );
     },

     handleEvent(aEvent) {

When I hovered over the main part of the tab right after startup, the tooltip occasionally showed vertical white dots of varying sizes with a longer vertical length than width like I described. There's a browser/ subdirectory in my Firefox 109.0a1 installation, but it doesn't have a base/ subdirectory. I guess that Firefox would need to be rebuilt with the patch. If you could make a build with the patch, I'd test it out. I've only built Firefox once probably a couple years ago and it took about 3 hours on my computer. Thanks.