652427 - Going back to the new bug page loses the description if possible duplicates have been searched for

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Mark Banner (:standard8)]

STR:

1) Create a new bug, with some field incorrect - e.g. a mismatching cc field
1a) Make sure to enter a summary which causes duplicates to be searched for
1b) Enter a description.
2) Hit Submit

=> You get the error about the mismatched cc.

3) Hit Back

=> You get the new bug page with everything filled in except for the description.

This is a really annoying dataloss situation that didn't used to happen.

It doesn't appear to happen if possible duplicates have already been searched for (e.g. following on from step 3, enter a description, hit submit, then hit back again and your text is still there).

I'm using FF 4 on Mac.

Comment 1

[Frédéric Buclin]

I cannot reproduce your issue. When clicking Back, all the data is here.

Comment 2

[Frédéric Buclin]

Can someone else besides the reporter reproduce this?

Comment 3

[:glob ✱]

works for me on firefox-aurora and ie9.

Comment 4

[Frédéric Buclin]

Reopen if someone else can reproduce. It could be a problem with Mark's Fx4, e.g. due to an extension.

Comment 6

[Justin Lebar (not reading bugmail)]

Reopening per comment 4.  I believe Myk reproduced with a clean profile.

See STR in bug 653834.  It takes some futsing.

Comment 7

[:glob ✱]

to reproduce this, first enter a summary to get the duplicates table populated, then fill in an invalid CC, and immediately hit 'submit bug'.

you have to hit 'submit bug' before the results are returned from the name auto-completion (watch it with firebug).

then when you go back, the duplicates table will be missing.

Comment 8

[Max Kanat-Alexander]

