36843 - Bugzilla relies on browser to preserve form data via "press Back"

Status: NEW

(Bugzilla :: Creating/Changing Bugs, defect, P4)

Description

[uridavid.akavia]

While entering a new bug I entered a long and detailed bug report, with examples
and recreated the bug (a quarter of an hour of work late at night). I forgot to
choose a component of the browser (due to the fact that most of the components
don't mean anything to the ordirnary user). When bugzilla corrected me about
that it, I used the back button, as instructed, and found out that my report was
returned to its prisintine blank state. This is really annoying and might limit
the amount of bugs you get (perhaps purposely).
Another thing - it is quite hard to find previous reports of a bug, if you make
it easier somehow (perhaps by allowing users to define keywords or enlarging the
amount) you'll get less duplicate bugs. Your Call.

Comment 1

[Dave Miller [:justdave]]

That might be a bug in your browser...  (what browser are you using?) When I hit 
the back button (either Netscape or iCab) everything I filled in is still there.

Comment 2

[uridavid.akavia]

This appears to be a bug with mozilla, that possibly appears in the release
notes. Just so I'll be sure they know about this - They said that mozilla
doesn't re-post data to a form when pressing back. If this is what I've been
complaining about feel free to mark it as INVALID or DUPLICATE or whatever.

Comment 3

[Matthew T (active 1999-2002)]

De-bogosifying summary.

This is probably just because of Mozilla's erstwhile lack of cache, but it would 
be nice if Bugzilla had a more reliable method of fixing up incomplete reports 
than just saying `use yer Back button'.

Comment 4

[Chris Yeh]

and it would do this how?

Comment 5

[Matthew T (active 1999-2002)]

Chris, if you're going to ask a question, you could at least hang around to 
listen to the answer.

You would do this the same way any other well-behaved Web app (e.g. a Webmail 
app) does it. Instead of just saying `Get Back, thy errant hacker!', you would 
show a variant of the previous page, with the incorrect fields highlighted and 
annotated with what was wrong with them.

Comment 6

[Chris Yeh]

thanks, that was the clarification i was asking for.

Comment 7

[Matthew Tuck [:CodeMachine]]

Pretty sure I've seen this in N4/Linux once or twice, but not always.

Comment 8

[Andreas Franke (gone)]

-> New Bugzilla product, Creating-Bugs component, reassigning.

I just verified that the dataloss bug in mozilla is fixed by now, i.e. the
browser remembers form values that have been entered on the page.
Downgrading to enhancement. Please correct this if you disagree.

Comment 9

[Dave Miller [:justdave]]

re-clarifying summary.  I think this is a good idea in the long run.

Comment 10

[Dave Miller [:justdave]]

*** Bug 134216 has been marked as a duplicate of this bug. ***

Comment 11

[Matthew Craig]

Encountered this bug in Bugzilla (2.16rc2).  I was very frustrated at losing 
all of the data that I had spent time to enter.  Bugzilla Bug 36843 should not 
be a simple request for enhancement: There is a loss of data involved.  I 
propose raising severity to Major or Critical.

Comment 12

[Myk Melez [:myk] [@mykmelez]]

Bug 163714 is a new dataloss bug in Mozilla causing this problem.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Matthew, did you encounter this bug while using Mozilla, and if so what build
were you using?

Comment 14

[Richard M Davis]

I've been nobbled by the Back bug too, most recently using Mozilla 1.2 and then
1.2.1 on Linux. One result is that my second entry of bug details tends to be
more perfunctory than the first - so a different sort of information loss there!

In my own Post-based CGI apps, using Back button in Mozilla (or history.back)
does usually return to completed rather than blank forms, so don't know what
Bugzilla is doing differently. 

OTOH, I think in general it is safer and nicer :) not to rely on browser
etiquette for   "please go back and correct" type functions. Typical
alternatives include:
1. Putting "Back" link/button in the page with hidden form field values that can
be poured back into the program.
2. Re-outputing the completed form with the Error message splashed at the top
3. Adding some pre-send Javascript validation ;)

Bugzilla's very impressive, but anyone adversely affected by this "feature" is
bound to be **** off.

Comment 15

[Dave Miller [:justdave]]

*** Bug 186802 has been marked as a duplicate of this bug. ***

Comment 16

[Joe M]

