1766143 - When opening settings from about:logins (direct link to subcategory), clicking Back button causes the page to re-scroll but doesn't go "back"

Status: NEW

(Firefox :: Settings UI, defect, P5)

Description

[creative854379]

Attachment: Logins & Passwords — Mozilla Firefox 2022-04-24 15-16-32.mp4

[Affected versions]:

• Firefox Nightly 101.0a1 (2022-04-23) (64-bit)
• Firefox Release 99.0.1 (64-bit)

[Affected Platforms]:

• Windows 10 x64

[Steps to reproduce]:

1. Launch Firefox, and access "about:logins".
2. Click on the "..." Menu button.
3. Select the “Options” option, and the page jumps to a new tab "about:preferences#privacy".
4. Click the Back button (left arrow) in the upper left corner

[Expected result]:

• Back button is grey and cannot be clicked, because there is no previous page.

[Actual result]:

• After clicking the Back button, the page "about:preferences#privacy" quickly scrolls down from the top to "Logins and Passwords".

Comment 1

[Peter Magyari (Desktop QA)]

I can also reproduce this on MacOS 11.

I'm setting the flags accordingly.

Thank you for reporting!

Comment 2

[:Gijs (he/him)]

The reason this happens is that the link opening from about:logins points to about:preferences#privacy-logins, which gets normalized to a single category link (#privacy). The way that normalization works means we navigate. This means there's a history entry for #privacy-logins and one for #privacy. The "right" fix (which would result in the expected behaviour listed in comment 0, ie disabled back button) would mean not having a history entry getting created for this.

Fixing this requires functioning replaceState support for about: URLs, which we don't have. Quoting from an earlier comment from me elsewhere:

My next thought was to use history.replaceState [...] but unfortunately (a) we fail here because we can't get a userpass info for the magical about: URL, but even if we fix that, no about:[something] url is ever same origin with another as far as nsIScriptSecurityManager::CheckSameOriginURL is concerned, because you can't QI those URLs to nsIStandardURL. I am... not convinced we want to open that can of worms. :-\

We would need to fix both the replacestate code and the CheckSameOriginURL thing, and we might still need to specialcase about:blank and talk to DOM folks about spec compliance (would need some testing).

I don't think we can justify that kind of investment for this minor bug.

---

An alternative fix would be to not replace #privacy-logins with #privacy at all (ie keep the URL) but ISTR there was a conscious decision to do it this way and not have user-visible permalinks for these sub-items. I don't remember exactly why, though... Jared, do you recall?

Comment 3

[:Gijs (he/him)]

It seems the about: URL thing is not spec-compliant as-is, so if there's enough impetus to fix that in the DOM code fixing this bug would become more feasible.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

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

The reason this happens is that the link opening from about:logins points to about:preferences#privacy-logins, which gets normalized to a single category link (#privacy). The way that normalization works means we navigate. This means there's a history entry for #privacy-logins and one for #privacy. The "right" fix (which would result in the expected behaviour listed in comment 0, ie disabled back button) would mean not having a history entry getting created for this.

Fixing this requires functioning replaceState support for about: URLs, which we don't have. Quoting from an earlier comment from me elsewhere:

My next thought was to use history.replaceState [...] but unfortunately (a) we fail here because we can't get a userpass info for the magical about: URL, but even if we fix that, no about:[something] url is ever same origin with another as far as nsIScriptSecurityManager::CheckSameOriginURL is concerned, because you can't QI those URLs to nsIStandardURL. I am... not convinced we want to open that can of worms. :-\

We would need to fix both the replacestate code and the CheckSameOriginURL thing, and we might still need to specialcase about:blank and talk to DOM folks about spec compliance (would need some testing).

I don't think we can justify that kind of investment for this minor bug.

---

An alternative fix would be to not replace #privacy-logins with #privacy at all (ie keep the URL) but ISTR there was a conscious decision to do it this way and not have user-visible permalinks for these sub-items. I don't remember exactly why, though... Jared, do you recall?

I don't recall the reason here. It was not security or privacy related. If anything it may have been just to have single code paths once we normalize a path. If it's easy to clean up or follow the code paths without changing the hash then we should remove the code that normalizes "#privacy-logins" to "#privacy".

Comment 8

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

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1494353: S3

:jhirsch, could you consider increasing the severity of this bug to S3?

For more information, please visit BugBot documentation.

Comment 9

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Sure, BugBot, sounds good