qns: fix reported JavaScript content defects

Resolve vetted production feedback across the JavaScript question set by replacing unsafe or stale resources, correcting runtime and storage explanations, and fixing localized terminology and examples. Regenerate the README so its embedded answers remain consistent with the question sources.

Author: yangshun

README.md

@@ -387,7 +387,7 @@ The event loop is a concept within the JavaScript runtime environment regarding
 3. Once the asynchronous operation completes, its callback function is placed in the respective queues – task queues (also known as macrotask queues / callback queues) or microtask queues. We will refer to "task queue" as "macrotask queue" from here on to better differentiate from the microtask queue.
 4. The event loop continuously monitors the call stack and executes items on the call stack. If/when the call stack is empty:
    1. Microtask queue is processed. Microtasks include promise callbacks (`then`, `catch`, `finally`), `await` continuations, `MutationObserver` callbacks, and calls to `queueMicrotask()`. The event loop takes the first callback from the microtask queue and pushes it to the call stack for execution. This repeats until the microtask queue is empty.
-   2. Macrotask queue is processed. Macrotasks include web APIs like `setTimeout()`, HTTP requests, user interface event handlers like clicks, scrolls, etc. The event loop dequeues the first callback from the macrotask queue and pushes it onto the call stack for execution. However, after a macrotask queue callback is processed, the event loop does not proceed with the next macrotask yet! The event loop first checks the microtask queue. Checking the microtask queue is necessary as microtasks have higher priority than macrotask queue callbacks. The macrotask queue callback that was just executed could have added more microtasks!
+   2. Macrotask queue is processed. It contains tasks scheduled by the host, such as timer callbacks and user interface event callbacks. APIs such as `setTimeout()` and networking APIs are not themselves macrotasks; they arrange for callbacks or promise reactions to be queued when appropriate. The event loop dequeues the first callback from the macrotask queue and pushes it onto the call stack for execution. However, after a macrotask queue callback is processed, the event loop does not proceed with the next macrotask yet! The event loop first checks the microtask queue. Checking the microtask queue is necessary as microtasks have higher priority than macrotask queue callbacks. The macrotask queue callback that was just executed could have added more microtasks!
       1. If the microtask queue is non-empty, process them as per the previous step.
       2. If the microtask queue is empty, the next macrotask queue callback is processed. This repeats until the macrotask queue is empty.
 5. This process continues indefinitely, allowing the JavaScript engine to handle both synchronous and asynchronous operations efficiently without blocking the call stack.
@@ -475,7 +475,7 @@ Here's a table summarizing the 3 client storage mechanisms.
 | Lifespan | As specified | Until deleted | Until tab is closed |
 | Persistent across browser sessions | If a future expiry date is set | Yes | No |
 | Sent to server with every HTTP request | Yes, sent via `Cookie` header | No | No |
-| Total capacity (per domain) | 4KB | 5MB | 5MB |
+| Typical storage limit | About 4 KB per cookie | About 5 MB per origin (browser-dependent) | About 5 MB per origin (browser-dependent) |
 | Access | Across windows/tabs | Across windows/tabs | Same tab |
 | Security | JavaScript cannot access `HttpOnly` cookies | None | None |
 
@@ -1331,7 +1331,7 @@ Common use cases include:
 - **New JavaScript Methods**: For example, `Array.prototype.includes()`, `Object.assign()`, etc.
 - **New APIs**: Such as `fetch()`, `Promise`, `IntersectionObserver`, etc. Modern browsers support these now, but for a long time they had to be polyfilled.
 
-Libraries and services for polyfills:
+A commonly used polyfill library is:
 
 - **`core-js`**: A modular standard library for JavaScript which includes polyfills for a wide range of ECMAScript features.
 
