1610688 - Container names on small width resolution hide URL in address bar & ALSO prevent use of installed extensions via Address Bar plugin icons

Status: RESOLVED DUPLICATE of bug 1545046

(Firefox :: Address Bar, defect)

Description

[YDQ]

Attachment: Overflow Issue - Temporary Containers Animated GIF

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

1. Set width of browser to something like 900px wide or less (This small width makes the problem immediately apparent to user)
2. Install Temporary Containers extension & a couple other extensions with extension popup windows (e.g. uBlock Origin and Cookie Auto Delete)

Related bug report filed with Temporary Containers extension github issue tracker prior to opening issue on Bugzilla: https://github.com/stoically/temporary-containers/issues/364

Actual results:

1. Container name will be shown & the URL will ALWAYS be hidden on small width display (this is dangerous as user has no idea what domain they are on).
2. If the container name is a long name (e.g. using the extension generated container names when utilizing the "Deletes History Temporary Containers" feature of Temporary Containers extension) will cause a display overflow and overlap on the right side of the Address Bar & block the ability to access other installed extension popup windows from the toolbar.

Expected results:

1. For user security the URL should have higher visibility priority than container name so they can verify they are on correct domain before entering sensitive information and not entering data as part of phishing attack.
2. Container name should also not overlap extension popup icons causing them to be unclickable

For testing purposes, I believe the container name being displayed over other extension popups started in either Firefox v70.0 or 71.0 but prioritizing the container name over the URL has always been present.

Comment 1

[:Gijs (he/him)]

This is basically a dupe of bug 1597181, with potential fixes in bug 1601334 (on nightly atm). Dunno if the containers stuff means this is worth keeping separately - we could/should probably increase the minimum width when a container label is present - Dão?

I don't think there's much point keeping it security-sensitive as the window width cannot be determined by an attacker and the problem is otherwise very apparent, but I'll leave that decision with you as well...

Comment 2

[Dão Gottwald [:dao]]

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

This is basically a dupe of bug 1597181, with potential fixes in bug 1601334 (on nightly atm). Dunno if the containers stuff means this is worth keeping separately - we could/should probably increase the minimum width when a container label is present - Dão?

This doesn't sound very desirable as it would push other toolbar elements into overflow, plus the label disappears / changes when switching tabs. And then we also seem to allow arbitrarily long container labels; I'd say we should impose a limit here and display the full label in a tooltip.

Comment 3

[YDQ]

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

This is basically a dupe of bug 1597181, with potential fixes in bug 1601334 (on nightly atm). Dunno if the containers stuff means this is worth keeping separately - we could/should probably increase the minimum width when a container label is present - Dão?

I don't think there's much point keeping it security-sensitive as the window width cannot be determined by an attacker and the problem is otherwise very apparent, but I'll leave that decision with you as well...

Sorry for somewhat off-topic question, are you saying changing the security-sensitive flag is my decision or Dao? I'm fine with security sensitive flag being removed so discussion is more open if you all agree.

Comment 4

[Johann Hofmann [:johannh]]

This is a dupe of bug 1545046