(In reply to comment #7)
> then when you go back, the duplicates table will be missing.

  The duplicates table or the description that you entered in the comment? Losing a comment is data loss, losing the duplicates table is not.

Comment 9

[Justin Lebar (not reading bugmail)]

(In reply to comment #8)
> (In reply to comment #7)
> > then when you go back, the duplicates table will be missing.
> 
>   The duplicates table or the description that you entered in the comment?

Both.

Comment 10

[Max Kanat-Alexander]

  pyrzak: This is another "stuff disappears that shouldn't when hitting Back" bug. Any input?

Comment 11

[Justin Lebar (not reading bugmail)]

Any movement on this?  I've heard people complaining about it on IRC periodically, and I just hit it again.

Data loss like this is not acceptable.

Comment 12

[Max Kanat-Alexander]

(In reply to comment #11)
> Data loss like this is not acceptable.

  Really? Gee, I thought it was high fashion. ;-) I fully agree with you that this is a serious issue that should be resolved as soon as we understand why it is happening. What's particularly odd is that YUI isn't touching the description field, so I have no idea why it would be missing data.

  Does it happen in all browsers, or just Firefox?

Comment 13

[Justin Lebar (not reading bugmail)]

> Does it happen in all browsers, or just Firefox?

I did some testing at https://landfill.bugzilla.org/bugzilla-4.0-branch and was unable to reproduce in Chrome.

It seems that when Chrome goes back to the page, it refetches it, while we retrieve it from bfcache.

Comment 14

[Guy Pyrzak]

Attachment: v1

the bug is actually in Firefox/BFCache. BFCache can't handle dynamic form elements and basically breaks whenever a form element is present and then disappears on back. This is exactly what the dup table is doing by adding buttons and then removing them. The fix is simple, remove the buttons from the dup table. There might even be a bug on this since I recall running into this a long time ago.

This makes me sad from a design perspective, but it works and I don't want to add some funky UI that makes it look like a button for no reason. Tested on FF4.

Comment 15

[Max Kanat-Alexander]

  Boris, could you perhaps confirm that the issue Guy describes above is indeed a bug in Gecko's bfcache?

Comment 16

[Boris Zbarsky [:bzbarsky]]

bfcache has no problems with dynamic anything, since it just restores the exact DOM you had before (or more precisely it never gets rid of it).

Comment 14 sounds like a description of a known issue with out non-bfcache form state restoration.

That would be consistent with comment 7 paragraph 2 as well: the fact that a network request is outstanding will make us NOT bfcache the page and instead rely on normal form-state restoration stuff.

Jonas, we really need to fix form state restoration to be saner....

Comment 17

[Max Kanat-Alexander]

Comment on attachment 539419 [details] [diff] [review]
v1

Review of attachment 539419 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/bug.js
@@ +88,5 @@
>      formatCcButton: function(el, oRecord, oColumn, oData) {
>          var url = 'process_bug.cgi?id=' + oRecord.getData('id') 
>                    + '&addselfcc=1&token=' + escape(oData);
> +        var button = document.createElement('a');
> +        button.setAttribute('href', "#");

I think that users do not expect an anchor to automatically perform a data-changing action for them, we'd be violating the Principle of Least Surprise in a fashion that modifies data--not a good idea.

Comment 18

[Guy Pyrzak]

We're going to use http://developer.yahoo.com/yui/examples/button/btn_example02.html in response to the desire to have a button look but not a real button. I'll make sure to include all this in a comment as well.

Comment 19

[Guy Pyrzak]

Attachment: v2

now with fake buttons thanks to YUI.

Comment 20

[Frédéric Buclin]

Comment on attachment 539723 [details] [diff] [review]
v2

>=== modified file 'template/en/default/global/header.html.tmpl'

>-[%# The contents of this file are subject to the Mozilla Public
>+  [%# The contents of this file are subject to the Mozilla Public

No reason to change the indentation.

Comment 21

[Max Kanat-Alexander]

Comment on attachment 539723 [details] [diff] [review]
v2

Review of attachment 539723 [details] [diff] [review]:
-----------------------------------------------------------------

Beautiful. Above the "new YUI.Button" bit, add a comment explaining why we're doing that and not using a standard HTML button.

Comment 22

[Tushar]

Is there a workaround for people who are seeing it consistently using firefox 5.0 ?

Comment 23

[Guy Pyrzak]

(In reply to comment #22)
> Is there a workaround for people who are seeing it consistently using
> firefox 5.0 ?

The bug is caused by hitting submit while an ajax call is happening. The easy thing to do is use firebug to see if something is being loaded or just waiting a bit after filling in the cc field or the summary. 

You could also use greasemonkey to replace the button with a hyperlink.

 I'm not sure how much effort you want to put into a work around. Another work around... BMO could just backport this patch sooner than later. It doesn't really use anything that fancy or dangerous.

Comment 24

[:glob ✱]

(In reply to comment #23)
>  I'm not sure how much effort you want to put into a work around. Another
> work around... BMO could just backport this patch sooner than later. It
> doesn't really use anything that fancy or dangerous.

once it's committed to 4.0 branch (hint!), BMO will pick up this fix.

Comment 25

[Guy Pyrzak]

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/                                                                                                                               
modified js/bug.js
modified skins/standard/enter_bug.css
modified template/en/default/bug/create/create.html.tmpl
modified template/en/default/global/header.html.tmpl
Committed revision 7846. 

Committing to: bzr+ssh://[e-mail]/bugzilla/4.0/                                                                                                                                 
modified js/bug.js
modified skins/standard/enter_bug.css
modified template/en/default/bug/create/create.html.tmpl
modified template/en/default/global/header.html.tmpl
Committed revision 7608.

Comment 26

[Frédéric Buclin]

Comment on attachment 539723 [details] [diff] [review]
v2

>=== modified file 'template/en/default/global/header.html.tmpl'

>-[%# The contents of this file are subject to the Mozilla Public
>+  [%# The contents of this file are subject to the Mozilla Public

I reverted this change, as the new intentation is wrong.

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified template/en/default/global/header.html.tmpl
Committed revision 7847.

Committing to: bzr+ssh://[e-mail]/bugzilla/4.0/
modified template/en/default/global/header.html.tmpl
Committed revision 7609.