@@ -1341,11 +1341,7 @@ Libraries and services for polyfills:
   [1, 2].flatMap((it) => [it, it]); // => [1, 1, 2, 2]
   ```
 
-- **Polyfill.io**: A service that provides polyfills based on the features and user agents specified in the request.
-
-  ```js
-  <script src="https://polyfill.io/v3/polyfill.min.js"></script>
-  ```
+Prefer installing maintained polyfills as project dependencies and bundling them with your application instead of loading executable code from a third-party polyfill service at runtime.
 
 <!-- Update here: /questions/what-are-javascript-polyfills-for/en-US.mdx -->
 
@@ -3753,7 +3749,7 @@ The event loop is a concept within the JavaScript runtime environment regarding
 3. Once the asynchronous operation completes, its callback function is placed in the respective queues – task queues (also known as macrotask queues / callback queues) or microtask queues. We will refer to "task queue" as "macrotask queue" from here on to better differentiate from the microtask queue.
 4. The event loop continuously monitors the call stack and executes items on the call stack. If/when the call stack is empty:
    1. Microtask queue is processed. Microtasks include promise callbacks (`then`, `catch`, `finally`), `await` continuations, `MutationObserver` callbacks, and calls to `queueMicrotask()`. The event loop takes the first callback from the microtask queue and pushes it to the call stack for execution. This repeats until the microtask queue is empty.
-   2. Macrotask queue is processed. Macrotasks include web APIs like `setTimeout()`, HTTP requests, user interface event handlers like clicks, scrolls, etc. The event loop dequeues the first callback from the macrotask queue and pushes it onto the call stack for execution. However, after a macrotask queue callback is processed, the event loop does not proceed with the next macrotask yet! The event loop first checks the microtask queue. Checking the microtask queue is necessary as microtasks have higher priority than macrotask queue callbacks. The macrotask queue callback that was just executed could have added more microtasks!
+   2. Macrotask queue is processed. It contains tasks scheduled by the host, such as timer callbacks and user interface event callbacks. APIs such as `setTimeout()` and networking APIs are not themselves macrotasks; they arrange for callbacks or promise reactions to be queued when appropriate. The event loop dequeues the first callback from the macrotask queue and pushes it onto the call stack for execution. However, after a macrotask queue callback is processed, the event loop does not proceed with the next macrotask yet! The event loop first checks the microtask queue. Checking the microtask queue is necessary as microtasks have higher priority than macrotask queue callbacks. The macrotask queue callback that was just executed could have added more microtasks!
       1. If the microtask queue is non-empty, process them as per the previous step.
       2. If the microtask queue is empty, the next macrotask queue callback is processed. This repeats until the macrotask queue is empty.
 5. This process continues indefinitely, allowing the JavaScript engine to handle both synchronous and asynchronous operations efficiently without blocking the call stack.
@@ -5032,7 +5028,7 @@ Here's a table summarizing the 3 client storage mechanisms.
 | Lifespan | As specified | Until deleted | Until tab is closed |
 | Persistent across browser sessions | If a future expiry date is set | Yes | No |
 | Sent to server with every HTTP request | Yes, sent via `Cookie` header | No | No |
-| Total capacity (per domain) | 4KB | 5MB | 5MB |
+| Typical storage limit | About 4 KB per cookie | About 5 MB per origin (browser-dependent) | About 5 MB per origin (browser-dependent) |
 | Access | Across windows/tabs | Across windows/tabs | Same tab |
 | Security | JavaScript cannot access `HttpOnly` cookies | None | None |
 
@@ -5326,7 +5322,7 @@ Common use cases include:
 - **New JavaScript Methods**: For example, `Array.prototype.includes()`, `Object.assign()`, etc.
 - **New APIs**: Such as `fetch()`, `Promise`, `IntersectionObserver`, etc. Modern browsers support these now, but for a long time they had to be polyfilled.
 
-Libraries and services for polyfills:
+A commonly used polyfill library is:
 
 - **`core-js`**: A modular standard library for JavaScript which includes polyfills for a wide range of ECMAScript features.
 
@@ -5336,11 +5332,7 @@ Libraries and services for polyfills:
   [1, 2].flatMap((it) => [it, it]); // => [1, 1, 2, 2]
   ```
 
-- **Polyfill.io**: A service that provides polyfills based on the features and user agents specified in the request.
-
-  ```js
-  <script src="https://polyfill.io/v3/polyfill.min.js"></script>
-  ```
+Prefer installing maintained polyfills as project dependencies and bundling them with your application instead of loading executable code from a third-party polyfill service at runtime.
 
 <!-- Update here: /questions/what-are-javascript-polyfills-for/en-US.mdx -->
 

questions/can-you-offer-a-use-case-for-the-new-arrow-function-syntax-how-does-this-new-syntax-differ-from-other-functions/en-US.mdx

