1930236 - [Toolbar Redesign] Address bar content is very narrow since Firefox 133 on Android

Status: VERIFIED FIXED

(Firefox for Android :: Toolbar, defect, P1)

Description

[Rob Wu [:robwu]]

Attachment: Screenshot_left_Release_right_Beta.png

Since Firefox 133 (currently Beta), buttons are taking more horizontal space in the address bar.
On some sites, Firefox displays two additional buttons (Reader View, Translate). With these shown, there is barely any space left do display the URL! I find that concerning because the address bar is an important security indicator (displaying the origin/URL of the website).

I think that this regressed by bug 1920554.

The attached screenshot from a Pixel 8 phone shows a comparison between Firefox 132.0.1 (left) and Firefox 133.0b4 (right) when visiting https://tweakers.net/nieuws/228532/supermarkt-albert-heijn-voegt-generatieve-ai-toe-aan-mijn-ah-app.html

• 132 shows: tweakers.net/nieuws/ (with the trailing slash faded out)
• 133 shows: tweakers.net/n (with the trailing n partially visible)

When I visit https://nl.m.wikipedia.org/`, I see

• 132 shows: nl.m.wikipedia.org/wi (with the trailing i faded out).
• 133 shows: nl.m.wikipedia (with the trailing a faded out). NOTE: As a user, I can now not see whether this is the real wikipedia, or a fake one whose subdomain starts with the same.

Comment 1

[Rob Wu [:robwu]]

Attachment: Addressbar_132_expected.png

Screenshot of address bar from 132 with expected display.
It shows: tweakers.net/nieuws/ (with the trailing slash faded out)

Comment 2

[Rob Wu [:robwu]]

Attachment: Addressbar_133_actual.png

Screenshot of address bar from 133 with the larger buttons and smaller address bar content.
It shows: tweakers.net/n (with the trailing n partially visible). This amount of text is too little.

Comment 3

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

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

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

For more information, please visit BugBot documentation.

Comment 4

[Chris Peterson [:cpeterson]]

Aarjav, what is the intended design? Do the a11y guidelines require this much visual padding or can we just increase the touch target sizes without increasing the padding? Does Firefox iOS have this same issue with toolbar padding?

Comment 5

[Petru-Mugurel Lingurar [:petru]]

Attachment: image.png

bug 1920554 did not modify the size/margins of toolbar buttons so it didn't regress this.
Looking back in commit history and reverting some patches we see that we now have less space to display the current URL after:

• bug 1919161 - which made the menu button wider - 48dp vs 36dp
• bug 1909751 - which added a 32dp padding to the toolbar buttons

Leaving for Aarjav to decide whether we should revert any of the above two patches.

