`/history`'s `history-event`s do not `open` when their relevant `id=` has a fragment directive appended.

[RokeJulianLockhart]

meta:295150

What The Problem Is

linux.codidact.com/posts/294865/history#3 renders the relevant revision, expanded. by contrast, when a fragment directive is appended, like linux.codidact.com/posts/294865/history#3:~:, it does not:

17:06:22.253 Uncaught Error: Syntax error, unrecognized expression: #3:~:text=it.%20They%20must%2C-,instead%2C%20merely%20wait,-for%20it%20to
    jQuery 7
        error
        tokenize
        select
        fa
        find
        init
        n
    t https://linux.codidact.com/assets/application-f633374372c26fba22ed96cbc21568af874c89721872e975217d544f37266dbc.js:74
    EventListener.handleEvent* https://linux.codidact.com/assets/application-f633374372c26fba22ed96cbc21568af874c89721872e975217d544f37266dbc.js:74
    jQuery 8
        i
        fireWith
        ready
        J
        promise
        <anonymous>
        <anonymous>
        <anonymous>
jquery.min.js:2:12556
    jQuery 7
        error
        tokenize
        select
        fa
        find
        init
        n
    t https://linux.codidact.com/assets/application-f633374372c26fba22ed96cbc21568af874c89721872e975217d544f37266dbc.js:74
    (Async: EventListener.handleEvent)
    <anonymous> https://linux.codidact.com/assets/application-f633374372c26fba22ed96cbc21568af874c89721872e975217d544f37266dbc.js:74
    jQuery 8
        i
        fireWith
        ready
        J
    (Async: EventListener.handleEvent)
        promise
        <anonymous>
        <anonymous>
        <anonymous>

This is problematic when the user wants to link to a text fragment.

How To Reproduce It

1. #!/usr/bin/env xdg-open
   window.location.href = 'https://linux.codidact.com/posts/294865/history#3:~:text=it.%20They%20must%2C-,instead%2C%20merely%20wait,-for%20it%20to';

2. Select the //*[@id="toolbox-tab-webconsole"].

3. Expand the relevant div.message:nth-child.

Expected Behaviour

The relevant details.history-event should open.

My Environment

• QPixel

  Version 1ff2d8b7 (2025-11-19 11:32:27Z)

• My Browser

  1. #!/usr/bin/env sh
     rpm -qi $(rpm -qf $(command -v firefox))

  2. Name        : firefox
     Version     : 145.0.1
     Release     : 1.fc43
     Architecture: x86_64
     Install Date: Sun 23 Nov 2025 03:06:22 GMT
     Size        : 267898587
     Signature   :
                   RSA/SHA256, Thu 20 Nov 2025 08:37:07 GMT, Key ID 829b606631645531
     Source RPM  : firefox-145.0.1-1.fc43.src.rpm
     Build Date  : Wed 19 Nov 2025 09:22:06 GMT
     Build Host  : buildhw-x86-08.rdu3.fedoraproject.org
     Packager    : Fedora Project
     Vendor      : Fedora Project
     Bug URL     : https://bugz.fedoraproject.org/firefox

[trichoplax]

On Firefox 145.0.1 on Fedora 43, the following URL renders correctly for me, highlighting the phrase "instead, merely wait":

https://linux.codidact.com/posts/294865/history#3:~:text=it.%20They%20must%2C-,instead%2C%20merely%20wait,-for%20it%20to

I don't know why I'm seeing different behaviour on the same browser and operating system. Let me know if there's anything else you'd like me to test to narrow things down.

[RokeJulianLockhart]

@trichoplax, apologies; I attempted to confirm with a new profile, and realised that it works there, so I now realise that this is because I am, instead, utilising ichaoX/ext-textFragment with dom.text_fragments.enabled: false, due to what ichaoX/ext-textFragment/issues/26#issuecomment-3547761362 describes. Therefore, I have reported this at ichaoX/ext-textFragment/issues/29.

However, I'll note that the ECMAScript console continues to report the error.

[trichoplax]

Thanks for tracking down the root cause. I don't see an error in the console tab of the developer tools in Firefox or Chromium on Fedora. Do you see the error in the console even in the new profile without the extension? I'm checking because it would be good to avoid the error in the console even if it does not affect the presentation of the page.

[trichoplax]

To reproduce the error in the console, in Firefox enter about:config in the URL bar, then after accepting the safety warning enter dom.text_fragments.enabled and set the value to false. This suppresses displaying the text fragment when visiting https://linux.codidact.com/posts/294865/history#3:~:text=it.%20They%20must%2C-,instead%2C%20merely%20wait,-for%20it%20to and results in the page being displayed at the top as if no id had been specified. In the console there is an error message:

Uncaught Error: Syntax error, unrecognized expression: #3:~:text=it.%20They%20must%2C-,instead%2C%20merely%20wait,-for%20it%20to
    jQuery 7
    t https://linux.codidact.com/assets/application-d3321e2cea20edcad0f5c17f09bd5e27603f621e66a288092a1c47b937ae40ac.js:74
    <anonymous> https://linux.codidact.com/assets/application-d3321e2cea20edcad0f5c17f09bd5e27603f621e66a288092a1c47b937ae40ac.js:74
    jQuery 8
jquery.min.js:2:12556

[trichoplax]

I'm reopening this issue for 2 reasons:

1. We should ideally avoid errors in the console even when they have no effect on the displaying of the page, to reduce the chance of important errors being overlooked.
2. In this particular case, there is an effect on the displaying of the page, as described below.

When dom.text_fragments.enabled is set to false in Firefox configuration, the browser ignores the text fragment directive part of the URL (which begins with :~:). The result should be the same as visiting the URL with that part omitted. However, the #3 is also ignored, so the third revision in the edit history is not expanded and scrolled to. The result is the equivalent of entering https://linux.codidact.com/posts/294865/history into the URL bar rather than https://linux.codidact.com/posts/294865/history#3.

This is independent of the third party extension mentioned in the issue description. I am not using any extensions and can still reproduce the console error message, and the subsequent ignoring of the #3 part of the URL.

Note that visting https://linux.codidact.com/posts/294865/history#3 when dom.text_fragments.enabled is set to false results in correct processing of the #3 by Firefox. It's not clear to me whether the incorrect display after we get a jQuery error is a Firefox bug but we should avoid the error anyway if possible.

[RokeJulianLockhart]

@trichoplax, thanks for the diagnosis! (I just confirmed that chromium-143.0.7499.40-1.fc43 and firefox-145.0.1-1.fc43, in new profiles, don't reproduce this, so I would have not thought to attribute the error appearing due to the flag being false.)

Because I can also confirm that this reproduces solely with dom.text_fragments.enabled: false, I'll close ichaoX/ext-textFragment/issues/29. Instead, do you reckon I should take this to bugzilla.mozilla.org/enter_bug.cgi?product=Firefox, or is such a question premature?