1943898 - www.capital.gr - The site refresh indefinitely

Status: REOPENED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Calin Tanase]

Environment:
Operating system: Android 10
Firefox version: Firefox Mobile [phone]

Steps to reproduce:

1. Go to https://www.capital.gr/
2. Refresh the page.
3. Observe the behavior.

Expected Behavior:
The page reloads correctly.

Actual Behavior:
The page reloads indefinitely.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/74073

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[Daniel Holbert [:dholbert]]

I can reproduce on desktop in Responsive Design Mode, with a 300x600 viewport and this user agent string taken from my phone:

Mozilla/5.0 (Android 15; Mobile; rv:136.0) Gecko/136.0 Firefox/136.0

I wasn't able to reproduce when I used a 400x600 viewport [EDIT: I can repro with this window size after all; it just needs a manual reload in order to trigger the issue, and I'd overlooked that part.]

Here's a profile (with networking logging enabled in case it's handy, and with 0.1ms-frequency samples), showing several of the reloads:
https://share.firefox.dev/4jGbVA3

The marker-chart shows some CreateAboutBlankDocumentViewer marks right around each reload point. I haven't yet dug backwards to see what's causing the reload.

Comment 3

[Daniel Holbert [:dholbert]]

The site here does something pretty pathological -- reloading immediately as soon as we load the page, basically -- and it seems that Chrome has a mitigation for that sort of pattern and we don't (or our intervention isn't effective in this case).

Comment 4

[Daniel Holbert [:dholbert]]

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:

    <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().

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2 (interactive, just to test if form-field content survives across pageloads)

Maybe Chrome doesn't preserve form state across reloads at all, actually?

Here's an interactive testcase to illustrate this.

STR here:

1. Load the testcase
2. Type "abc" into the textfield
3. Ctrl+R

Firefox behavior: The textfield still shows "abc" after the reload.
Chrome behavior: The textfield is blank after the reload.

Firefox's behavior here is meant to be helpful, but this particular site happens to be depending on the Chrome behavior (and they reload-forever in a browser with the form-field-preserving Firefox behavior, via the pathological setTimeout-based mechanism described above).

Comment 7

[Daniel Holbert [:dholbert]]

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:

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.

Comment 8

[Daniel Holbert [:dholbert]]

A few references:

• There's some analysis/description of this behavior across browsers here.
• It seems we have bug 46845 filed on the interop difference here, which is resolved as invalid because presumably we're not planning to change, but it appears we're also using it to track sites that appear broken in Firefox due to this behavior.

Comment 9

[Daniel Holbert [:dholbert]]

Ah, it looks like ksenia already diagnosed this in https://github.com/webcompat/web-bugs/issues/74073#issuecomment-860833691

Calin: when moving issues from github to bugzilla: if you happen to notice that some diagnosis has already been done on the GitHub issue, it'd be great to call that out in the Bugzilla bug-report, so that we don't duplicate diagnosis work. Thanks!

Comment 10

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1943898 - add an Android-only webcompat intervention for www.capital.gr to prevent endless reloading cycles; r?denschub

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d8ac17a8856f
add an Android-only webcompat intervention for www.capital.gr to prevent endless reloading cycles; r=denschub,webcompat-reviewers

Comment 12

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/d8ac17a8856f

Comment 13

[railioaie]

The issue has been fixed.

Tested with:

Browser / Version: Firefox Nightly 138.0a1-20250323000437
Operating System: Android 11

Comment 14

[railioaie]

Attachment: 25.03.2025_10.35.05_REC.mp4

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:twisniewski, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox137 to wontfix.

For more information, please visit BugBot documentation.

Comment 17

[railioaie]

Verified as FIXED using RC Build fenix android-arm64-v8a

Tested with:

Browser / Version: Firefox 138.0 Build 2016086490
Operating System: Samsung A51 (Android 11) -1080 × 2400 pixels 20:9 aspect ratio (~405 ppi density)

Comment 18

[Thomas Wisniewski [:twisniewski]]

This should be left open for tracking purposes, while we still need a webcompat intervention.

Comment 19

[Raul Bucata]

Leaving a comment here, while has an intervention, to eliminate it from our weekly QA re-triage list.

Comment 20

[Raul Bucata]

Leaving a comment here, while has an intervention, to eliminate it from our weekly QA re-triage list.

Comment 21

[Raul Bucata]

Leaving a comment here, while the intervention is active, to eliminate it from our weekly QA re-triage list.

Comment 22

[Raul Bucata]

Leaving a comment here, while the intervention is active, to eliminate it from our weekly QA re-triage list.

Comment 23

[Raul Bucata]

Leaving a comment here, while the intervention is active, to eliminate it from our weekly QA re-triage list.