Open Bug 1707907 Opened 4 years ago Updated 1 year ago

The 'cache firefox' intervention help button is displayed on another row with a minimum width

Categories

(Firefox :: Address Bar, defect, P5)

Desktop
All
defect
Points:
2

Tracking

()

Tracking Status
firefox-esr78 --- unaffected
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- fix-optional

People

(Reporter: cbaica, Unassigned)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [proton-address-bar])

Attachments

(3 files)

Affected versions

  • Fx89.0b4
  • Fx90.0a1

Affected platforms

  • Windows 10
  • Ubuntu 18.04

Steps to reproduce

  1. Launch Firefox.
  2. Resize the Firefox window to its minimum width.
  3. Click on the address bar and type in 'cache firefox'.
  4. Inspect the available buttons in the dropdown.

Expected result

  • The intervention buttons are displayed on the same row regardles of browser size.

Actual result

  • The buttons ('Choose What to Clear' and '?') are displayed on separate rows.

Regression range

  • This is not a regression. Happened with the switch to the new design (Firefox 88 is unaffected).

Additional notes

  • This does not occur for other interventions like 'refresh firefox', 'update firefox' (for both download and restart buttons).
Whiteboard: [proton-address-bar]

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #0)

  • This is not a regression. Happened with the switch to the new design (Firefox 88 is unaffected).

Are you sure? I can reproduce this on 88 on Mac without Proton. Could you find a regression range if you have time? It's certainly possible a Proton-related change caused it though, even if Proton doesn't need to be enabled for it to happen.

Flags: needinfo?(cristian.baica)
Severity: normal → S4
Points: --- → 2
Priority: -- → P3
Attached video cache firefox bug

This seems to be weird. For whatever reason, this does not occur in Fx88.0b9 on windows. You can see in this in the newly attached file.

Flags: needinfo?(cristian.baica)

OK. It's possible there's some platform-specific width/padding/margins/whatever that's relevant. It may be related to the minimum width of the urlbar. A regression range would still be helpful IMO, but it's not a high priority since this only happens in very narrow windows.

QA Whiteboard: [qa-regression-triage]
Has STR: --- → yes
Attached video repro demo.webm

While attempting to investigate for a regression I have noticed that the issue also occurs at different widths, not just at the minimum one. It appears to be influenced by the wrapping of the text it is related to.

I have attached this demonstration rather than a more detailed explanation.

I will attempt regression investigation with the following steps:
1. Launch Firefox.
2. Click on the address bar and type in 'cache firefox'.
3. Resize the Firefox window slowly towards its minimum width.
4. Pay attention to the wrong wrapping of the suggestion under the address bar and its 2 buttons.

First mozregression result:

2021-05-09T23:25:25.821000: DEBUG : Found commit message:
Bug 1693376 - Move save to Pocket to the toolbar. r=Gijs,fluent-reviewers,gvn,flod
Differential Revision: https://phabricator.services.mozilla.com/D107744

Another, more believable mozregression result:

2021-05-09T23:39:04.735000: DEBUG : Found commit message:
Bug 1697023 - Add end margin/padding back to urlbar tips and their buttons. r=harry

This fixes a couple of problems introduced in bug 1692526 with tips that don't have help buttons:

The main button focus ring is cut off on the right edge as shown in the bug. This patch fixes that 
by adding:

.urlbarView-tip-button {
  margin-inline-end: 4px;
}

The main button is too close to the edge of the row, fixed by:

.urlbarView-row[type=tip] {
  padding-inline-end: calc(@urlbarViewIconMarginEnd@);
}

`urlbarViewIconMarginEnd` was removed recently in bug 1695022 (D107568), I'm
guessing because it was only used in one place, but I need it here so I've added
it back. It corresponds to the old `urlbarViewItemInlinePadding` variable that
we used for tips before I incorrectly stopped using it in bug 1692526 [1].

I didn't take tips without help buttons into account when I fixed bug 1692526.
Tips with help buttons look fine currently. Their help buttons are closer to the
edge of the row than they used to be, but that was intentional because I think
it looks better since the help button doesn't have a background like the main
button does. This patch reverts that because it's not possible to keep without
adding a new class or attribute on tips with/without help buttons, and I don't
think it's worth it since we can just revert back to the status quo we had for a
long time, which looks fine too.

[1] https://hg.mozilla.org/mozilla-central/diff/87ab179e18da832a091aa4150ba0e6589baa43ec/browser/themes/shared/urlbarView.inc.css#l1.39

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

The issue was investigated on Windows 10. NI me if more info si needed.

Regressed by: 1697023
Has Regression Range: --- → yes
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: