I suspect we're not going to roll back our helpful behavior here on account of just this site, so our only option might be an intervention (or maybe outreach if we can get in touch with the site). Our intervention would be some JS snippet like the following, to clear the value on this hidden form field: ```JavaScript var el = document.getElementById('alwaysFetch'); el.value = ''; ``` The tricky bit might be to get this script to run **after** `<input id="alwaysFetch">` gets parsed but *before* the subsequent inline <script> element's setTimeout fires. I'm pretty sure that setTimeout can fire before the "load" event fires, for example. I suppose another mitigation would be to change our form-field-restoration behavior to be something that we can toggle on/off on a per-domain basis for compat reasons, and we could force it to off for this site.
Bug 1943898 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I suspect we're not going to turn off our helpful form-field-restoration behavior here just on account of this site, so our only option might be an intervention (or maybe outreach if we can get in touch with the site). Our intervention would be some JS snippet like the following, to clear the value on this hidden form field: ```JavaScript var el = document.getElementById('alwaysFetch'); el.value = ''; ``` The tricky bit might be to get this script to run **after** `<input id="alwaysFetch">` gets parsed but *before* the subsequent inline <script> element's setTimeout fires. I'm pretty sure that setTimeout can fire before the "load" event fires, for example. I suppose another mitigation would be to change our form-field-restoration behavior to be something that we can toggle on/off on a per-domain basis for compat reasons, and we could force it to off for this site.