Closed Bug 1688183 Opened 3 years ago Closed 3 years ago

Forms being cached even with appropriate cache headers

Categories

(Toolkit :: Form Autofill, defect, P3)

Firefox 84
defect

Tracking

()

RESOLVED DUPLICATE of bug 654072

People

(Reporter: Niklas.Hanft, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

I'm recently switched from chrome to firefox 84.0.2 (64-Bit) Windows version as my local development/daytoday browser.

I encountered an issue while dealing with localhost form submissions. My form is being cached (filled out) until I explicitly press "SHIFT+STRG+R". Even with the appropriate no-cache headers coming from my backend. (Cache-Control: max-age=0, private, must-revalidate)

In short:

  1. Filling out forms
  2. Submit forms OR explicitely reload page with F5/STRG+R

Actual results:

A normal "refresh" wont purge my form. It stays there as before submitted.

This issue occurs also on other pages than localhost.
(Go in the web, fill out a form und just reload)

Expected results:

Firefox should not cache my forms when reloading.

For my understanding F5 or STRG+R should always purge my forms, because logic is responsible for "pre-fill" my forms not caching.

<opinion>
Even with Cache headers, forms are the very dynamic part of the page and never ever should be cached by the browser.
(Imagine pasting a password which just stays there when reloading....)
</opinion>

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Networking: Cache
Product: Firefox → Core

Sean, given your work around bug 1551965, do you know what is happening here? I would expect that the form filling is done by the form autofill component and doesn't depend on network cache - but on the other hand, if force-refresh does clear the form, either form autofill code is checking refresh flags or somehow otherwise deciding not to fill the form.

Niklas: thanks for the report. Do you have a testcase online somewhere that can be used to reproduce the issue?

Flags: needinfo?(sefeng)
Flags: needinfo?(Niklas.Hanft)

(In reply to :Gijs (he/him) from comment #2)

Sean, given your work around bug 1551965, do you know what is happening here? I would expect that the form filling is done by the form autofill component and doesn't depend on network cache - but on the other hand, if force-refresh does clear the form, either form autofill code is checking refresh flags or somehow otherwise deciding not to fill the form.

Niklas: thanks for the report. Do you have a testcase online somewhere that can be used to reproduce the issue?

Interestingly the login for github.com is not being cached, and for example gitlab.com is being cached.

Its enough to write "test" in the gitlab username field and press reload. Do you need a video?

Flags: needinfo?(Niklas.Hanft)

(In reply to Niklas.Hanft from comment #3)

(In reply to :Gijs (he/him) from comment #2)

Sean, given your work around bug 1551965, do you know what is happening here? I would expect that the form filling is done by the form autofill component and doesn't depend on network cache - but on the other hand, if force-refresh does clear the form, either form autofill code is checking refresh flags or somehow otherwise deciding not to fill the form.

Niklas: thanks for the report. Do you have a testcase online somewhere that can be used to reproduce the issue?

Interestingly the login for github.com is not being cached, and for example gitlab.com is being cached.

Its enough to write "test" in the gitlab username field and press reload. Do you need a video?

It starts feeling a little fishy to me. The behavior is different from browser to browser but with firefox it is not consistently reproducible. For now only gitlab and localhost, also a rails site, are showing this symptoms. It may be a combination of framework "features" and caching. Not sure.

This seems to be related to the autocomplete feature. Niklas, Can you try adding autocomplete="off" to your <input> field and see if it's still being cached?

Flags: needinfo?(sefeng) → needinfo?(Niklas.Hanft)

(In reply to Sean Feng [:sefeng] from comment #5)

This seems to be related to the autocomplete feature. Niklas, Can you try adding autocomplete="off" to your <input> field and see if it's still being cached?

I can confirm that this is a issue if:

  1. No explicit "autocomplete" is set. (Every normal input field)
  2. Autocomplete is set to "off".

Only "autocomplete=off" makes the cache not applying. (F5 resets the form)

Its also noteworthy, that my input is being cached while switching from autocomplete=on to off. After setting the input to autocomplete=on the value from before is restored.

This issue affects "input" and "textarea" fields the same way.

Thanks for the hint!

Flags: needinfo?(Niklas.Hanft)

(In reply to Niklas.Hanft from comment #6)

(In reply to Sean Feng [:sefeng] from comment #5)

This seems to be related to the autocomplete feature. Niklas, Can you try adding autocomplete="off" to your <input> field and see if it's still being cached?

I can confirm that this is a issue if:

  1. No explicit "autocomplete" is set. (Every normal input field)
  2. Autocomplete is set to "off".

Only "autocomplete=off" makes the cache not applying. (F5 resets the form)

Its also noteworthy, that my input is being cached while switching from autocomplete=on to off. After setting the input to autocomplete=on the value from before is restored.

This issue affects "input" and "textarea" fields the same way.

Thanks for the hint!

To clarify:

It is an issue if:

  1. No explicit "autocomplete" is set. (Every normal input field)
  2. Autocomplete is set to "on".

Sorry for the typo

This seems not a networking bug.
Please correct the component if I do not set it right.

Component: Networking: Cache → DOM: Forms

jdai: Could you take a look?

Flags: needinfo?(jdai)

Yes, I will take a look. Keep NI for tracking.

Since this is related to autocomplete preference setting, moving to Form Autofill component.

Component: DOM: Forms → Form Autofill
Flags: needinfo?(jdai)
Product: Core → Toolkit
Severity: -- → S3
Priority: -- → P3

This looks like a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=654072

I too am having this problem. Essentially Firefox auto-restores form values if a form wasn't submitted. So you can type something into this box, refresh and notice how it persists. There are other times Firefox won't cache, detailed here https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/1.5/Using_Firefox_1.5_caching

This breaks ajax workflow e.g. you submit form by ajax (preventing form submit) - firefox will still persistent the form values on page load.

No other browser does this; Chrome, Safari, Edge, IE. The "fix" is to add autocomplete=off to your form or inputs, but that fixes this issue and breaks a useful one.. autocomplete.

It sucks. But given this was brought up 11 years old I suspect developers see this as more of a "feature" than a bug.

(In reply to holegary from comment #12)

This looks like a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=654072

Yes, this appears to be correct.

I too am having this problem. Essentially Firefox auto-restores form values if a form wasn't submitted. So you can type something into this box, refresh and notice how it persists.

bugzilla does its own caching (check the local storage portion of the devtools "storage" pane), so this webpage isn't really a particularly good testcase for this problem.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

bugzilla does its own caching (check the local storage portion of the devtools "storage" pane), so this webpage isn't really a particularly good testcase for this problem.

Try these examples then:

Example 1 - prevent form submission

<form method="POST" onsubmit="return false">
	<textarea name="test" placeholder="Enter text here. Notice how it persists in firefox, even after page reload" rows="5"></textarea>
	<button name="submit" value="submit" type="submit">Submit</button>
</form>

Example 2 - prevent form submission + send form by ajax

<form method="POST">
	<textarea name="test"></textarea>
	<button name="submit" value="submit" type="submit">
		Submit
	</button>
</form>

<script>
  document.querySelector('form').addEventListener('submit', function(e) {
     e.preventDefault(); // Firefox doesn't care. It will still persist the form values.

	 // Handling the form by ajax. Firefox doesn't see this and will still keep old form data on reload.
     fetch(e.target.action, { method: e.target.method, body: new FormData(e.target) });
  });
</script>

Fill the textarea, click submit, refresh the page - notice how Firefox restores the textarea value.

Chrome, Safari doesn't.

I think if firefox should at least clear the cached values if form submission was prevented, because it's likely the form is being handled by another part of code e.g. submitting by ajax. That's pretty common in apps.

You need to log in before you can comment on or make changes to this bug.