Fix relative-time error and improve global error handler

[silverwind]

1. Fixes: relative-time error invalid language tag: "undefined" in playwright #37239
2. Enhance global error message to show stack trace on click

---

This PR was written with the help of Claude Opus 4.7

[Copilot]

Pull request overview

Fixes a Playwright/headless-only relative-time locale parsing crash and enhances the frontend global error handler to better capture/copy debugging details, plus adds an e2e smoke test to catch homepage JS errors.

Changes:

• Make relative-time locale resolution resilient to invalid navigator.language values and add a regression unit test.
• Replace showGlobalErrorMessage with showGlobalError(Error, opts) and extend the global error UI with a copy-to-clipboard button that includes stack traces.
• Add a Playwright test intended to ensure the homepage renders without JS errors.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
web_src/js/webcomponents/relative-time.ts	Safer language fallback when locale candidates are invalid.
web_src/js/webcomponents/relative-time.test.ts	Adds regression test for invalid navigator.language.
web_src/js/modules/errors.ts	New showGlobalError API + copy-with-stack UI + updated error event processing.
web_src/js/modules/errors.test.ts	Updates/extends unit tests for new error handler behavior.
web_src/js/features/common-page.ts	Migrates warning banners to the new showGlobalError API.
web_src/js/bootstrap.ts	Uses showGlobalError for early bootstrap failures.
tests/e2e/homepage.test.ts	Adds homepage smoke test asserting no global error UI is rendered.
templates/base/head_script.tmpl	Adds i18n.copy string to window.config for the new copy button label.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wxiaoguang]

No, the error message prompt is just for development purpose.

It should not be that complex. The more complex it becomes, the more potential bugs it will have. What if the code causes new errors again?

Do not make things unnecessarily complex.

If you need to read more about the error details, just open the browser's console, just like all the frontend developers do.

[silverwind]

Stack trace must be accessible somehow because it's vital information and a small copy button achieves that in the least obtrusive way besides rendering it directly.

"Open the console" is bad, some browsers might not even have a console, think about tablets or phones. Don't assume every user is on a desktop.

[wxiaoguang]

Stack trace must be accessible somehow because it's vital information and a small copy button achieves that in the least obtrusive way besides rendering it directly.

Do you remember that you had objection when I introduced such "js error message prompt"? But now why you keep making it unnecessarily complex. Developers should open their console, look into the real source code with source map.

In production build, your stack trace here is just garbled text

---

"Open the console" is bad, some browsers might not even have a console, think about tablets or phones. Don't assume every user is on a desktop.

It is just your guess and imagination that "it needs to show stack for a user who uses a phone".

[silverwind]

It's more about that I always have to ask users to copy the error from the console than to screenshot/copy only the message because "Foo is undefined" is not debuggable without the stack trace. If you don't like the copy button, we could make it visible on-hover.

[wxiaoguang]

It's more about that I always have to ask users to copy the error from the console

How many times? Where are the related issues?

If you don't like the copy button, we could make it visible on-hover.

I don't accept any more useless change.

[silverwind]

How many times? Where are the related issues?

At least 4-5 times, some on GitHub, some on Discord.

I don't accept any more useless change.

It is genuinely needed for debugging.

[silverwind]

Concrete example:

User posts only a screenshot of the error without any console output. Errors was deducable from the message via AI, but in case of e is undefined, this won't be possible.

[silverwind]

If copy button is not to your liking, we can use a <details>+<summary> that expands with the stack track on click and maybe add a "Click for details" in place of "Open browser console". Least obtrusive change possible.

[wxiaoguang]

Concrete example:

User posts only a screenshot of the error without any console output. Errors was deducable from the message via AI, but in case of e is undefined, this won't be possible.

1. They are contributors, they should know how to correctly report a bug without the "copy" button or duplicate "stack" message.
2. Most end users should never see the JS error, most JS errors should already have been handled by maintainers during the development.
3. Even if you have a "copy" button, almost all users still only show you a screenshot (just like your screenshot shows), you still need to tell them "please provide the stacktrace", the same as "open the console and show the stacktrace"

[wxiaoguang]

If copy button is not to your liking, we can use a <details>+<summary> that expands with the stack track on click and maybe add a "Click for details" in place of "Open browser console". Least obtrusive change possible.

Can do with a general function like

export function showGlobalErrorMessage(msg: string, msgType: Intent = 'error', details?: string) {
...
}

[silverwind]

I will do the details+summary approach like that.

[wxiaoguang]

My only question: Why is single message still centered? Looks inconistent.

Just because "it looks better" for "single line" (as you suggested).

For > 99% cases, the left-alignment and center-alignment won't appear on the same page at the same time, there won't be "inconsistent"

Also, for > 99% cases, you will still only see single line message. The multiple line message is only for some serious errors, very rare cases.