feat: include source location in list_console_messages

[masamaru0513]

Summary

Include source-mapped location in list_console_messages with shortened display and grouping support.

Fixes #903

Changes since review feedback

Addressed @OrKoN's feedback:

1. Source-mapped locations — Resolves source-mapped locations (via uiSourceCode.uiLocation()) instead of raw CDP locations
2. Shortened display — Extracts the filename from URLs to reduce token consumption (e.g., app.js:42:15 instead of https://example.com/static/js/app.js:42:15). Handles puppeteer-style wrappers and percent-encoded URLs in a single non-recursive pass.
3. Grouping uses location — Messages with same text, type, argCount, AND location are grouped as [N times]
4. Timeout guard — Bounds stack-trace resolution with a timeout so dialog-blocked pages do not stall the tool call

Output example

msgid=1 [error] Something went wrong (1 args) app.js:42:15
msgid=2 [error] repeated error (1 args) utils.js:10:3 [5 times]

Design

• list_console_messages: Shows shortened source-mapped location (filename:line:col)
• get_console_message: Shows full detail with Location: line + ### Stack trace section
• structuredContent: Includes location object with url, displayName, lineNumber, columnNumber
• Grouping key: type + text + argCount + location — identical messages from the same source are collapsed

Compatibility

No breaking changes to existing tool outputs or public APIs. The new location field is additive in structuredContent.

Why the timeout wrapper is part of this PR

This PR resolves the stack trace eagerly on every list_console_messages call (not just when fetchDetailedData=true) to derive the source-mapped location. As a side effect, pages paused on a dialog can hang the underlying CDP calls.

The timeout wrapper bounds that work so the tool call always returns. The existing when dialog is open test (#1977) covers this scenario; without the wrapper it times out at 120s.

So the wrapper is not a separate concern — it's required by the eager stack resolution that makes the location feature work.

Test plan

• Inline script location shows script.js:1:18 (not full pptr URL)
• External script location shows shortened filename
• 5 identical messages grouped as [5 times]
• UncaughtError includes shortened location
• get_console_message shows ID, Location, Stack trace
• Dialog-blocked page returns response within timeout
• All existing console/formatter tests pass

[OrKoN]

per #903 we do want to have source maps locations. Additionally, we had non-source mapped location previously and received complains that with many console messages it consumes to many tokens as the URLs can be long and repeating. So we need to be smart about how we display it and take the grouping of console messages into account. In general, agents can make multiple tool calls at once so over the long term calling get_console_message multiple times should be less of a problem. With that, let's make sure use source location for grouping and that we show source mapped location.

[masamaru0513]

Thanks for the feedback. To make sure I go in the right direction:

1. Timing of source map resolution: Should location be resolved lazily when list_console_messages is called, or eagerly in the background as messages are collected?
2. Token efficiency: For the text output, should I shorten/omit the URL (e.g., show only filename + line:col), or keep location only in structuredContent (JSON) to avoid bloating the text response?

---

Based on your review, I'll go ahead and:

1. Resolve source-mapped locations (using the top non-ignored stack frame, similar to the approach in feat(list_console_messages): include source-mapped location of messages #960)
2. Use source location for grouping and show only filename:line:col in the text output to keep token usage low

Will push an update.

[masamaru0513]

@OrKoN one self-review note before you look — I added a few things that may be out of scope for this PR:

1. A short withResolveTimeout wrapper around stack resolution to guard against pages paused on a dialog. Happy to split this into a separate PR if you prefer.
2. Splitting includeStackAndCause into includeStack / includeCause so the formatter can fetch the stack without paying for cause lookup. Also fine to keep the combined flag and resolve both, if you'd rather not change the API here.
3. Also unsure whether shortUrl() is worth carrying — uiSourceCode.displayName() covers the common case; the regex parsing is mainly to extract the inner file from pptr:evaluate;... URLs. Open to dropping it.

Let me know which of these you want trimmed and I'll push a focused update.

[masamaru0513]

@OrKoN Addressed your feedback. Reverted the includeStackAndCause API change and simplified shortUrl() to ~15 lines (no more recursive unwrapping or URL parsing). The timeout wrapper stays as it's needed to prevent hangs when the page is paused on a dialog. Ready for review.

Would appreciate another look when you get a chance.

[masamaru0513]

@OrKoN Could you approve the workflows so CI can run? Happy to address anything that comes up.

[masamaru0513]

Hi @OrKoN, sorry to bother you again. The CI failure on the previous run was in an unrelated test (work for elements inside iframes in script.test.js — a navigation timeout on Windows/Node 26), not related to my changes. Could you re-run the workflow when you get a chance? Thank you!

[OrKoN]

@masamaru0513 please do not rebase the PR for now, as it will reset the test results.

[OrKoN]

@szuend @Lightning00Blade could you please review and see if it makes sense to land this?

[masamaru0513]

@Lightning00Blade Gentle ping — OrKoN requested your review here on May 29. Would you have a chance to take a look when you get a moment? Happy to address any feedback. Thanks!

[szuend]

This PR is on my ToDo list for review. Unfortunately it's very large, with non-trivial changes. This will take some time to properly review.

[masamaru0513]

Thanks for the heads up — happy to wait!