morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #1586] [Bug] dom_urls skips SVG links written only as xlink:href #534

New issue

Closed

opened 2026-10-15 18:25:57 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:25:57 +00:00

Owner

Originally created by @CassieFox23 on GitHub (Oct 10, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1586

TL;DR: inspect-web-page lists no URL for an SVG link written as xlink:href alone. Chromium follows that link, since it still reads xlink:href when href is missing. SVG written for older tools often uses only xlink:href, so those links are missing from dom_urls.

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Process capture or runtime observation

Observed behavior

On f6009d007, inspect-web-page gives no dom_urls entry for an SVG a, image or use that has only xlink:href. The node is in dom.nodes, with attribute_names of ["id", "xlink:href"]. The same element with plain href gets an entry.

Chromium 154 reads the link. For the a below, a.href.baseVal is /xl-s2h and a.matches(":any-link") is true. For image and use, href.baseVal holds their xlink:href value.

Reproduction

Save this as x.html and serve it from 127.0.0.1:

<!doctype html><title>x</title>
<svg width="10" height="10">
  <a id="s2" xlink:href="/xl-s2h"><text>s2</text></a>
</svg>

Start headless Chromium with --remote-debugging-port=9222, and open the page.
Run rea inspect-web-page http://127.0.0.1:9222 <target> --format json.
Look at normalized_result.metadata.dom_urls. It has no entry for the a.

Expected behavior

dom_urls lists the a with attribute href and the URL /xl-s2h, the same as it does for <a href="/xl-s2h">. When both href and xlink:href are present, Chromium uses href, and REA already does.

Impact and scope

Links in SVG written the old way do not show up in dom_urls. Elements with plain href are fine. I did not check how the URL list is used downstream.

This is separate from #1496 and #1516, which are about repeated names and are now merged. Their pairs, such as HREF then href, all match Chromium on f6009d007.

REA also lists href on elements Chromium does not treat as links, such as MathML mi and div. That may be on purpose, so it is not part of this issue.

REA version

Source revision f6009d007

Runtime and platform

Node 24.18.0, on Nobara 44 (Linux 7.2.9). Chromium 154, run headless.

Target and artifact context

Local test page in headless Chromium

Interface

CLI

Earliest failure stage

Capture or observation

Analysis or suspected cause

Source-derived, not tested. domMetadata in src/browser/CdpCaptureDocuments.ts looks up the exact names href, src, action, formaction and poster. It has no case for xlink:href. A fix might read xlink:href on SVG elements when href is missing. I have not tried that change.

Not run

Any change to the code.
Other browsers.

Test setup

Box: Nobara 44 (Fedora 44 base), Linux 7.2.9
CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
Node: 24.18.0
Main: cca7bf002, with f6009d007 as the merge under test
Other: Chromium 154 (BSD-3-Clause), the one Fedora 44 ships
Build: 154.0.8037.57

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

Originally created by @CassieFox23 on GitHub (Oct 10, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1586 **TL;DR:** `inspect-web-page` lists no URL for an SVG link written as `xlink:href` alone. Chromium follows that link, since it still reads `xlink:href` when `href` is missing. SVG written for older tools often uses only `xlink:href`, so those links are missing from `dom_urls`. ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Process capture or runtime observation ### Observed behavior On `f6009d007`, `inspect-web-page` gives no `dom_urls` entry for an SVG `a`, `image` or `use` that has only `xlink:href`. The node is in `dom.nodes`, with `attribute_names` of `["id", "xlink:href"]`. The same element with plain `href` gets an entry. Chromium 154 reads the link. For the `a` below, `a.href.baseVal` is `/xl-s2h` and `a.matches(":any-link")` is true. For `image` and `use`, `href.baseVal` holds their `xlink:href` value. ### Reproduction 1. Save this as `x.html` and serve it from `127.0.0.1`: ```html <!doctype html><title>x</title> <svg width="10" height="10"> <a id="s2" xlink:href="/xl-s2h"><text>s2</text></a> </svg> ``` 2. Start headless Chromium with `--remote-debugging-port=9222`, and open the page. 3. Run `rea inspect-web-page http://127.0.0.1:9222 <target> --format json`. 4. Look at `normalized_result.metadata.dom_urls`. It has no entry for the `a`. ### Expected behavior `dom_urls` lists the `a` with attribute `href` and the URL `/xl-s2h`, the same as it does for `<a href="/xl-s2h">`. When both `href` and `xlink:href` are present, Chromium uses `href`, and REA already does. ### Impact and scope Links in SVG written the old way do not show up in `dom_urls`. Elements with plain `href` are fine. I did not check how the URL list is used downstream. This is separate from #1496 and #1516, which are about repeated names and are now merged. Their pairs, such as `HREF` then `href`, all match Chromium on `f6009d007`. REA also lists `href` on elements Chromium does not treat as links, such as MathML `mi` and `div`. That may be on purpose, so it is not part of this issue. ### REA version Source revision `f6009d007` ### Runtime and platform Node 24.18.0, on Nobara 44 (Linux 7.2.9). Chromium 154, run headless. ### Target and artifact context Local test page in headless Chromium ### Interface CLI ### Earliest failure stage Capture or observation ### Analysis or suspected cause Source-derived, not tested. `domMetadata` in `src/browser/CdpCaptureDocuments.ts` looks up the exact names `href`, `src`, `action`, `formaction` and `poster`. It has no case for `xlink:href`. A fix might read `xlink:href` on SVG elements when `href` is missing. I have not tried that change. ### Not run - Any change to the code. - Other browsers. <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.9 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads - Node: 24.18.0 - Main: `cca7bf002`, with `f6009d007` as the merge under test - Other: [Chromium 154](https://github.com/chromium/chromium) ([BSD-3-Clause](https://github.com/chromium/chromium/blob/main/LICENSE)), the one Fedora 44 ships - Build: `154.0.8037.57` </details> 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

bsakaguchi

2026-10-15 18:25:57 +00:00

closed this issue
added the
area: runtime

bug
labels

bsakaguchi commented

2026-10-15 18:25:58 +00:00

Author

Owner

@sathariels commented on GitHub (Oct 10, 2026):

Hey @CassieFox23, thanks for the clear repro. I'd like to take this one. I checked it in headless Chrome: for an SVG <a> with only xlink:href, href.baseVal holds the value and the element matches :any-link, but for an HTML <a xlink:href> it doesn't. So my plan is to use xlink:href in domMetadata only when href is missing and the element is SVG, and report it as href so the dom_urls schema stays the same. Plain href still wins when both are there. Tests would cover xlink-only, both attributes, the HTML case that shouldn't be listed, and the origin policy, plus a real Chrome check of your page. I'd leave the MathML/div href question out of this one.

@sathariels commented on GitHub (Oct 10, 2026): Hey @CassieFox23, thanks for the clear repro. I'd like to take this one. I checked it in headless Chrome: for an SVG `<a>` with only `xlink:href`, `href.baseVal` holds the value and the element matches `:any-link`, but for an HTML `<a xlink:href>` it doesn't. So my plan is to use `xlink:href` in `domMetadata` only when `href` is missing and the element is SVG, and report it as `href` so the dom_urls schema stays the same. Plain `href` still wins when both are there. Tests would cover xlink-only, both attributes, the HTML case that shouldn't be listed, and the origin policy, plus a real Chrome check of your page. I'd leave the MathML/`div` `href` question out of this one.

bsakaguchi commented

2026-10-15 18:25:58 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 10, 2026):

Thanks, sathariels, for fixing this in #1602. Checking the HTML and SVG cases in headless Chrome first was a nice touch.

🤖 Generated with Claude Code (Opus 5.5) 🦊

@CassieFox23 commented on GitHub (Oct 10, 2026): Thanks, sathariels, for fixing this in #1602. Checking the HTML and SVG cases in headless Chrome first was a nice touch. 🤖 Generated with Claude Code (Opus 5.5) 🦊

bsakaguchi referenced this issue

2026-10-15 18:28:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:13:48 +00:00

[PR #534] [MERGED] fix(native): match compound otool keys exactly and badge unknown thread entrypoints #2056