(each of the attached "without bug.." screenshots build upon the above screenshot. So "Without bug 1919161" contains also the revert of 1920554 and "Without bug 1909751 contains also the revert of 1919161 & 1920554)

Comment 6

[Rob Wu [:robwu]]

Thanks for identifying the regressors correctly.

Comment 7

[Petru-Mugurel Lingurar [:petru]]

Regarding

can we just increase the touch target sizes without increasing the padding

We can't. We tried something like this in the past and it works for just one child in a parent that has the available space.
But when there are multiple buttons near each other and we update the touch area for them in a loop only the last updated one will actually have a larger touch area.
This because we need the actual physical space for larger buttons/touch areas - otherwise with just increasing touch areas but the buttons physically too close to each other the touch areas would overlap and we wouldn't know which button was acted upon when the user taps in that overlapping space.

Comment 8

[Channing]

Release blocker.

Comment 9

[Christoph Kerschbaumer [:ckerschb}]

Hey Roger, I am the REO for Fx133. As the triage owner I want to bring this bug to your attention as it is marked as a release blocker and the last day for Beta uplifts is this week on the 14th/15th.

Comment 10

[Joe M [:jmahon]]

:ckerschb, apologies, I think this was marked as release blocker in error. Channing's comment was that it's a release blocker for the Toolbar project, which in our working group means that it's a blocker for us to allow that feature to ride the train to release. This doesn't affect the overall release.

I've updated the tracking flags accordingly.

Comment 12

[Rob Wu [:robwu]]

(In reply to Joe M [:jmahon] from comment #10)

:ckerschb, apologies, I think this was marked as release blocker in error. Channing's comment was that it's a release blocker for the Toolbar project, which in our working group means that it's a blocker for us to allow that feature to ride the train to release. This doesn't affect the overall release.

This description is inaccurate - not doing anything will cause a regression when this rides to release (in two weeks).

The toolbar project includes a new URL bar with more space. As an unintended side effect of the implementation the old toolbar's URL bar shrunk, as seen in the report.

I think that these are the current options:

1. Do nothing - let this regression ride to release. Impact: security risk, increased domain spoofing risk due to narrower URL bar.
2. Revert regressors - comment 8 identified the regressors. If feasible, could revert some or all of them on Beta 133 to buy us more time.
3. Enable toolbar on beta 133 (ride to release) - the new toolbar does not suffer from this specific bug. Risk: I don't know, but it sounds like it was still under active development.

Joe, given the above, do you still consider this to not be true release blockers?

Comment 13

[Zac McKenney [:zmckenney]]

Attachment: reverted-only-1909751

(In reply to Petru-Mugurel Lingurar [:petru] from comment #5)

Created attachment 9436663 [details]
image.png

bug 1920554 did not modify the size/margins of toolbar buttons so it didn't regress this.
Looking back in commit history and reverting some patches we see that we now have less space to display the current URL after:

• bug 1919161 - which made the menu button wider - 48dp vs 36dp
• bug 1909751 - which added a 32dp padding to the toolbar buttons

Leaving for Aarjav to decide whether we should revert any of the above two patches.

(each of the attached "without bug.." screenshots build upon the above screenshot. So "Without bug 1919161" contains also the revert of 1920554 and "Without bug 1909751 contains also the revert of 1919161 & 1920554)

This is very helpful! I think our biggest issue here is bug 1909751 which if reverted by itself produces this result. There are only minor dimens.xml conflicts when backing out and it should fix the old toolbar. Also, at least in my brief testing on a Pixel 7 Pro this does not break the new toolbar either as seen in my second attached image.

Comment 14

[Zac McKenney [:zmckenney]]

Attachment: reverted-only-1909751-new-toolbar.png

Comment 15

[Rob Wu [:robwu]]

I chatted with :dmeehan to ask why bug 1919161 was dropped as regressor despite it being one of the two causes of this bug.

The reason was to make it easier to track the backout.

I am adding it back as "see also" to keep the bug relations more obvious.

For clarity:

• bug 1909751 was the biggest cause of this bug as seen in comment 13.
• bug 1919161 contributed to this bug too, although not as severe as the other bug.

Comment 16

[Donal Meehan [:dmeehan]]

Setting Fx133 to disabled since Bug 1909751 was backed out of beta

Comment 17

[Zac McKenney [:zmckenney]]

(In reply to Rob Wu [:robwu] from comment #15)

I chatted with :dmeehan to ask why bug 1919161 was dropped as regressor despite it being one of the two causes of this bug.

The reason was to make it easier to track the backout.

I am adding it back as "see also" to keep the bug relations more obvious.

For clarity:

• bug 1909751 was the biggest cause of this bug as seen in comment 13.
• bug 1919161 contributed to this bug too, although not as severe as the other bug.

:robwu, the reason for bug 1919161 changing the icons from 36dp to 48dp was also to address a11y issues. I think reverting those is a bigger issue than removing padding (1909751). We're up against two competing issues with that ticket now, the smaller URL bar and the A11Y requirements. I'm not sure how we are going to handle this yet but just backing out 1909751 at least unblocks the release for now.

Comment 18

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

The bug is marked as tracked for firefox134 (nightly). We have limited time to fix this, the soft freeze is in 7 days. However, the bug still isn't assigned and has low severity.

:royang, could you please find an assignee and increase the severity for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 19

[Simon Friedberger [:simonf]]

We should specify where we draw the line for the future. Only displaying .com is clearly not enough but we probably don't need to support domains which are 80 characters long.
So we should agree on a length that must remain visible on devices we want to support properly. From a quick look at random Top 1k site I am guessing the number should be somewhere around 25 characters.

13 microsoft.com
16 steampowered.com
17 stackoverflow.com
17 bankofamerica.com
18 steamcommunity.com
19 mercadolivre.com.br
20 bancodevenezuela.com
21 centraldasapostas.net
22 lotterysambadresult.in

(Disclaimer: I may be missing some context on the general importance of the address bar on mobile.)

Comment 20

[Chris Peterson [:cpeterson]]

Since this bug is about the new toolbar's padding affecting the old toolbar, this bug isn't a block for the new toolbar's Beta 134 experiment, but we should resolve (with a fix or an agreement to WONTFIX) before Fx 134 release.

Comment 21

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

This is a reminder regarding comment #18!

The bug is marked as tracked for firefox134 (nightly). We have limited time to fix this, the soft freeze is in a day. However, the bug still isn't assigned.

Comment 22

[Petru-Mugurel Lingurar [:petru]]

We have a backout of patch of bug 1909751 ready, tagging Zach to decide if this should be landed now.

Comment 23

[Petru-Mugurel Lingurar [:petru]]

Based on the feedback here it seems like only the above backout would be enough for now.
But we already had plans to update the UX of the addressbar in a later effort so I opened bug 1932350 to remember considering the security implications of modifying the address bar layout.

Comment 24

[[:harrisono]]

sorry, I accidentally closed the wrong ticket.

Comment 25

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

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

Comment 26

[Petru-Mugurel Lingurar [:petru]]

(In reply to Petru-Mugurel Lingurar [:petru] from comment #22)

We have a backout of patch of bug 1909751 ready, tagging Zach to decide if this should be landed now.

The backout was linked to bug 1909751 already.
What still remains is bug 1932350 as a followup.

Comment 27

[tchoh]

Read Petru's Comment.
Fixed by back out.

Comment 28

[Donal Meehan [:dmeehan]]

:tchoh reopening since the regressor Bug 190975 was only backed out of beta for Fx133.
It was never backed out of central. I'm not sure why you resolved this?

Comment 29

[tchoh]

Apologies for the confusion.
There was confusion on the team regarding what to backout.
The team will back it out and close once its completed.

Comment 30

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug 1930236 - Revert "Bug 1909751 - Adjust margins for Toolbar" r=#android-reviewers

This will ensure more available space for the URL view.
More investigation / possible updates to come later.

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/144d526a18c6
Revert "Bug 1909751 - Adjust margins for Toolbar" r=android-reviewers,tchoh

Comment 32

[amarc]

https://hg.mozilla.org/mozilla-central/rev/144d526a18c6

Comment 33

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

The patch landed in nightly and beta is affected.
:petru, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox134 to wontfix.

For more information, please visit BugBot documentation.

Comment 34

[Petru-Mugurel Lingurar [:petru]]

Comment on attachment 9442703 [details]
Bug 1930236 - Revert "Bug 1909751 - Adjust margins for Toolbar" r=#android-reviewers

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Smaller URL view -> a smaller part of the URL is displayed potentially impacting security.
• 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: Ensure not using the navbar
  Check that the home button and the menu buttons are now more closer to the edge of the screen allowing for a slightly wider URL view.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small targeted change.
  Backout uplifted in 134 after the same happened one month ago for 133.
• String changes made/needed:
• Is Android affected?: Yes

Comment 35

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/6120b7aff73a

Comment 36

[Delia Pop (Android QA)]

Attachment: 2c37bec4-9062-49c8-8119-7561bce43b40.JPEG

Verified as fixed in Nightly 135.0a1 from 12/13 with Google Pixel 8 Pro (Android 14) and OPPO A15s (Android 10).

Comment 37

[Delia Pop (Android QA)]

Attachment: 1930236_beta.jpg

Verified as fixed in Beta 134.0b10 with Samsung Galaxy A53 5G (Android 14) and OPPO A15s (Android 10).