@@ -48,11 +48,12 @@ function Timer() {
 }
 
 const timer = new Timer();
-timer.increment(); // 1
-timer.increment(); // 2
+const increment = timer.increment;
+increment(); // 1
+increment(); // 2
 ```
 
-In the example above, using a traditional function for `increment` would lose the correct `this` context when called, requiring additional steps like `bind` to fix it.
+In the example above, `increment` is called without `timer` as its receiver, but the arrow function still uses the `this` value captured by the `Timer` constructor. A traditional function would lose that context when detached this way unless it was explicitly bound.
 
 ### Using arrow functions in array methods
 

questions/can-you-offer-a-use-case-for-the-new-arrow-function-syntax-how-does-this-new-syntax-differ-from-other-functions/zh-CN.mdx

@@ -48,11 +48,12 @@ function Timer() {
 }
 
 const timer = new Timer();
-timer.increment(); // 1
-timer.increment(); // 2
+const increment = timer.increment;
+increment(); // 1
+increment(); // 2
 ```
 
-在上面的例子中，在 `setInterval` 中使用传统函数需要额外的步骤来维护正确的 `this` 上下文。
+在上面的例子中，调用 `increment` 时没有将 `timer` 作为接收者，但箭头函数仍然使用 `Timer` 构造函数捕获的 `this`。如果使用传统函数，以这种方式脱离对象调用时会丢失该上下文，除非显式绑定它。
 
 ### 在数组方法中使用箭头函数
 

questions/describe-the-difference-between-a-cookie-sessionstorage-and-localstorage/en-US.mdx

@@ -18,7 +18,7 @@ Here's a table summarizing the 3 client storage mechanisms.
 | Lifespan | As specified | Until deleted | Until tab is closed |
 | Persistent across browser sessions | If a future expiry date is set | Yes | No |
 | Sent to server with every HTTP request | Yes, sent via `Cookie` header | No | No |
-| Total capacity (per domain) | 4KB | 5MB | 5MB |
+| Typical storage limit | About 4 KB per cookie | About 5 MB per origin (browser-dependent) | About 5 MB per origin (browser-dependent) |
 | Access | Across windows/tabs | Across windows/tabs | Same tab |
 | Security | JavaScript cannot access `HttpOnly` cookies | None | None |
 
@@ -50,7 +50,7 @@ The following sections dive deeper into each client storage mechanism.
 
 Cookies are used to store small pieces of data on the client side that can be sent back to the server with every HTTP request.
 
-- **Storage capacity**: Limited to around 4KB for all cookies.
+- **Storage capacity**: Limited to around 4 KB per cookie. Browsers also limit how many cookies can be stored per domain.
 - **Lifespan**: Cookies can have a specific expiration date set using the `Expires` or `Max-Age` attributes. If no expiration date is set, the cookie is deleted when the browser is closed (session cookie).
 - **Access**: Cookies are domain-specific and can be shared across different pages and subdomains within the same domain.
 - **Security**: Cookies can be marked as `HttpOnly` to prevent access from JavaScript, reducing the risk of XSS attacks. They can also be secured with the `Secure` flag to ensure they are sent only when HTTPS is used.

questions/describe-the-difference-between-a-cookie-sessionstorage-and-localstorage/pt-BR.mdx

@@ -24,7 +24,7 @@ Cookies, `localStorage`, and `sessionStorage`, são todos:
 | Vencimento | Definir manualmente | Para sempre | Ao fechar a aba |
 | Persistente através de sessões do navegador | Depende se a expiração está definida | Sim | Não |
 | Enviado para o servidor com cada solicitação HTTP | Os cookies são automaticamente enviados via cabeçalho `Cookie` | Não | Não |
-| Capacidade (por domínio) | 4kb | 5MB | 5MB |
+| Limite típico de armazenamento | Cerca de 4 KB por cookie | Cerca de 5 MB por origem (varia conforme o navegador) | Cerca de 5 MB por origem (varia conforme o navegador) |
 | Acesso | Quqlquer Janela | Quqlquer Janela | Mesma Guia |
 
 Também existem outros mecanismos de armazenamento do lado do cliente, como [IndexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API) que é mais poderoso do que as tecnologias acima mencionadas, mas mais complicado de usar.

