Open Bug 1909942 Opened 1 year ago Updated 9 months ago

Text Fragment scrolling fails if the text fragment consists of special characters

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox128 --- unaffected
firefox129 --- unaffected
firefox130 --- disabled

People

(Reporter: phorea, Unassigned)

References

(Blocks 2 open bugs)

Details

Found in

  • Nightly 130.0a1;

Affected versions

  • Nightly 130.0a1;

Tested platforms

  • Ubuntu 22;
  • macOS 14;
  • Windows 10;

Affected platforms

  • Ubuntu 22;
  • macOS 14;
  • Windows 10;

Preconditions

  • Have dom.text_fragments.enabled to TRUE

Steps to reproduce

  1. Access https://datatracker.ietf.org/doc/html/rfc3986#page-24:~:text=:
  2. Access https://datatracker.ietf.org/doc/html/rfc3986#page-24:~:text=/
  3. Access https://datatracker.ietf.org/doc/html/rfc3986#page-24:~:text=#
  4. Access https://datatracker.ietf.org/doc/html/rfc3986#page-24:~:text=&
  5. Access https://datatracker.ietf.org/doc/html/rfc3986#page-24:~:text=,

Expected result

  • Text fragments directive is applied, text highlighted and scrolled to.

Actual result
case 1. and 2. Characters are highlighted but placed out of view, the page is scrolled below them.
case 3. "#" is not highlighted nor scrolled to
case 4. and 5. Page is scrolled to a paragraph without "&" or "," in view (3.5 Fragment). Their first occurrences are not highlighted.

Regression range

  • Not a regression.

Additional notes

  • Chrome doesn't scroll the page for 1 & 2 (as their first occurrence is in the first paragraph).
  • Case 3. works properly in Chrome.
  • Same behavior for cases 4. & 5. in Chrome.

Thank you for the report!

Case 1 and 2 are at the very top of the page, so there shouldn't be any scrolling involved. On my machine with today's Nightly (MacOS) there is no scrolling.

Case 3 is an interesting one. Technically, the URL is invalid if there are two pound signs. However, this should be recoverable and should work.

Case 4 should not work. The ampersand is the delimiter between text directives (:~:text=foo&text=bar). This case also does not work in Chrome.

Looked deeper into this. First of all: The links contain both a fragment and a text fragment. In case the text fragment finds a match, it takes precedence over the fragment navigation. That is why cases 4 and 5 still scroll to page 24, but don't highlight a & or ,, and also why cases 1 and 2 stay at the top of the document.

Case 1 and 2 do actually scroll slightly. That's unexpected and should be investigated. I'm using this bug for tracking this.
Scrolling to # should work. I have a patch for that in Bug 1910417.
As said before, cases 4 and 5 behave as expected.

Summary: Text Fragment scrolling fails → Text Fragment scrolling fails if the text fragment consists of special characters
You need to log in before you can comment on or make changes to this bug.