220034 - empty form after changing bug details

Status: RESOLVED FIXED

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

Description

[Denny Reeh]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827

after changing and submitting a bug, you get normally a "Bug processed"-message
an seeing the next bug. but the next bug isn't shown korrectly. the heading "
The next bug in your list is bug 1347:" is shown, but the formular fields are empty.
with mozilla, i'm getting javascript-errors:

Error: syntax error
Source File: http://devel.ets-online.de/bugzilla/process_bug.cgi
Line: 243, Column: 23
Source Code:
  var fRemainingTime = ; // holds the original value


Error: addReplyLink is not defined
Source File: http://devel.ets-online.de/bugzilla/process_bug.cgi
Line: 614

Reproducible: Always

Steps to Reproduce:
1. select a bug
2. change details
3. submit the changes

Actual Results:  
the bug changes are saved, but the next bug isn't shown.

Expected Results:  
mozilla shows an empty formular.

Comment 1

[Dave Miller [:justdave]]

This sounds like it's related to the reply-link thing....   kiko?

Comment 2

[Dave Miller [:justdave]]

Reproduced on landfill.  This is pretty severe....

Comment 3

[Christian Reis]

Actually, it's more related to the time-tracking implementation. The code in
fault (in edit.html.tmpl) follows:

[% IF UserInGroup(Param('timetrackinggroup')) %]
  var fRemainingTime = [% bug.remaining_time %]; // holds the original value

As you can see from the output in the error, bug.remaining_time is null.

This error only occurs if timetrackinggroup is on, the user is in the group, and
the bug has no remaining time. 

The bandaid fix is maybe (I have no idea on the real implementation of this):

[% IF UserInGroup(Param('timetrackinggroup')) and bug.remaining_time %]
    var fRemainingTime = [% bug.remaining_time %]; // holds the original value

-- but maybe Jeff has a better idea.

Now I'm not saying there's nothing I can do about the addReplyLink consequences,
of course :-) I need some help from caillon: is there a way I can work around JS
errors and make addReplyLink not die a horrible death if an unrelated problem
occurs?

Comment 4

[Christian Reis]

Jeff did some JS changes in bug 179293 that did some bulletproofing, but if the
user *is* in a timetrackinggroup, the code is included.

I guess the real question is why is bug.remaining_time null in this case? 
Do Denny or Jeff have any idea?

Comment 5

[Gervase Markham [:gerv]]

Given that JS auto-converts from strings to numbers, an alternative band-aid
might be:

var fRemainingTime = "[% bug.remaining_time %]";

Better, though, is to make sure remaining_time is never null - null has no
meaning for a remaining time. It should always be a non-negative decimal.

Gerv

Comment 6

[Jussi Sirpoma]

I'm seeing this on my site and I do not have time tracking enabled. All bugs are
in one or more group. These are the error messages I'm getting:

[Fri Oct  3 01:36:32 2003] process_bug.cgi: Argument "" isn't numeric in numeric
gt (>) at data/template/en/default/bug/edit.html.tmpl line 310.
[Fri Oct  3 01:36:32 2003] process_bug.cgi: Argument "" isn't numeric in numeric
gt (>) at data/template/en/default/bug/edit.html.tmpl line 419.
[Fri Oct  3 01:36:32 2003] process_bug.cgi: Date/Time format () unrecogonzied at
Bugzilla/Util.pm line 167.

The first error comes from line 294 in edit.html.tmpl:
        [% IF bug.flag_types.size > 0 %]

So could it be that bug is not defined for some reason?

Comment 7

[Christian Reis]

Sounds like flag_types is null, more likely. Possible?

Anyway.. Gerv, where should we go with this?

Comment 8

[Teemu Mannermaa (:wicked)]

Actually to me it seems that the whole bug object is null. Line "$vars->
{'bug'} = $bug;" that was in the file process_bug.cgi before processing 
next.html.tmpl was removed as part of bug 208699. I take this makes bug object 
missing from $vars when edit.html.tmpl template is processed.

See http://bonsai.mozilla.org/cvsview2.cgi?
diff_mode=context&whitespace_mode=show&file=process_bug.cgi&branch=&root=/cvsro
ot&subdir=mozilla/webtools/bugzilla&command=DIFF_FRAMESET&rev1=1.189&rev2=1.190

Adding that line back to process_bug.cgi seems to fix this bug.

Comment 9

[Vlad Dascalu]

Attachment: Adding the next bug information to the template.

I don't know if this fixes the time-thing, but right now the whole information
for the next bug is empty. All the fields.

Steps to reproduce:

-> make a query which returns multiple bugs.
-> select the first bug.
-> change something, click Submit.

Result: the "next" bug displayed has completely empty forms.
Expected results: the actual data for the next bug.

This patch fixes this.

Comment 10

[Christian Reis]

Comment on attachment 133030 [details] [diff] [review]
Adding the next bug information to the template.

Yep, seems that bbaetz missed that dependency. 

Maybe add a comment that makes it clear that the template wants $bug defined?
At any rate, good catch, r=kiko.

Comment 11

[Vlad Dascalu]

Attachment: Version 2

>> At any rate, good catch

Well, the credit goes to Teemu (comment #8) :).

Comment 12

[Vlad Dascalu]

Attachment: Version 2

Seems the previous one is corrupted.

Comment 13

[Christian Reis]

Well, your comment describes "the what" instead of "the why". While the code
itself should make the former clear, good comments focus on the latter. I suggest

   # next.html.tmpl includes edit.html.tmpl, and therefore we
   # need $bug defined in $vars.

The comment was just a nit, though, you can carry on my r= and just fix it on
checkin.

Comment 14

[Vlad Dascalu]

Thanks!

I'll replace my comment with yours upon checkin, if that's ok.

Comment 15

[Dave Miller [:justdave]]

-> patch author.

Vladd: go ahead and check it in, with the comment changes you noted.

Comment 16

[Christian Reis]

Vladd, before closing please make sure the original problem reported isn't
happening any more (i'm still a bit sketchy as to what bug.remaining_time is
being set to right now, and I originally thought that was the actual problem).

Comment 17

[Vlad Dascalu]

Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.192; previous revision: 1.191
done

I'll let this opened until someone can confirm that it's fully fixed.

Comment 18

[Vlad Dascalu]

Removing the approval+ flag to:

-> make the bug disappear from the "ready to checkin" query (already checked in).
-> allow the "a?" flag to be set for eventually new patches that will be posted
here.

Comment 19

[Dave Miller [:justdave]]

uh, say what?

What's happening that this didn't fix?

Comment 20

[Christian Reis]

Well, I am still curious about bug.time_remaining, but I'm very busy today. I'll
look into this tomorrow if nobody can do it before that.

Comment 21

[Teemu Mannermaa (:wicked)]

It's 4am right now but as this bug is assigned to me I couldn't resist the 
temptation to test it more. So I went and updated process_bug.cgi from cvs to 
v1.192 and tested the code.

Re problem in description and in comment #9: next bug is shown with correct 
information. There are no erroneous empty fields. Same data is displayed as in 
show_bug.cgi for the same bug.

Re problem in comment #6: there are no errors in error log after the change.

Re comment #4 and comment #7: to my understanding the bug.remaining_time and 
bug.flag_types were null because the bug object that contained them was null 
thus making them null also.

Re comment #16 and comment #20: I'm in timetrackinggroup and can see the 
correct values in the time tracking fields. Even the javascript updating Hours 
left fields seems to behave normally (or atleast the same as in show_bug.cgi).

I would say this is fixed but feel free to test some more if you think 
otherwise or want to make the timetracking code more robust. I can't think of 
anything more to test and besides I have run out of bugs to change..

Comment 22

[Dave Miller [:justdave]]

yeah, I thought as much.  If someone thinks this is still broken, reopen this
and tell us why.