questions/describe-the-difference-between-a-cookie-sessionstorage-and-localstorage/zh-CN.mdx

@@ -18,7 +18,7 @@ title: 描述浏览器中 cookie、`sessionStorage` 和 `localStorage` 之间的
 | 寿命 | 如指定 | 直到删除 | 直到选项卡关闭 |
 | 是否跨浏览器会话持久 | 如果设置了未来的过期日期 | 是 | 否 |
 | 是否随每个 HTTP 请求发送到服务器 | 是，通过 `Cookie` 标头发送 | 否 | 否 |
-| 总容量（每个域） | 4kb | 5MB | 5MB |
+| 典型存储限制 | 每个 cookie 约 4 KB | 每个来源约 5 MB（因浏览器而异） | 每个来源约 5 MB（因浏览器而异） |
 | 访问 | 跨窗口/选项卡 | 跨窗口/选项卡 | 相同选项卡 |
 | 安全性 | JavaScript 无法访问 `HttpOnly` cookies | 无 | 无 |
 
@@ -50,7 +50,7 @@ Cookies、`localStorage` 和 `sessionStorage` 都是客户端（Web 浏览器）
 
 Cookies 用于在客户端存储小块数据，这些数据可以通过每个 HTTP 请求发送回服务器。
 
-- **存储容量**：所有 cookies 限制在 4KB 左右。
+- **存储容量**：每个 cookie 限制在 4 KB 左右。浏览器还会限制每个域可存储的 cookie 数量。
 - **寿命**：Cookies 可以使用 `Expires` 或 `Max-Age` 属性设置特定的过期日期。如果未设置过期日期，则在浏览器关闭时删除 cookie（会话 cookie）。
 - **访问**：Cookies 是特定于域的，可以在同一域内的不同页面和子域之间共享。
 - **安全性**：Cookies 可以标记为 `HttpOnly` 以防止从 JavaScript 访问，从而降低 XSS 攻击的风险。它们也可以使用 `Secure` 标志进行保护，以确保仅在使用 HTTPS 时发送它们。

questions/explain-the-concept-of-code-coverage-and-how-it-can-be-used-to-assess-test-quality/zh-CN.mdx

@@ -82,5 +82,5 @@ jest --coverage
 ## 延伸阅读
 
 - [Istanbul documentation](https://istanbul.js.org/)
-- [Jest code coverage](https://jestjs.io/docs/en/coverage)
+- [Jest code coverage](https://jestjs.io/docs/cli#--coverageboolean)
 - [Karma coverage](https://karma-runner.github.io/6.3/intro/installation.html)

questions/explain-the-concept-of-error-propagation-in-javascript/zh-CN.mdx

@@ -102,4 +102,4 @@ async function b() {
 
 - [MDN Web Docs: Error handling](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Control_flow_and_error_handling#exception_handling_statements)
 - [JavaScript.info: Error handling, "try...catch"](https://javascript.info/try-catch)
-- [Node.js Error Handling Best Practices](https://nodejs.dev/learn/error-handling-in-nodejs)
+- [Node.js Documentation: Errors](https://nodejs.org/api/errors.html)

questions/how-can-you-implement-secure-authentication-and-authorization-in-javascript-applications/en-US.mdx

@@ -114,5 +114,5 @@ app.get('/admin', checkRole('admin'), (req, res) => {
 
 - [JWT.io](https://jwt.io/)
 - [Passport.js documentation](https://www.passportjs.org/docs/)
-- [OWASP Secure Coding Practices-Quick Reference Guide](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/)
+- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
 - [MDN Web Docs on HTTP Strict Transport Security (HSTS)](https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security)

questions/how-can-you-implement-secure-authentication-and-authorization-in-javascript-applications/zh-CN.mdx

@@ -113,6 +113,6 @@ app.get('/admin', checkRole('admin'), (req, res) => {
 ## 延伸阅读
 
 - [JWT.io](https://jwt.io/)
-- [Passport.js documentation](http://www.passportjs.org/docs/)
-- [OWASP Secure Coding Practices-Quick Reference Guide](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/)
-- [MDN Web Docs on HTTPS](https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security)
+- [Passport.js documentation](https://www.passportjs.org/docs/)
+- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
+- [MDN Web Docs on HTTP Strict Transport Security (HSTS)](https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security)