1864867 - No "Open link in new [window/tab]" context menu entry for `about:.*` URIs.

Status: NEW

(Core :: Networking, defect, P3)

Description

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

Environment

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

Steps to reproduce

1. Select /html/body/div[4]/div/div[2]/main/section/article/section/p[2]/strong at support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles (which should be code, not strong):

   about:profiles

2. Invoke the context menu (≡⃣).

Actual results

It did not appear to be recognized as a URI, despite being valid and visitable from Firefox.

Expected results

It should be treated as any other URI would – the schema should be irrelevant. I think this is just a RegEx nonconformity issue.

Comment 1

[Dana Lucaci, Desktop QA]

Reproduced the issue with Firefox 119.0 (2023-10-16) on Ubuntu 22.04.
Marking issue as new for engineering input. Thank you.

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

No sure what's the problem here - the URL can be opened with Firefox 121.0.1. Can you be more specific?
Thanks.

Comment 5

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

Attachment: Presence of Context Menu Entries from Non-Hyperlinked Domain Selection

the URL can be opened with Firefox 121.0.1. Can you be more specific?

Yes. The problem arises solely with about: URIs that aren't encapsulated with <a href>s.

Examples

1. text/plain

   1. https://example.com

      Selection and secondary-click produces the correct context menu entries.

   2. ftp://example.com

      Selection and secondary-click produces the correct context menu entries.

   3. example.com

      Selecting this produces the relevant options. It isn't automatically hyperlinkified (which is understandable), so secondary-click isn't relevant.

   4. about:blank

      Neither work for this. Additionally, it should be hyperlinkified, but isn't.

2. <a href>

   1. https://example.com

      Selection and secondary-click produces the correct context menu entries.

   2. ftp://example.com

      Selection and secondary-click produces the correct context menu entries.

   3. example.com isn't a valid URI, so converting it to a hyperlink would cause the browser to consider it to be a path relative to the current domain.

   4. about:preferences

      Selecting this doesn't produce the correct options, but secondary-clicking it does. However, the options are non-functional:

      1. When I try about:blank, I am redirected to about:blank, albeit with nothing in the omnibox.
      2. When I try about:preferences, I am again redirected to about:blank, albeit with about:preferences prefilled in the omnibox.

Environment

firefox-135.0.1-1.fc41.x86_64

Meta

Ideally, for the sake of semantics, the content of the text/plain section should be encapsulated within a <pre><code> (~~~txt), but Bugzilla doesn't hyperlinkify its content like it does for CommonMark text. Is that deficiency being tracked anywhere (yet)?

Comment 6

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

Attachment: Lack of Context Menu Entries from Non-Hyperlinked `about` URI Selection

Comment 7

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

Attachment: Presence of Context Menu Entries from Hyperlinked `about` URI Secondary-Click

Comment 8

[Martin Stránský [:stransky] (ni? me)]

I guess we'd need to add about: as uri scheme but I'm not sure which component is that. Tentatively moving to networking.

Comment 9

[Masatoshi Kimura [:emk]]

We should not allow to open privileged about: pages from web content.

Comment 10

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

#c9

This is about the explicit context menu option on selection of text, irrespective of whether it's been rendered as a hyperlink. As aforementioned, regarding hyperlinks, I believe that single-click is already blocked.

Though, more broadly, what's the security gain from disabling either? Immediately, one might think that it prevents a website from autofilling dangerous parameters in about: URIs, but they can still just as easily plonk the URI content in a <p> and then ask the user to copy and paste into the omnibox. Heck, they can even automatically paste it into the clipboard, obfuscating it as much as an <a href> can.