Hitting Refresh does not reset form values

CLOSED DUPLICATE of bug 46845

Status

()

Core
Layout: Form Controls
CLOSED DUPLICATE of bug 46845
16 years ago
9 years ago

People

(Reporter: James Green, Assigned: Eric Pollmann)

Tracking

({regression, relnote})

Trunk
x86
Linux
regression, relnote
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: JMKG - Document this feature in help docs)

(Reporter)

Description

16 years ago
This is a result I believe of the recent checkin to make form values persist on
going forward/backward.

Steps to reproduce:
1.  Go to a Bugzilla bug. Enter and update. Hit Submit/whatever
2.  Once bug is updated, go back, and find the form has the values you put in
3.  Hit refresh

Expected Results:
Page is refreshed and the form is reset to default values.

Actual Result:
Page is refreshed, and the form contains the values as you last used them (e.g.
your last comments are there).

You can only reset the form but entering the bug number into the bugzilla footer
and hitting 'Find'. Presumably you can also do it but restarting the browser.

I have both Memory and Disk caches turned on. We may get a number of complaints
about this from 0.9.1 users, I don't know.
(Reporter)

Comment 1

16 years ago
CC pollman who cheched this in for bug 77834, nisheeth/jst who r/sr=ed the bug.
Keywords: mozilla0.9.2, regression

Comment 2

16 years ago
--> HTML form controls
Assignee: morse → rods
Component: Form Manager → HTML Form Controls
QA Contact: tpreston → vladimire
Unless I'm mistaking, I've seen this for weeks in mozilla, and I kinda like it
(but maybe that's just me).

Comment 4

16 years ago
reassigning
Assignee: rods → pollmann
(Reporter)

Comment 5

16 years ago
I believe I saw this last week, but I wasn't sure of myself. What happened then
was that I changed the Severity or something in a bug, realised I had an old
version of the bug page present, hit reload to get the newest comments, and
noticed that the pull-down menu still had my changes.

This is fine if you don't need to see the original form values, but if you
changed a form value, hit refresh to reset it (perhaps you couldn't recall the
old value), and assumed it had be reset on the reload then you have a problem.

Comment 6

16 years ago
I concur with jst, this has been the case for some time and I think it's cool.
To reset the form values hit shift+reload. Of course it's inconsistent with
IE... but who cares.
I too vote for WONTFIX/WORKSFORME on this. Shift+Refresh does a complete
reshresh. Plain Refresh fetches up new content but keeps your changes in the
form controls, which is cool (especially so with Bugzilla).
(Reporter)

Comment 8

16 years ago
OK I'm in favour of WONTFIXing this since although I didn't get it's behaviour,
and I know others won't, it could be useful in some situations.

I do however strongly suggest this feature is documented in the help guide.
Adding relnote keyword and marking WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Keywords: relnote
Resolution: --- → WONTFIX
Whiteboard: JMKG - Document this feature in help docs

Comment 9

16 years ago
Verifying, sounds good to me.
Status: RESOLVED → VERIFIED

Comment 10

16 years ago
*** Bug 78420 has been marked as a duplicate of this bug. ***

Comment 11

16 years ago
Ick! Ick! Ick! Bad! Bad! Bad! Wrong! Wrong! Wrong! This has been driving me mad
for several days. It really wrecks havoc with the web-apps I am trying to design
at work.

see http://HamsterRepublic.com/tmp/formy-test.php

I can, (with much grumbling and complaining) live with the SHIFT+RELOAD
workaround, but I can see alot of situations on script-generated pages where
this is going to severely discombobulate people. If the above URL doesnt
convince you to at least reconsider WONTFIXing this, I can spend some time write
some more elaborate bad examples for you :(
(Assignee)

Comment 12

16 years ago
Marking this as a dup of the master bug, which was created and resolved long ago.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 13

16 years ago
Marking dup.

*** This bug has been marked as a duplicate of 46845 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → DUPLICATE

Comment 14

16 years ago
Well that means you'll have to reopen bug 46845 and fix it, right? The reasons
mpt and blake give in that bug are imho good enough to make me change my mind
about this

Comment 15

16 years ago
Ah, well, I spent some time messing with testcases for this, and recant on my
whining. For most purposes this is a spiffy feature to have, and most of my
problems came from situations where I was repeatedly reloading a page whilst I
edited the script that generated it, which is something average users arent
going to be doing. If I come up with any situations where a regular reload of a
form does something it shouldnt, Ill file it as a separate and specific bug.

Comment 16

16 years ago
closing
Status: RESOLVED → CLOSED
Why closed? Shouldn't you have verified this?
You need to log in before you can comment on or make changes to this bug.