Autowebcompat agents are struggling to submit results sometimes because they're trying to place the required parameter inside another parameter as xml, something like <parameter name=\"evidence\">onReset.toString() plus its string table ...</parameter>
--- turn 55 ---
[agent→tool] mcp__autowebcompat-diagnosis__submit_result
{
"root_cause": "CORRECTION - this supersedes my previous placeholder submission (\"test\").\n\nThe Reset button never clears the textarea itself; it reloads the page and relies on the browser re-creating the textarea from its empty markup value. The form carries onreset=\"return onReset()\" and the button is id=\"resetBtn\" type=\"reset\". The page's obfuscated inline script defines (de-obfuscated): function onReset() { return confirm(\"\u5165\u529b\u3057\u305f\u6587\u7ae0\u3092\u524a\u9664\u3057\u307e\u3059\u304b\uff1f\u3053\u306e\u64cd\u4f5c\u3092\u884c\u3046\u3068\u5143\u306b\u623b\u305b\u307e\u305b\u3093\u3002\") && location.reload(), false; }\n\nSo accepting the confirm calls location.reload(), and the handler returns false, which cancels the native form reset. location.reload() is therefore the only mechanism that is supposed to empty the textarea (id \"str\").\n\nFirefox restores the dirty value of form controls when a document is reloaded: session-history \"persisted user state\" restoration is applied on reload, not only on history traversal. After location.reload() the textarea comes back still holding the typed text, and the realtime counter re-derives the same old numbers, so the Reset button appears to do nothing. Chrome does not restore form state on a reload; the textarea is re-created empty from markup, so the site's reset appears to work.\n\nThis is a browser engine implementation difference, not UA sniffing: the page runs the identical codepath in both browsers (same confirm, same location.reload(), no navigator checks in that path). The HTML spec only requires form-control state to be persisted/restored for history traversal, and defines reload as a navigation that reuses the same session history entry, so restoring-on-reload is UA-discretionary. Refs: https://html.spec.whatwg.org/multipage/browsing-the-web.html#persisted-user-state-restoration , https://html.spec.whatwg.org/multipage/browsing-the-web.html#reload , https://html.spec.whatwg.org/multipage/form-elements.html#the-textarea-element</parameter>\n<parameter name=\"evidence\">1. Site code: strcount.html contains the form with onreset=\"return onReset()\" and a button id=\"resetBtn\" type=\"reset\". onReset.toString() in Firefox returns the obfuscated body; resolving its string table (window._0x25ba) gives _0x25ba(0xac) === \"reload\" and the confirm message \"\u5165\u529b\u3057\u305f\u6587\u7ae0\u3092\u524a\u9664\u3057\u307e\u3059\u304b\uff1f\u3053\u306e\u64cd\u4f5c\u3092\u884c\u3046\u3068\u5143\u306b\u623b\u305b\u307e\u305b\u3093\u3002\". Net effect: confirm(msg) && location.reload(), then return false.\n\n2. Live site, Firefox Nightly: set the textarea value to \"Hello test text 123\", fired an input event, then called location.reload(). After reload: value = \"Hello test text 123\", count = \"19\" - the value survived the reload and the counter re-derived the old count. That is exactly the reported \"nothing happens\".\n\n3. Live site, Chrome stable: identical steps; after reload value = \"\" and count = \"0\".\n\n4. No console errors or failed network requests are involved; the confirm dialog fires and is accepted in both browsers (the repro script reports dialogAccepted=true in both). The divergence is purely what location.reload() does to the textarea's dirty value.\n\n5. Reduced testcase /app/diagnosis/testcase=r5vaai8w.html - a plain form with one textarea that has no markup value; the script sets a value, then calls location.reload() once (guarded by sessionStorage). Loaded via file:// in both browsers: Firefox gives document.title \"FAIL still-has-text\" and textarea value after reload = \"Hello reload state 123\"; Chrome gives document.title \"PASS cleared\" and textarea value after reload = \"\". Same divergence as the real site, with all site and ad script removed.</parameter>\n<parameter name=\"testcase_path\">/app/diagnosis/testcase=r5vaai8w.html</parameter>\n</invoke>\n"
}
[tool←ERROR]
Input validation error: 'evidence' is a required property
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 50, "estimated_tokens_delta": 50, "uuid": "ab449131-af65-47ba-9bde-e98105c54a99", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 200, "estimated_tokens_delta": 150, "uuid": "139f99f9-4c1b-4f37-a78b-35069a7d1aa0", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
--- turn 56 ---
[agent:thinking]
--- turn 57 ---
[agent→tool] mcp__autowebcompat-diagnosis__submit_result
{
"root_cause": "CORRECTION - supersedes my prior placeholder submission. The Reset button never clears the textarea itself; it reloads the page and relies on the browser re-creating the textarea from its empty markup value. The form carries onreset=\"return onReset()\" and the button is id=\"resetBtn\" type=\"reset\". The obfuscated inline script defines, de-obfuscated: function onReset() { return confirm(\"\u5165\u529b\u3057\u305f\u6587\u7ae0\u3092\u524a\u9664\u3057\u307e\u3059\u304b\uff1f\u3053\u306e\u64cd\u4f5c\u3092\u884c\u3046\u3068\u5143\u306b\u623b\u305b\u307e\u305b\u3093\u3002\") && location.reload(), false; }. So accepting the confirm calls location.reload(), and the handler returns false which cancels the native form reset; location.reload() is thus the only mechanism that is supposed to empty the textarea (id \"str\"). Firefox restores the dirty value of form controls when a document is reloaded - session-history \"persisted user state\" restoration is applied on reload, not only on history traversal. After location.reload() the textarea comes back still holding the typed text and the realtime counter re-derives the same old numbers, so the Reset button appears to do nothing. Chrome does not restore form state on reload; the textarea is re-created empty from markup, so the site's reset appears to work. This is a browser engine implementation difference, not UA sniffing: the page runs the identical codepath in both browsers (same confirm, same location.reload(), no navigator checks in that path). The HTML spec only requires form-control state to be persisted/restored for history traversal, and defines reload as a navigation that reuses the same session history entry, so restoring-on-reload is UA-discretionary. Refs: https://html.spec.whatwg.org/multipage/browsing-the-web.html#persisted-user-state-restoration , https://html.spec.whatwg.org/multipage/browsing-the-web.html#reload , https://html.spec.whatwg.org/multipage/form-elements.html#the-textarea-element</parameter>\n<parameter name=\"evidence\">(1) Site code: strcount.html contains the form with onreset=\"return onReset()\" and a button id=\"resetBtn\" type=\"reset\"; onReset.toString() in Firefox returns the obfuscated body, and resolving its string table (window._0x25ba) gives _0x25ba(0xac) === \"reload\" plus the confirm message \"\u5165\u529b\u3057\u305f\u6587\u7ae0\u3092\u524a\u9664\u3057\u307e\u3059\u304b\uff1f\u3053\u306e\u64cd\u4f5c\u3092\u884c\u3046\u3068\u5143\u306b\u623b\u305b\u307e\u305b\u3093\u3002\", i.e. confirm(msg) && location.reload(), then return false. (2) Live site in Firefox Nightly: set the textarea value to \"Hello test text 123\", fired an input event, then called location.reload(); after reload value = \"Hello test text 123\" and count = \"19\" - the value survived the reload and the counter re-derived the old count, exactly the reported \"nothing happens\". (3) Live site in Chrome stable: identical steps, after reload value = \"\" and count = \"0\". (4) No console errors or failed network requests are involved; the confirm dialog fires and is accepted in both browsers (the repro script reports dialogAccepted=true in both), so the divergence is purely what location.reload() does to the textarea's dirty value. (5) Reduced testcase /app/diagnosis/testcase=r5vaai8w.html is a plain form with one textarea that has no markup value; the script sets a value then calls location.reload() once, guarded by sessionStorage. Loaded via file:// in both browsers: Firefox gives document.title \"FAIL still-has-text\" with textarea value after reload = \"Hello reload state 123\"; Chrome gives document.title \"PASS cleared\" with textarea value after reload = \"\". Same divergence as the real site with all site and ad script removed.</parameter>\n<parameter name=\"testcase_path\">/app/diagnosis/testcase=r5vaai8w.html</parameter>\n</invoke>\n"
}
[tool←ERROR]
Input validation error: 'evidence' is a required property
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 50, "estimated_tokens_delta": 50, "uuid": "f0a4d4b3-2230-42e3-86a9-d4a40eebe1eb", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 125, "estimated_tokens_delta": 75, "uuid": "10510be5-ae5a-4bfb-9f4c-f6938e3d9fb7", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
--- turn 58 ---
[agent:thinking]
--- turn 59 ---
[agent→tool] mcp__autowebcompat-diagnosis__submit_result
{
"root_cause": "CORRECTION, supersedes my prior placeholder submission. The Reset button never clears the textarea itself: the form has onreset=\"return onReset()\" and onReset() is (de-obfuscated) `return confirm(\"\u5165\u529b\u3057\u305f\u6587\u7ae0\u3092\u524a\u9664\u3057\u307e\u3059\u304b\uff1f...\") && location.reload(), false`. It returns false, cancelling the native form reset, so location.reload() is the ONLY thing meant to empty the textarea. Firefox restores the dirty value of form controls across a reload (session-history persisted-user-state restoration applies on reload, not just history traversal), so the textarea comes back with the typed text and the counter re-derives the old numbers; the button looks dead. Chrome does not restore form state on reload, so the textarea is re-created empty from markup and the reset appears to work. Engine difference, not UA sniffing: identical codepath in both. Spec leaves it to the UA: state restoration is only required for history traversal, and reload reuses the same history entry. https://html.spec.whatwg.org/multipage/browsing-the-web.html#persisted-user-state-restoration https://html.spec.whatwg.org/multipage/browsing-the-web.html#reload https://html.spec.whatwg.org/multipage/form-elements.html#the-textarea-element</parameter>\n<parameter name=\"evidence\">onReset.toString() plus its string table (window._0x25ba(0xac) === \"reload\") show the handler is confirm(msg) && location.reload(), return false. Live site, Firefox Nightly: set textarea value \"Hello test text 123\", fire input, location.reload() -> after reload value = \"Hello test text 123\", count = \"19\" (value survived; counter re-derived old count). Same steps in Chrome stable -> value = \"\", count = \"0\". No console errors, no failed requests; the confirm fires and is accepted in both (repro script: dialogAccepted=true in both). Reduced testcase /app/diagnosis/testcase=r5vaai8w.html (bare form + empty-markup textarea; script sets value then reloads once via sessionStorage guard), loaded from file:// : Firefox title \"FAIL still-has-text\", value after reload \"Hello reload state 123\"; Chrome title \"PASS cleared\", value after reload \"\". Same divergence with all site/ad script removed.</parameter>\n<parameter name=\"testcase_path\">/app/diagnosis/testcase=r5vaai8w.html</parameter>\n</invoke>\n"
}
[tool←ERROR]
Input validation error: 'evidence' is a required property
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 50, "estimated_tokens_delta": 50, "uuid": "a6594303-05db-4254-8f86-4c95a1d2258e", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 100, "estimated_tokens_delta": 50, "uuid": "435fc9c7-da4d-4992-aacf-7aff6d81c70a", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 200, "estimated_tokens_delta": 100, "uuid": "b484db49-d7d8-4023-af9c-993a3b751751", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 350, "estimated_tokens_delta": 150, "uuid": "0e74ba58-aa3e-44b0-929b-529e46943012", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
--- turn 60 ---
[agent:thinking]
--- turn 61 ---
[agent→tool] mcp__autowebcompat-diagnosis__submit_result
{
"evidence": "onReset.toString() plus its string table (window._0x25ba(0xac) is \"reload\") show the handler is: confirm(msg) and then location.reload(), returning false. Live site in Firefox Nightly: set textarea value to \"Hello test text 123\", fire input, call location.reload(); after the reload the value is still \"Hello test text 123\" and count is \"19\" - the dirty value survived and the counter re-derived the old count. Same steps in Chrome stable give value \"\" and count \"0\". No console errors and no failed network requests; the confirm fires and is accepted in both browsers (repro script reports dialogAccepted true in both). Reduced testcase at /app/diagnosis/testcase=r5vaai8w.html is a bare form with one empty-markup textarea whose script sets a value then reloads once via a sessionStorage guard. Loaded from file:// in Firefox it reports title \"FAIL still-has-text\" with value \"Hello reload state 123\"; in Chrome it reports title \"PASS cleared\" with value \"\". Same divergence as the real site with all site and ad script removed.</parameter>\n<parameter name=\"root_cause\">CORRECTION, supersedes my earlier placeholder submission. The Reset button never clears the textarea itself. The form has onreset=\"return onReset()\" and onReset() is, de-obfuscated: return confirm(\"\u5165\u529b\u3057\u305f\u6587\u7ae0\u3092\u524a\u9664\u3057\u307e\u3059\u304b\uff1f\u3053\u306e\u64cd\u4f5c\u3092\u884c\u3046\u3068\u5143\u306b\u623b\u305b\u307e\u305b\u3093\u3002\") and-then location.reload(), false. Because it returns false the native form reset is cancelled, so location.reload() is the only mechanism intended to empty the textarea. Firefox restores the dirty value of form controls across a reload - session-history persisted-user-state restoration is applied on reload, not only on history traversal - so the textarea comes back holding the typed text and the realtime counter re-derives the old numbers, making the button look dead. Chrome does not restore form state on reload, so the textarea is re-created empty from markup and the reset appears to work. This is an engine implementation difference, not UA sniffing: both browsers run the identical codepath with no navigator checks. The HTML spec leaves it to the UA, since form-control state restoration is only required for history traversal and reload reuses the same session history entry. See https://html.spec.whatwg.org/multipage/browsing-the-web.html#persisted-user-state-restoration and https://html.spec.whatwg.org/multipage/browsing-the-web.html#reload and https://html.spec.whatwg.org/multipage/form-elements.html#the-textarea-element</parameter>\n<parameter name=\"testcase_path\">/app/diagnosis/testcase=r5vaai8w.html</parameter>\n</invoke>\n"
}
[tool←ERROR]
Input validation error: 'root_cause' is a required property
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 50, "estimated_tokens_delta": 50, "uuid": "5af64dfb-697b-4298-a2eb-7b9c5a6b670b", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 150, "estimated_tokens_delta": 100, "uuid": "2728f950-fda1-4f33-9231-24099b0f6770", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 250, "estimated_tokens_delta": 100, "uuid": "8fefce34-07ca-4aa7-b3c7-694132714713", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
[system:thinking_tokens] {"type": "system", "subtype": "thinking_tokens", "estimated_tokens": 400, "estimated_tokens_delta": 150, "uuid": "814f5409-90b4-45fd-b1df-9d413384ddae", "session_id": "849b0e9f-2703-4cdf-828d-724996966754"}
--- turn 62 ---
[agent:thinking]
Autowebcompat agents are struggling to submit results sometimes because they're trying to place the required parameter inside another parameter as xml, something like
<parameter name=\"evidence\">onReset.toString() plus its string table ...</parameter>Here it's diagnosis agent submitting
evidenceinsideroot_causefor run232a2fb2-3ba4-4376-85da-07e043281834: