Bugzilla

Actually maybe this isn't so much a mitigation as just a difference in how form field state is preserved across reloads.

The site here does this:
```
    <input id="alwaysFetch" type="hidden" />
    <script>
        setTimeout(function () {
            var el = document.getElementById('alwaysFetch');
            el.value = el.value ? location.reload() : true;
        }, 0);
    </script>
```

The first time you load the page, the `alwaysFetch` element is empty, which means `el.value` is falsey, so this assignment...
```
     el.value = el.value ? location.reload() : true;
```
...essentially just evaluates to:
```
     el.value = true;
```

The next time you load the page, we preserve the form state, which means when we hit that setTimeout, `el.value` is now truthy. So that assignment now evaluates to:
```
el.value =  location.reload();
```
...and we reload.  The next load does the same thing, etc. forever.

In Chrome, I think `el.value` doesn't get preserved to the next page load in this case for some reason, so they never trigger the `location.reload()`.

Actually maybe this isn't so much a mitigation as just a difference in how form field state is preserved across reloads.

The site here does this pathological thing:
```html
    <input id="alwaysFetch" type="hidden" />
    <script>
        setTimeout(function () {
            var el = document.getElementById('alwaysFetch');
            el.value = el.value ? location.reload() : true;
        }, 0);
    </script>
```

The first time you load the page, the `alwaysFetch` element is empty, which means `el.value` is falsey, so this assignment...
```
     el.value = el.value ? location.reload() : true;
```
...essentially just evaluates to:
```
     el.value = true;
```

The next time you load the page, we preserve the form state, which means when we hit that setTimeout, `el.value` is now truthy. So that assignment now evaluates to:
```
el.value =  location.reload();
```
...and we reload.  The next load does the same thing, etc. forever.

In Chrome, I think `el.value` doesn't get preserved to the next page load in this case for some reason, so they never trigger the `location.reload()`.

Actually maybe this isn't so much a mitigation as just a difference in how form field state is preserved across reloads.

The site here does this pathological thing:
```html
    <input id="alwaysFetch" type="hidden" />
    <script>
        setTimeout(function () {
            var el = document.getElementById('alwaysFetch');
            el.value = el.value ? location.reload() : true;
        }, 0);
    </script>
```

The first time you load the page, the `alwaysFetch` element is empty, which means `el.value` is falsey, so this assignment...
```
     el.value = el.value ? location.reload() : true;
```
...essentially just evaluates to:
```
     el.value = true;
```

The next time you load the page, we preserve the form state, which means when we hit that setTimeout, `el.value` is now truthy (it's probably the string "true" or whatever `el.value = true` coerces to). So the assignment now evaluates to:
```
el.value =  location.reload();
```
...which reloads (and also stores the string `undefined` in the input element).  The next load does the same thing, etc. forever.

In Chrome, I think `el.value` doesn't get preserved to the next page load in this case for some reason, so they never trigger the `location.reload()`.