1714276 - [Linux] The tabstrip changes height (becomes taller / shorter) when sound "PLAYING" notifications appear/disappear, which resizes web content

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P2)

Description

[Dominique Pelle]

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

Steps to reproduce:

When playing chess on Lichess.org, I see that the chess board sometimes resizes slightly for 1 few milliseconds. I does not happen all the times but frequently enough to be annoying (maybe every 1 in 5 chess moves or so).

The bug started to happen after I upgraded Firefox from version 88.0.1 to version 89.0 on xubuntu-18.04.5. I also tried with Chrome and Chrome 91.0.4472.77 does not have such a bug. I have been using chess on Lichess.org for years and I only started to notice this bug right after the Firefox upgrade to version 89.0 (using Ubuntu packages).

I've also reported this bug on Lichess.org at:
https://lichess.org/forum/lichess-feedback/booad-small-resize-glitches-after-upgrading-from-firefox-88-to89-on-linux

To reproduce, just play a game on Lichess. The bug should happen after playing a few moves only (less than 5 moves is more than enough to see the bug most of the times).

Actual results:

The chess board slightly resizes during a few milliseconds.

Expected results:

The chess board should not resize at random times. Its size should be fixed (as when playing with Firefox <= 88 or Chrome.

Comment 1

[Dominique Pelle]

I just also installed Firefox nightly on xubuntu-18.04: 91.0a1 (2021-06-02) (64-bit)
It has the same bug, although perhaps the bug happens less often (subjective).
So the bug happens at least wiht Firefox 89.0 and Firefox nightly 91.0a1.

I only tried on Linux. I'm curious whether it happens on other platforms (Windows or macOs).

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Alastor Wu [:alwu]]

As this seems a recent regression, would you mind to use this to find the possible root cause?
In addition, the resizing of the chessboard seems more like an animation or a layout issue, not media, so I will move this to another component.

Comment 4

[Dominique Pelle]

@alwu wrote

As this seems a recent regression, would you mind to use this to find the possible root cause?

I've never used mozregression, but I can give it a try in during the weekend.

In addition, the resizing of the chessboard seems more like an animation or a layout issue, not media, so I will move this to another component.

Yes, it was a bot that guessed wrongly that this belongs to 'Core::Audi/Video: Playback' (clearly incorrect)

Comment 5

[Brian Birtles (:birtles)]

As best I can tell the pieces are not moved using declarative animations so I don't think this is DOM: Animation. Moving to Graphics for now.

I suspect the Graphics team would benefit from the information in about:support if you are able to provide that.

Comment 6

[Dominique Pelle]

Attachment: about:config content of firefox 89.0

> I suspect the Graphics team would benefit from the information in about:support if you are able to provide that.

Here it is with Firefox 89.0:
```

```

Comment 7

[Dominique Pelle]

Attachment: about:support content of Firefox nightly 91.0a1 which also has the bug

Also also attaching about:config content of Firefox nightly 91.0a1 (2021-06-03) (64-bit) which has the same issue.

Comment 8

[Dominique Pelle]

Also also attaching about:config content of Firefox nightly 91.0a1 (2021-06-03) (64-bit) which has the same issue.

Comment 9

[Dominique Pelle]

I've run mozregression. It ended with:

2021-06-04T23:32:29.654000: DEBUG : Found commit message:
Bug 1700109 - Enable main Proton pref by default in Nightly r=dao,jaws

This sets browser.proton.enabled to true by default in Nightly. This is the first
wave of Proton changes.

Differential Revision: https://phabricator.services.mozilla.com/D110156

2021-06-04T23:32:29.655000: DEBUG : Did not find a branch, checking all integration branches
2021-06-04T23:32:29.659000: INFO : The bisection is done.
2021-06-04T23:32:29.660000: INFO : Stopped

I hope that helps. I will attach the full log from mozregression.
It was the first time I used mozregression. It's a very good tool!

To reproduce the bug, you don't need to login in lichess.org.
You can play anonymously.

Comment 10

[Dominique Pelle]

Attachment: mozregression.log

Full log of mozregression.

Comment 11

[Dominique Pelle]

Since mozregression blamed the commit that enabled proton by default,
I just went into about:config and disabled proton (set first 4 item to false in screenshot disable-proton.png)
And sure enough, that fixed the issue: playing on Lichess is now good again with Firefox 89 after disabling proton.
I have no idea why proton messes up lichess.org.
If there is anything else I can do, let me know.

Comment 12

[Dominique Pelle]

Attachment: disable-proton.png

Screenshot showing the first 4 options which I disabled to work around the issue as explained in my previous comment.

Comment 13

[Jamie Nicol [:jnicol] (PTO until 17/6)]

Unfortunately I'm not able to reproduce, on either Linux or Windows. So it might be device specific.

Thanks for running mozregression, Dominique. Would you be able to run it again, but this time adding --pref 'browser.proton.enabled:true' to the command line? This should help narrow down which part of proton specifically is causing the issue. Thanks again!

Comment 14

[Dominique Pelle]

I reran the regression again with the settings 'browser.proton.enabled:true'.
mozregression indicated:

2021-06-10T21:00:41.557000: INFO : Narrowed integration regression window from [bef51c40, 1cad2771] (3 builds) to [14e56036, 1cad2771] (2 builds) (~1 steps left)
2021-06-10T21:00:53.028000: DEBUG : Found commit message:
Bug 1701003 - Use the darker toolbar text color in Light that was already being used in browser-custom-colors.inc.css. r=mstriemer           

Differential Revision: https://phabricator.services.mozilla.com/D109973
2021-06-10T21:00:53.028000: DEBUG : Did not find a branch, checking all integration branches
2021-06-10T21:00:53.032000: INFO : The bisection is done.
2021-06-10T21:00:53.034000: INFO : Stopped

Instead of playing a game, I go in lichess.org I reproduced it by doing "TOOLS → Analysis board"
And there you can make random move for whites and black in order to reproduce the bug.

The resize glitch always happens at least at the first move when in Firefox versions that have the bug.

I found that it's actually the content of the tab that changes from showing 1 line only with this comment:

Analysis board

… to briefly showing 2 lines:

Analysis board
PLAYING

Since the tab vertical changes a result, the board is also briefly slightly resized (→ BUG!).

I'll attach 2 screenshots showing the tab with 1 and 2 lines.

Comment 15

[Dominique Pelle]

Attachment: tab-with-2-lines.png

Attached screenshot tab-with-2-lines.png which shows the tab in the top left that contains 2 lines:

Analysis board
PLAYING

When the tab changes briefly from 1 line to 2 lines, it causes to tab to be bigger temporarily hence shrinking the board (ugly glitch!)

Comment 16

[Dominique Pelle]

Attachment: tab-with-1-line.png

Attached "tab-with-1-line.png" (compare with other attached file "tab-with-2-line.png").

I would not expect the tab height to temporarily change, as it causes ugly temporary resize of the chess board.

Comment 17

[Dominique Pelle]

Adding @mstriemer in copy of this bug, since mozregression pointed to one of his commit (I hope I ran mozregression correctly!).
See comment #14 for the outcome of mozregression.

Comment 18

[Dominique Pelle]

For the record, the latest nightly build "91.0a1 (2021-06-10) (64-bit)" has the bug.
To reproduce:

1. Go to https://lichess.org
2. From main menu in lichess page, chose TOOLS → Analysis board
3. Make a move with white and notice that the chess board resizes temporarily (BUG!) a s result of the tab that vertically resizes to show 2 lines instead of 1 line.

The bug does not happen with Chrome or when disabling proton in Firefox as they show a constant size tab with one line only. It seems bad that FIrefox with proton has tabs that can dynamically resize vertically, especially when this happens only for a brief amount of time.

Comment 19

[Dominique Pelle]

Hmm, the outcome of the mozregression seems suspicious, as it's pointing to a commit that merely change a color:
https://hg.mozilla.org/releases/mozilla-release/rev/1cad2771338cc5ed9b8ed587f48510bbb877193a

I don't see why this would affect the resizing of the tab.

Is there way for me to confirm that this commit introduces the regression? other than by re-running mozregression that takes time?

Comment 20

[Jamie Nicol [:jnicol] (PTO until 17/6)]

(In reply to Dominique Pelle from comment #19)

Hmm, the outcome of the mozregression seems suspicious, as it's pointing to a commit that merely change a color:
https://hg.mozilla.org/releases/mozilla-release/rev/1cad2771338cc5ed9b8ed587f48510bbb877193a

I don't see why this would affect the resizing of the tab.

Is there way for me to confirm that this commit introduces the regression? other than by re-running mozregression that takes time?

You could try running mozregression over a much smaller range. You can use dates for the good and bad revisions, eg mozregression --good 2021-05-23 --bad 2021-05-25 --pref 'browser.proton.enabled:true'

Comment 21

[Dominique Pelle]

My machine where I reproduce the bug is xubuntu-18.04
I tried to reproducing the bug on a xubuntu-20.04 machine with Firefox 89 and there I did not see the board resize bug.
I could still see on xubuntu-20.04 that the tab shows 2 lines temporarily temporarily and then 1 line (as on xubuntu-18.04).
However, this does not cause to resize the tab on xubuntu-20.04 unlike what I see on xubuntu-18.04.
As a result, the board does not get resized on xubuntu-20.04.

You could try running mozregression over a much smaller range. You can use dates for the good
and bad revisions, eg mozregression --good 2021-05-23 --bad 2021-05-25 --pref 'browser.proton.enabled:true'

Will do that later today.

Comment 22

[Dominique Pelle]

This issue looks similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1712663

Comment 23

[Dominique Pelle]

I just upgrade Firefox nightly to version "92.0a1 (2021-07-25) (64-bit)" and for the record, the bug is still reproducible in that version.

Comment 24

[Dominique Pelle]

I just upgrade Firefox nightly to version "93.0a1 (2021-08-12) (64-bit)" and bug is still reproducible.

Comment 25

[Dominique Pelle]

I just upgraded Firefox nightly to version "93.0a1 (2021-08-26) (64-bit)" on xubuntu-18.04.5 and bug is still reproducible.

Comment 26

[Darkspirit]

(In reply to Dominique Pelle from comment #25)

I just upgraded Firefox nightly to version "93.0a1 (2021-08-26) (64-bit)" on xubuntu-18.04.5 and bug is still reproducible.

Does the problem occur with Gnome or KDE on 18.04 as well?

---

Offtopic (other user's comment on your bug report):
https://lichess.org/forum/lichess-feedback/booad-small-resize-glitches-after-upgrading-from-firefox-88-to89-on-linux#3

Since updating to latest Firefox 89.0 on a Linux Mint system yesterday I'm experiencing massive animation lags, 'sluggish' behaviour of the pieces, even opponents pieces move like slow motion. Firefox consumes more resources on Lichess as well now. This started immediately after the update...
Bullet and well even Bltz is unthinkable. :-/
Latest FF 89 sucks moose c**k, really.

That could be the usual OpenGL/non-Gnome/Nvidia bug. In the past, I needed to enable "Force Composition Pipeline" in Nvidia settings to fix OpenGL applications on KDE. I mentioned it in bug 1673752 comment 0, but it was shipped anyway in bug 1712135. Hopefully it has been fixed with recent Nvidia driver releases.
Or it could be bug 1720634/bug 1716049.

Comment 27

[Dominique Pelle]

@Darkspririt asked:

Does the problem occur with Gnome or KDE on 18.04 as well?

I don't know. I use xfce that comes with xubuntu-18.04.5 i.e. xfce-4.12 according to the xfce4-about command.
I don't really feel like installing the fat KDE or GNOME packages and all their dependencies just to try that.

Comment 28

[Robert Mader [:rmader]]

Dominique, could you post the output of xrandr --listproviders here? This might be a duplicate of bug 1710400

Comment 29

[Dominique Pelle]

@rmader asked:

Dominique, could you post the output of xrandr --listproviders here?

Here it is:

$ xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x44 cap: 0x9, Source Output, Sink Offload crtcs: 2 outputs: 3 associated providers: 0 name:modesetting

Comment 30

[Dominique Pelle]

Attachment: bug-with-lichess.ogv

Attached captured movie bug-with-lichess.ogv
which shows the chess board with annoying resizes.

You can see that the height of the tab at the top changes, which causes the chessboard resize.
It was captured with: firefox nightly 94.0a1 (2021-09-18) (64-bit) on xubuntu-18.04.6

Comment 31

[Robert Mader [:rmader]]

I see, thanks. Actually, to me this doesn't look like a glitch at all - but rather a debatable design decision. What happens is that the game plays a sound, which triggers the sound indicator in the tab, which again triggers a resize. In other words: to me it looks like this is intended behaviour.

I'm not sure if it's possible to disable that - maybe by muting the tap (ctrl+m)? In any case, this doesn't look like a backend bug to me, but rather a design issue.

Comment 32

[Jamie Nicol [:jnicol] (PTO until 17/6)]

On my computer the tab height remains the same size even when the PLAYING line appears underneath the tab title. Dominique, do you have any non-standard font or css settings applied? Can you reproduce in a fresh profile?

Comment 33

[Dominique Pelle]

@jnicol asked:

Dominique, do you have any non-standard font or css settings applied? Can you reproduce in a fresh profile?

No, not to my knowledge.
I had reproduced it with the mozregression tool which uses default vanilla settings as far as I know.
Maybe reproduction of the bug depends on the version of xfce4 or other libs it uses. I don't really know.
This bug is linked to another tickets where the reporter complained about the tab changing height. E.g.:
https://bugzilla.mozilla.org/show_bug.cgi?id=1716661
See also:
https://support.mozilla.org/en-US/questions/1340677

I just noticed that in the movie I attached, the language was Esperanto (tab shows "Analiza tabulo").
But it does not look so relevant for this bug as earlier screenshots had the tab in English.

Comment 34

[Dominique Pelle]

I tried on another computer xubuntu-20.04.3 and I did not see the bug there.
But somehow the bug happens on my xubuntu-18.04.6 machine.
The screenshot at https://support.mozilla.org/en-US/questions/1340677 which describes a similar issue (with dulingo website) seems to be happening on Windows.

Comment 35

[Darkspirit]

Is this bug really a resize glitch?
Isn't this bug rather more about "The tab suddenly gets a second line with the word "PLAYING" which moves the whole browser UI and resizes website content." ?

Comment 36

[Darkspirit]

Then this bug should be moved to the Theme component because the "button bar" should not suddenly change its height.

Comment 41

[kunstler]

The solution to this problem is to install Extended Release Version of Firefox. It merely shows an audio icon of a speaker without changing size or displaying the word "playing".

Comment 42

[Darkspirit]

(In reply to kunstler from comment #41)

The solution to this problem is to install Extended Release Version of Firefox. It merely shows an audio icon of a speaker without changing size or displaying the word "playing".

You can also set browser.uidensity to 1 on about:config to prevent PLAYING from showing up. Officially it seems to be considered unsupported, but it's the only way to make Firefox not look like a big button phone for seniors.

Comment 43

[tbgf6180]

There are at least 4 bugs floating around here all with this same problem.

For anyone without a clear understanding of it:
when a sound starts playing, the word "PLAYING" appears in the tab.
That increases the size of the tab by 2 pixels, which decreases the size of the window (also by 2 pixels).

[Side note: that is where lichess has a problem it responds to the resize as if the user wanted it, or it was bigger]

When the sound stops playing, the word "PLAYING" is removed, and everything reverts to the
prior state, triggering another resize event, which jiggers content to a greater or lesser extent,
depending how the page handles it.

It is most noticeable on a page which plays lots of short sounds, causing constant jumpiness of the content.

Here is a very simple test case: http://acrozilla.com/test1/soundtest.html
Click the button to play a sound, watch things move, open Web Developer's console to see resize events being logged.

Illustration:
https://bugzilla.mozilla.org/attachment.cgi?id=9242965 (attached to bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1726144 )

Comment 44

[Masatoshi Kimura [:emk]]

(In reply to Darkspirit from comment #42)

(In reply to kunstler from comment #41)

The solution to this problem is to install Extended Release Version of Firefox. It merely shows an audio icon of a speaker without changing size or displaying the word "playing".

You can also set browser.uidensity to 1 on about:config to prevent PLAYING from showing up. Officially it seems to be considered unsupported, but it's the only way to make Firefox not look like a big button phone for seniors.

Yet another workaround: add your locale to browser.tabs.secondaryTextUnsupportedLocales pref on about:config. It will disable secondary labels (such as PLAYING) without changing the ui density.

Comment 45

[tbgf6180]

(In reply to Masatoshi Kimura [:emk] from comment #44)

(In reply to Darkspirit from comment #42)

(In reply to kunstler from comment #41)

The solution to this problem is to install Extended Release Version of Firefox. It merely shows an audio icon of a speaker without changing size or displaying the word "playing".

You can also set browser.uidensity to 1 on about:config to prevent PLAYING from showing up. Officially it seems to be considered unsupported, but it's the only way to make Firefox not look like a big button phone for seniors.

Yet another workaround: add your locale to browser.tabs.secondaryTextUnsupportedLocales pref on about:config. It will disable secondary labels (such as PLAYING) without changing the ui density.

This is a defect and should just be fixed - plain and simple. (That several people independently filed bug reports is testimony to that.)
Playing a sound should simply not cause any visual aspect of the window to move because the two bear no relationship.

As an ordinary user, I just want Firefox to work, and I find these suggested workarounds to be rather 'unfortunate',
to use a milder term than I'd like to.

Install a special version? Set some obscure option? (without knowing what ELSE it might affect) and have to track it every
time a new update comes down the pike, which might change things yet again? Really?

And it would be very easy to fix in a number of ways:

• move PLAYING up 2 pixels - there's boatloads of room (see Firefox-PLAYING-tab.jpg)
  OR ...
• make the font of PLAYING smaller
• Use a symbol of some kind and make the tab a bit wider if need be (which is apparently what one the workarounds does)
• Shrink the padding in the tab (since it's only two pixels - one at the top, one at the bottom would do)
• Just remove the feature ... because
  While I suppose it might be useful in finding the tab causing unwanted sound to play so you can shut it off, that is hardly the the most common case of sound playing - you are active in the tab and so you know what the sound is about - or it's background sound you started.

Comment 46

[tbgf6180]

Attachment: Firefox-PLAYING-tab.jpg

Enlarged view shows that PLAYING could easily be moved or reduced in size avoiding the tab expansion which causes the problem.

Comment 47

[Dominique Pelle]

This is a matter UI taste of opinion, but personally, I find it jarring to put "PLAYING" in the tab on a second line (which was introduced by Proto GUI in Firefox 89):

• either it causes an ugly resize of the tab as it happens for me on e.g. Lichess website on xubuntu-18.04 and happens to other people for other bugs linked to this issues. This is clearly a bug. I don't understand why it happens for some users and not others.
• or, if the tab does not resize, it causes all tabs to have a height larger than needed in most cases, as it needs to cope withe the possibility that the tab may later show "PLAYING". Often, no tabs has the "PLAYING" message so it often causes to waste precious vertical screen size.

I see that Chrome merely displays a sound icon on a single line which looks better IMHO. And Chrome does not have the resize tab glitch either. I think that Firefox prior to Proton did something similar to Chrome (not 100% sure). But again, I understand it's matter of taste so I'm not ranting, just stating my preference.

Comment 48

[Masatoshi Kimura [:emk]]

(In reply to tbgf6180 from comment #45)

This is a defect and should just be fixed - plain and simple. (That several people independently filed bug reports is testimony to that.)
Playing a sound should simply not cause any visual aspect of the window to move because the two bear no relationship.

Why did you quote my comment? When did I say this bug don't have to be fixed because workaround exists? Of course this bug should be fixed regardless of the existence of workarounds. But Mozilla developers could not reproduce the problem yet.

Can you reproduce this bug with a fresh profile and the default operating system theme?

Comment 49

[Dominique Pelle]

I just tried with a fresh profile as described at https://cat-in-136.github.io/2012/12/tip-how-to-run-new-firefox-instance-w.html i.e.:

$ PROFILEDIR=/tmp/tmp-fx-profile.$$.d
$ mkdir $PROFILEDIR
$ firefox -profile $PROFILEDIR -no-remote -new-instance

And the tab resize bug still happens when I go to https://lichess.org/analysis and move pieces.

This is with Firefox 92.0 (64-bit). But the bug also happens with nightly 94.0a1 (2021-09-18) (64-bit).
I'm using xubuntu-18.04.6 (up-to-date).

At https://bugzilla.mozilla.org/show_bug.cgi?id=1726144#c5 a user reported the same issue with ubuntu-20.04.3 also with a new profile.

Comment 50

[tbgf6180]

This defect has been reported by multiple users in multiple environments (Windows, Ubuntu, etc) which should satisfy as to it being a Firefox coding issue, regardless of other causative factors.

Whether the browser should give a visual indication that sound is playing, and how, can be argued as to matters of preference or style.

What is not a debatable issue is the window resizing which is occurring because of that, which simply should not happen.
While 2 pixels is not a lot of movement, it gets very annoying when it is happening often - your content is
bouncing up and down.

If you are playing a minutes-long video for example, it's not a big deal, that small movement at the start and end.

If you are playing a game, or doing something else interactive and many short sounds are played to call your
attention to the need to do something, your content can start to look like it's on a trampoline or something.

There is no good reason why playing a sound should change what is visible on the screen in any way that is unrelated to the sound.
lichess was cited - if this happens with every move as you intently stare at the board it breaks your concentration,
and gets annoying very quickly.

Plus there are multiple ways to easily fix this without changing the functionality at all.

Comment 51

[:Gijs (he/him)]

Clearing severity because I'm moving this to tabbed browser, as it's a tabstrip problem. I can repro on my Linux VM.

AFAICT this is Linux-specific; the only actual report of this on Windows is via comment #34, which doesn't actually appear to be the same issue (ie though hard to tell, the camera photos of the LCD screen don't seem to suggest the tabstrip changes size, and anyway that thread has comments suggesting it's resolved, whereas this bug persists, per the comments here).

Comment 52

[Dominique Pelle]

I can repro on my Linux VM.

Glad you could reproduce.
It might be useful to indicate which distro and version you use to reproduce, with which window manager?

Comment 53

[:Gijs (he/him)]

(In reply to Dominique Pelle from comment #52)

I can repro on my Linux VM.

Glad you could reproduce.
It might be useful to indicate which distro and version you use to reproduce, with which window manager?

Ubuntu 21.04, ubuntu:GNOME window manager (per XDG_CURRENT_DESKTOP, anyway).

I expect it's less distro/window-manager-related and more default-system-font-size (and potentially font-family) related. After bug 1704404 I expect the label height of the main tab title is a multiple of the font size as expressed in em. On Linux, that font size is usually but not always bigger than on Windows and macOS, which means less available space, unless we grow the tabstrip to match, which in turn upsets people who don't want to lose vertical space. Removing the "PLAYING" annotation entirely also isn't really an option because the design should be consistent across OSes, and I believe one of the ideas of this system is to use the subtext for other uses in the future... so we're going to have to find a way to make this work. Perhaps a mix of slightly reducing the font size of the main label and tightening up spacing, or something.

Comment 54

[tbgf6180]

A small (possible) mea culpa here regarding why this only reproduces sometimes.
Again, I am on Windows 10.

Straight-out-of-the-box Firefox uses VERY small fonts in the menus, options, tabs, and so forth.
To make it a little easier on these old, tired eyeballs, I have added some custom CSS in that regard.

I did that a long time ago, and mostly have forgotten about it, but some of the earlier discussion here
(or on one of the other of the many bugs on this issue) triggered my memory.

That may be a partial cause of the problem. Nevertheless, it should be fixable/fixed by changing
how PLAYING is displayed - either with smaller letters, or a symbol of some kind.

The most relevant section of the CSS I added is (probably) this -
(other changes to various menubars, toolbars, navbars, etc are the same as that):

/* Tab bar */
#TabsToolbar {
font-size: 17px !important;
padding: 2px !important;
}

The 2px padding number might be more !important than the font-size - since 2px is the magic number
of the resizing of the window content.

(And, no, I can't be bothered to test this - restarting Firefox multiple times is one thing in a developer environment,
but I have more useful things to accomplish, and want to keep my dozen or so windows and tabs open continuously.
The 2px padding is negotiable - the 17px font-size is not!)

Comment 55

[:Gijs (he/him)]

(In reply to tbgf6180 from comment #54)

Thank you! I've responded in the original bug you filed, which got reopened - bug 1729216 - to keep this bug focused on the Linux issue.

Comment 56

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 57

[Dão Gottwald [:dao]]

(In reply to :Gijs (he/him) from comment #53)

Removing the "PLAYING" annotation entirely also isn't really an option because the design should be consistent across OSes, and I believe one of the ideas of this system is to use the subtext for other uses in the future...

browser.tabs.secondaryTextUnsupportedLocales already prevents this, so I'm not really sure what the long term plans are here.

Comment 58

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1681421

Comment 59

[tbgf6180]

Perhaps this information will help.

Environment is Windows 10.

After some experimentation, using the userchrome feature, I can make the bug appear/disappear
by using different values for M and N in these rules:

#TabsToolbar {
font-size: Mpx !important;
}
/* Tab bar */
.tab-secondary-label {
font-size: Npx !important;
}

M: 16px or less, N: not set - no bug
M: 17px, N not set - bug
M: 17 px, N: 10px - no bug
M: 18 px, N: 9px - no bug

(I removed padding - not sure if there is any built-in or not.
Adding padding: 0px (or maybe 1px) might make a difference.)

Comment 60

[Lougenia Bailey]

:dao this is an s2 and we've picked up four duplicates, can this be prioritized?

Comment 61

[tbgf6180]

I would like to suggest another possible way to fix the problem:

Let me define the problem as: if the height of the tab increases (for whatever reason),
a corresponding reduction is made to the main viewport, causing various side effects,
such as a jump in the content.

In my case, since tweaking the CSS of the tab resulted in this happening,
it was dismissed as "we can't cater to every user whim, there are too many
possibilities".

My new suggestion then is simple enough: Don't increase the height of the tab.

That might mean that the new content (such as the word PLAYING) does not
display fully, but where is the harm in that? If it is caused by user CSS,
the user can adjust his CSS, or just ignore the issue. The ignore part of that
is harder when the main content is jumping up and down a lot (as is the case
when a series of short sounds is played, and PLAYING appears and disappears
repeatedly).

To refresh other solutions/workarounds:

• indicate "PLAYING" in some way that adjusts the tab horizontally
• reduce font sizes, spacing, padding or anything else that will make things fit.
  (the latter being what I did in my user CSS, so for me this is no longer a problem).

Comment 62

[Bernard Igiri]

I cannot reproduce this. I've tested on Ubuntu 21.04 (natively) and 20.03 LTS (in a VM with and without the Yaru theme) and the tab bar remains the same height whether the words "PLAYING" is displayed in the tab or not. I've found the easiest way to test this is to use YouTube. The behavior on Lichess.com does not appear to be different.

Comment 63

[Bernard Igiri]

Attachment: Bug 1714276 - Limit height of tab when font size is changed r=Dao

Set a maximum height on tabs to prevent it from expanding and moving the display of the web page.

Comment 64

[Bernard Igiri]

I found that on Ubuntu if you install Ubuntu Tweak and set the Interface Text font size to 13px or higher you can reproduce this using YouTube. Playing a video will show the "PLAYING" message increasing the size of the tab, and pausing will remove the message. This is a bit easier than testing with the Lichess website. I tested this fix up to 17px as that was the font size given by tbgf6180.

Comment 65

[tbgf6180]

Given a set of conditions that will make the PLAYING indication appear, as described in Comment #64 above, you can use ANY web page that plays a sound to reproduce the problem, .

This one for example, which I created for just that purpose: http://acrozilla.com/test1/soundtest.html

Youtube will also do that, but those pages are complex and may introduce extraneous factors.

Comment 66

[wi.alhant]

Hello,
Just want to chime in and say I am also affected by this issue.
I have the same issue and it has been annoying me for a couple of months.
Version/system: Firefox 94/Fedora Linux
I think I have the default system font but I have a text scaling factor with Gnome Tweaks.
A workaround is to use the toolbar in compact mode but this is not supported, so not ideal.

Comment 67

[Heikki Levanto]

This bothers me too. Both on lichess.org and BackgammonGalaxy.com. I find it easiest to demonstrate on lichess, when trying to solve the problem of the day. When you make a move, the "PLAYING" text appears, the tab height increases, and the main display area decreases. After making a move, wait a few seconds, and the "PLAYING" text disappears, and the screen flickers again.

This with Firefox 91.4.1esr (64-bit) on Debian Bullseye with a KDE desktop, and slighly enlarged default fonts, and a 4k monitor.

I did find that setting the tab bar to compact layout helps, as it displays just a small speaker icon on top of the favicon in the tab title, which does not cause resizing.

Comment 68

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/390617f829e1
Limit height of tab when font size is changed r=dao,desktop-theme-reviewers

Comment 69

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/390617f829e1

Comment 71

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

:bigiri can you nominate to uplift this to release?

Comment 72

[Bernard Igiri]

Comment on attachment 9255940 [details]
Bug 1714276 - Limit height of tab when font size is changed r=Dao

Beta/Release Uplift Approval Request

• User impact if declined: Tab height will display inconsistently on Linux when audio is being played.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: In Linux Ubuntu use Ubuntu Tweaks to set the font size to 13px or higher.
  Open YouTube in the browser.
  Hit play on a video.
  When the video is playing the words "PLAYING" should show on the tab but the height of the tab should not change. When the video is stopped, the words "PLAYING" should disappear and the height of the tab should still remain the same.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): CSS change only.
• String changes made/needed:

Comment 73

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

Comment on attachment 9255940 [details]
Bug 1714276 - Limit height of tab when font size is changed r=Dao

Approved for 96.0.2

Comment 74

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

https://hg.mozilla.org/releases/mozilla-release/rev/d601a4866184

Comment 75

[Alexandru Trif, Desktop QA [:atrif]]

Reproduced the issue with Firefox 91.0a1 (2021-06-02) on Ubuntu 18.04. Setting the font to at least 16px or 20px inside Tweaks and playing/stopping a video on youtube or making a move on the Lichess site makes the tab change the height when the Playing message is displayed.

I can no longer reproduce the issue with Firefox 98.0a1 (2021-01-20), 97.0b5, and 96.0.2 on Ubuntu 18. Tab height no longer changes when playing and stopping a video on Youtube or making a move inside the Lichess site while having the font set to 20px, 17px, 16px, and 13px.

Comment 76

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9255940 [details]
Bug 1714276 - Limit height of tab when font size is changed r=Dao

Simple fix for a widely-reported issue. Approved for 91.6esr also.

Comment 77

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/594ee0d78b9e

Comment 78

[Alexandru Trif, Desktop QA [:atrif]]

Verified fixed with Firefox 91.6.0esr (20220131231250) on Ubuntu 20.04 and Ubuntu 18.04. Using 16px and 10px font the tab no longer changes height when Playing/ Stopping a Youtube video.