1914978 - `webNavigation.onDOMContentLoaded` should preserve text fragments in `details.url`

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[sycxyc+mozilla]

Attachment: test_webnavigation-1.zip

Steps to reproduce:

1. Enable dom.text_fragments.enabled on the about:config page.
2. Load the "test_webnavigation-1.zip" temporary extension and open this extension console.
3. Open "https://www.example.com/#hash:~:text=This-,domain,-is%20for%20use".

Actual results:

The extension console prints the url on the onDOMContentLoaded line as “https://www.example.com/#hash".

Expected results:

The extension console prints the url on the onDOMContentLoaded line as “https://www.example.com/#hash:~:text=This-,domain,-is%20for%20use".

Comment 1

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

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

Comment 2

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (131.0a1/20240827213859), Beta (130.0/20240826200919) and Release (129.0.2/20240819150008) under Windows 10 and macOS 11.3.1.

The issue occurs as described in Comment 0. See the attached screenshot for more details.

Comment 3

[Alex Cornestean]

Attachment: 2024-08-28_10h59_12.png

Comment 4

[Rob Wu [:robwu]]

Note that Chrome does include the text fragment in the URL in extension events, at least the given test case.

The question is what we should do here. Including the fragment enables extensions to detect the fragment and do something with it. But text fragments are hidden from scripts by design, so if an extension tries to correlate the URL as observed in the document (e.g. in a content script) with the URL as seen from extension, then that logic would break).

We retrieve the URL as documentURI at https://searchfox.org/mozilla-central/rev/55f2ada1564baaeebd69d277b38737961a3ca5f3/toolkit/components/extensions/webrequest/WebNavigationContent.cpp#119

Comment 5

[sycxyc+mozilla]

WebExtensions should need to be able to detect the fragment directive. I believe that preserving the fragment directive in the url is the simplest solution without altering the API design.

Because the fragment directive is preserved in browser history, the URL object, and <a> elements, compatibility issues may be hard to avoid.

Comment 6

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

The severity field is not set for this bug.
:robwu, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Rob Wu [:robwu]]

(In reply to sycxyc+mozilla from comment #5)

WebExtensions should need to be able to detect the fragment directive.

What is the use case for that? With built-in support for text fragments, navigation to a text fragment is comparable to the user pasting the original URL and then jumping to some place in the page.

Comment 8

[sycxyc+mozilla]

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

What is the use case for that?

Some extensions may need to read the full URL for purposes such as restoring the URL, handling text fragments, or interacting with the history and bookmarks APIs to perform certain actions.

The inconsistent behavior of webNavigation.onDOMContentLoaded may cause regression issues in the extension, requiring the implementation of additional compatibility logic.