Also, failed attachments should present the form again. There may be other forms
too (queries?). Maybe creating/changing bugs is not the most appropriate component.

Comment 17

[Dave Miller [:justdave]]

Dealing more appropriately with attachment errors is bug 87420.  Attachments is
a whole different ballgame because of the attached file as part of the upload,
which can't be sent back to the user in a hidden field.

Comment 18

[Joe M]

Bug 87420 doesn't mention the problem of not having the submission redisplayed, 
only that the URL is the same before and after attaching. I think this bug is 
more relevant, even for attachments, unless you'd rather have separate bugs for 
each component. And I don't see why uploading is a whole different ballgame; if 
the submitted file can't be prefilled on the error page, oh well. Everything 
else is the same.

Should I file another bug for queries and add some comments to bug 87420 (or 
open a new bug for attachments? Bug 87420 really addresses a different 
problem)? Or should this bug cover all 3?

Comment 19

[Dave Miller [:justdave]]

Bug 87420 is a different symptom, but the same solution would probably fix it :)

Yeah, probably better to have a separate bug for each component that requires
the fix.  That way we don't have an umbrella bug getting reopened when someone
discovered we missed a form. :)

The best way to do this in enter_bug without code duplication is probably to
have enter_bug.cgi submit to itself and eliminate post_bug.cgi.  But that won't
be real easy to do until Bug.pm can handle writing (which is yet another bug :)

On the other hand, with the forms all being in templates now, it may not be so
big a deal to redisplay the same template from a different perl script.

Comment 20

[Joel Peshkin]

The "SaveThisAsABookMarkableTemplate" function in bug entry should be able to
help here.  After all, it takes the data from the bug form and preloads them
into a bug entry form.  Perhaps the same technique can be applied to the bug
edit page.  

Comment 21

[timeless]

i filed a bug about dataloss in that feature. :)

Comment 22

[muchan (M. Nomura)]

All the discussion here was from Aug to Dec 2002.
Today 21th March 2003, I encountered the same problem, 
  (dataloss, of the details of bug I typed at "Press BACK",
   and later I noticed, that second typing, I gave less 
   information than the first attempt... a dataloss for bugfix..
   sure, I can add the comment about that bug report... )
with Mozilla 1.3b 
 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
 Build ID: 2003021008).

So it wasn't fixed since Dec 2002?

Comment 23

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 24

[Veda Larson Palmer]

(In reply to comment #11)
> Encountered this bug in Bugzilla (2.16rc2).  I was very frustrated at losing 
> all of the data that I had spent time to enter.  Bugzilla Bug 36843 should
> not be a simple request for enhancement: There is a loss of data involved.  I 
> propose raising severity to Major or Critical.

This keeps burning me and just burned me again (mistyped an assignee's email 
address).  It is *not* specific to Mozilla - it occurs in Internet Explorer, 
too (see bug 207805).

Because this is a dataloss bug, please raise the severity of either this bug 
36843 or bug 207805 to major or critical.

I would cast all 10 of my votes for this bug if I could - it is that 
aggravating.

Comment 25

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 26

[Veda Larson Palmer]

This bug is keeps getting postponed because it is filed as an enhancement with 
priority P3 - could you please raise the severity (and priority) of either this 
bug 36843 or bug 207805 to major or critical as it is a dataloss bug that keeps 
burning people (4.5 years old now)?

Comment 27

[Dave Miller [:justdave]]

*** Bug 207805 has been marked as a duplicate of this bug. ***

Comment 28

[Dave Miller [:justdave]]

OK, bugzilla.mozilla.org is now running on https.

This means form data (by design) doesn't get cached in a number of browsers
(apparently Firefox isn't one of them, it still seems to cache for me), which
greatly increases the impact of this issue.

For the scope of the change this is going to involve, I think it's going to have
too big of an impact to make it into 2.20 (which is already frozen), so it'll
still have to go in on the trunk.

The fact that we're using templates now makes this a lot easier to do than it
was when this bug was originally filed, because the form submission can contain
a pointer to which form was used, and the form processing script can just feed
the same template back with the error message at the top and the fields
pre-populated with the data that was posted.

Comment 29

[Myk Melez [:myk] [@mykmelez]]

Back when this bug was filed, redisplaying the form was the only reasonable
solution.  But now all popular browsers support relatively compatible ways of
submitting requests that don't unload the current page and that modify the page
in accordance with the results of those requests (f.e. marking invalid input or
adding additional fields that need editing like when a bug switches products).

I'm speaking of REST interfaces like XMLHttpRequest in IE and Mozilla-based
browsers as well as JavaScript-based on-the-spot input validation.  These
techniques can make the overall experience even better (i.e. faster, and more
coherent) for users than redisplaying the form.

Is this stuff still too cutting edge?  Is it just hype without substance? 
Maybe, but we should think seriously about it, because if it's not too soon, and
if it is actually better, then we'd do ourselves a disservice to spend a lot of
time reimplementing input validation to the current state of the art instead of
the next one.

Comment 30

[timeless]

it's way too cutting edge.

Comment 31

[Myk Melez [:myk] [@mykmelez]]

Hmm, it's not too cutting edge for gmail and orkut.  Both sites write data back
to the server without unloading the current page (or even requiring users to hit
"submit") for certain UI elements.

Comment 32

[timeless]

google is willing to use cutting edge stuff, for a while they didn't support
safari and other browsers (and they still don't support not that old versions of
safari, e.g. the one i used while i was visiting stanford).

Comment 33

[Wayne Sallee]

This bug should be changed to critical.
Why should anyone take the time to carefully document a bug when it's just 
going to be erased by this stupid bug?

Nobody likes having their time waisted.

Comment 34

[zug_treno]

*** Bug 309517 has been marked as a duplicate of this bug. ***

Comment 35

[Stephen Lee]

... or could at least add a keyword to mention it causes data loss. On machines
where I'm using IE6, I sometimes have a browser window open adding a bugzilla
comment for long enough that it decides to refetch the page rather than using
the cached copy, hence clearing out all the fields.

On my local bugzilla installation, I've been known to modify the .cgi on the
server to detect my errant input and replace it with what I'd intended - not an
option with a public bugzilla!

I'm not sure 100%, but I suspect that simply returning a "not modified" code to
a request including appropriate "if-modified-since" or similar headers may fix
this for some browsers.

Comment 36

[Kevin Benton]

As suggested previously, we really need to handle this in a way that's compatible with a stupid browser.  From what I can tell, we need to expect that using the back button will reset a form to its default values, thus, loosing values changed.  It also seems fair to request that we just redisplay the same form a second time, but put back all the values the user supplied to us in the incorrect form.  We could also highlight things that didn't match up.

Javascript is a nice way to deal with it, but from my chair, it still doesn't give us a fix for users who have Javascript turned off.  I agree with the commentor who suggests this bug should have the severity raised.

Comment 37

[Paul]

Attachment: Simple fix to avoid these problems

It really seems that we are creating our own problems by being too strict with the component choice.  We should try our best to accept bugs from the user without forcing them through a rule that requires them to know quite a bit about the internal workings of a product in order to submit.  For my 2 cents I say: "lighten up" and accept my patch.  It will solve the majority of these issues including the attachment issues described.

Comment 38

[Stephen Lee]

Comment on attachment 202751 [details] [diff] [review]
Simple fix to avoid these problems

ISTM that while this could avoid the specific problem of a non-selected component  as noted by the original reporter, it does nothing for the many other fields that could have invalid values. For example, a misspelled keyword or email address, an invalid bug number in the dependencies list, and when adding a comment on an existing bug, many other fields that can be set to invalid values.

If just addressing the "non-selected component" issue, I would also suggest that having a default component per product would be better than arbitrarily selecting the first one. (e.g. most products on b.m.o seem to have a "General" component...). According to bug 145009 this is already possible.

Comment 39

[Stephen Lee]

(In reply to comment #38)
> ... having a default component per product would be better than arbitrarily
> selecting the first one.

Added a request for this - bug 316534. This bug still needs to deal with the wider issue of any other invalid input on bug submission or update.

Comment 40

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 202751 [details] [diff] [review]
Simple fix to avoid these problems

> It really seems that we are creating our own problems by being
> too strict with the component choice.  We should try our best
> to accept bugs from the user without forcing them through a rule
> that requires them to know quite a bit about the internal workings
> of a product in order to submit.

There's something to that, and I certainly think it should be possible for Bugzilla to assign a component for users that don't specify one.  But it shouldn't be the first component in the list, it should be a default component that the admin has specified.

That way not only does the bug go into the right component for "bugs for which the component is not yet known", but the admin can decide whether a given product should have a default component, since there may be valid reasons to sometimes require specification of a valid component on entry.

Note that specifying a default component which gets used if the user doesn't specify one himself is already possible per bug 145009 (although it hasn't happened yet on b.m.o--that's bug 316534), but it's not so easy to use, since it requires template hacking.  I have filed bug 317051 to add specification of a default component to the admin interface.

And yes, the long-term solution to this problem overall, when we can't guess input to fields the user didn't enter anything into, is to redisplay the form rather than making the user go back.  But we should certainly do our damnedest to make educated guesses where possible, and making it easy for admins to specify a default component is a good start.

Comment 41

[Paul]

The cool thing is that when we take the approach to accept the bug 1st.  Issues with the keywords, cc list etc. can be solved by displaying an error message with THE bug. (THE bug because it now has an ID)  This is a whole lot easier because all the code is written to make updates to a bug.

Error message something like "The following keywords were not accepted: foo bar xxx yyy zzz.  The following CC emails addresses are not valid and were not accepted: [e-mail] [e-mail] ..."

Bug 696969:
<regular bug>

Comment 42

[Stephen Lee]

In comment 23, justdave declared this to be a major bug, not an enhancement... restoring "major" severity until an explanation is given for being silently dropped to "enhancement". I (and other commenters) have lost data due to this *bug*. Re-instating dataloss keyword.

Also rephrasing "Summary" to avoid sounding "enhancement-like".

Comment 43

[Stephen Lee]

(In reply to comment #42)
> In comment 23, justdave declared ....
I meant comment 28, which was *on* the 23rd... oops!

Comment 44

[Max Kanat-Alexander]

This is not major and not a blocker only because it primarily is a browser bug in some sense.

I actually had to read the whole bug to even figure out why we'd want to fix it, since the problem has never happened to me (I use Firefox).

I think the only thing we really need to save is the comment. I've known some sites that auto-save your last comment as you're writing it, using AJAX, so perhaps we could do that also. Then you get a popup when you load enter_bug if you didn't successfully submit the last enter_bug comment you wrote.

Comment 45

[Connie]

This works for us in Bugzilla 2.22.1 but does not work in Bugzilla 3.0.4 (same browser, same platform, same settings - Windows XP with Internet Explorer 6).  It can be frustrating if you've spent a long time writing up a problem description only to have it disappear because of a typo in a cc name.

Comment 46

[Guy Pyrzak]

If possible I'd like someone to give some solid "here is how to reproduce this bug" sort of text. 

My suspicion is this is caused when someone does an action which adds something to the dom via JS. I know that's an easy way to break the back button on forms. 

I do agree with the notion that it would be GREAT if we just removed the need to hit back after an error and instead redisplayed the whole bug along with the error message.

Comment 47

[Tanner M. Young [:tmyoung]]

(In reply to comment #46)
> I do agree with the notion that it would be GREAT if we just removed the need
> to hit back after an error and instead redisplayed the whole bug along with the
> error message.

I think that is the real solution here, since it can get very annoying with collisions or not selecting a component or having misspelled a bugmail address to need to use the back button to fix only one problem with a large set of changes.  Eliminating that saves time and frustration for users and would automatically prevent this kind of data loss.  I don't know how difficult that is, but it would substantially enhance the user experience.

Comment 48

[Guy Pyrzak]

(In reply to comment #47)

I agree it would be great. However, I also know this is not trivial to accomplish with Bugzilla because we tried it at work and there were a bunch of "gotchas". 

But I'm also noticing this bug doesn't ask for "Display errors inline of the bug instead of on a separate window". I couldn't find such a bug but maybe it exists. If so I'd be happy to say this is a dup of that one and see if we can get the "display errors inline" as a higher priority. Or maybe we just change this bug to say that.

Comment 49

[jeff.sorensen]

It seems ridiculous that a bug reported in 2002 is still not fixed for IE7 in 2010!  I just ran afoul of this after spending considerable time submitting a bug and do not appreciate having my time wasted.  Any chance this will get fixed in this decade???  And why woulfd the status of this be marked NEW and no one is assigned to it?  Does anyone take bugs seriously or is the whole submission process just something to make it appear someone cares?  I also don't like to waste my time submitting a bug of the bug reporting system!