Closed Bug 1606773 Opened 5 years ago Closed 5 years ago

On page reload(F5/Ctrl+R), Firefox overrides HTML presets of checkboxes.

Categories

(Core :: DOM: Forms, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 46845

People

(Reporter: csz_stl, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

In HTML, the "checked" attribute was used on a radio button and selected checkboxes to pre-specify various default conditions for users. In Firefox, it works as expected on initial page load but not on page reload.

Actual results:

On page reload, Firefox overrides the "checked" attribute (as well as its absence) to configure all radio buttons and all checkboxes as they were immediately before the reload, instead of respecting the HTML to return them to their default conditions. This is a design defect, not a code bug, because it is reproducible in Firefox versions as old as 2.0.

Expected results:

On page reload, all radio buttons and all checkboxes should be set as specified by the presence or absence of the "checked" attribute in the HTML. The reason for reloading a page is to restore its original state, in order to recover from some unwanted changes that occurred, whether they were accidental errors that occurred during page load or user errors after the page finished loading. This reasonably expectable behavior can be observed in Safari from v.1.3.2 through v.13.0.4 (at least), as well as in OmniWeb 5.1.3. It would be interesting to know how other Web browsers behave.

Let's triage this issue.

Using attached testcase:

  1. Open the testcase.
  2. Check Yes.
  3. Refresh.

Different browsers behaviour, as follows:

Chrome(79.0.3945.88 ) & Safari(12.1.1 14607.2.6.1.1):

on refresh, the checkbox is reset on the default condition.

Edge:

on refresh - there is nothing checked

Firefox 68.3.0esr, Firefox 71.0, Firefox 74.0a1 2020-01-06:

yes check is kept after refresh and not reset to the default

Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → DOM: Core & HTML
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Version: 71 Branch → Trunk

There are "Reload (F5)" and "Reload with override cache (Ctr+F5)" in Firefox https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly. Both shortcut keys worked as expected to me.

Adrian, how did you produce the "refresh" action in comment 1?

Flags: needinfo?(aflorinescu)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #3)

There are "Reload (F5)" and "Reload with override cache (Ctr+F5)" in Firefox https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly. Both shortcut keys worked as expected to me.

Adrian, how did you produce the "refresh" action in comment 1?

Problem is reproducible with refresh/reload: Ctrl+R, F5.
Problem doesn't reproduce with Ctrl+F5. Let's update the title to clarify that.

Later edit:
Since it seems I missed updating the tested OS'es in comment 1, let me state here that it is reproducible on all tested Os'es: Win 10 x32, Win 10 x64, Ubuntu 16.04, Mac 10.14.5.

Flags: needinfo?(aflorinescu)
Summary: On page reload, Firefox overrides HTML presets of checkboxes. → On page reload(F5/Ctrl+R), Firefox overrides HTML presets of checkboxes.

Thanks Adrian! Then this is working as expected per design. Please see https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
Component: DOM: Core & HTML → DOM: Forms
Resolution: INVALID → DUPLICATE

"Working as designed" is not an acceptable excuse for an error in design. A page reload ought always to restore the page to its original state; otherwise, what's the point?

Issue still persists in Firefox version 94.

=> Here's my submission https://bugzilla.mozilla.org/show_bug.cgi?id=1739978

=> Above submission was flagged as possible duplication of https://bugzilla.mozilla.org/show_bug.cgi?id=654072

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

Attachment

General

Created:
Updated:
Size: