Closed Bug 368034 Opened 18 years ago Closed 17 years ago

Data in "Set Up", "Break Down", "Action" and "Expected Results" all become "undefined" after saving an admended test case.

Categories

(Testopia :: Test Cases, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kccho4, Assigned: gregaryh)

References

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)
Build Identifier: Internet Explorer Version: 6.0.2900.2180.xpsp_sp2_gdr.050301-1519

Hi, I have created a dummy test case under a test plan. The record should have data in "Set Up", "Break Down", "Action" and "Expected Results". However when I was trying to amend some data under "Attribute", all data in "Set Up", "Break Down", "Action" and "Expected Results" become "undefinedundefinedundefined" after clicking "commit". Pls kindly help, thanks a lot.   

Reproducible: Always

Steps to Reproduce:
1.Create a new test case w/ data under "Set Up", "Break Down", "Action" and "Expected Results"
2.Retrieve the test case and amend a field under "Attribute"
3.Click on commit
Actual Results:  
All data under "Set Up", "Break Down", "Action" and "Expected Results" become "undefinedundefinedundefined"  

Expected Results:  
All data under "Set Up", "Break Down", "Action" and "Expected Results" should remain the same as before.
This only appears to happen in Internet Explorer. Firefox does not exhibit this behavior.
Update the version and I've retested in Firefox.  I can't reproduce the case mentioned above
Version: unspecified → 1.1
I experience this problem with Internet Explorer 7, using the http://landfill.mozilla.org/testopia/ (15 february 2007) site. See http://landfill.mozilla.org/testopia/tr_show_case.cgi?case_id=407
There's a lot of 'undefined' there...

I also get the same problem using Internet Explorer 7 on testopia-1.1.3 with bugzilla-2.22.2

Both above is repeatable every time.

Using Firefox 2.0.0.1 on a Gentoo machine it works as expected though.
Dojo has fixed this bug and it will appear in the 1.3 release of Testopia.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
I am using Testopia 1.3 and am able to reproduce this bug.

My environment:
Windows XP
Bugzilla 3.0
Mysql 5.0
Apache 2.2.4
ActivePerl 5.8.8
Testopia 1.3
Internet Explorer 7

Repro Steps:
1) Home > New Case
2) Select a plan
3) Type in something for these items in the testcase:
  Summary
  Set up
  Break down
  action 
  expected results
4) Click one of the Add buttons
5) Verify that your data was saved
6) Double click Breakdown and edit it (add some more text)
7) Click Commit when you are done
8) Note that Breakdown is saved and other three change to: 'undefined'

Has anyone actually gotten around this problem?

I also have a variety of errors in BZerrorLog.  I don't know if any of them are relevant.  This is a new install:

... index.cgi: Use of uninitialized value in substitution (s///) at (eval 42) line 45.
(several)

... File does not exist: C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/bz/testopia.css, referer: http://bug.mpowerlabs.com/tr_new_case.cgi?plan_id=
(several)

...File does not exist: C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/bz/testopia/dojo/src/widget/nls/en, referer: http://bug.mpowerlabs.com/tr_new_case.cgi?plan_id=1
(several)

... File does not exist: C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/bz/testopia/dojo/src/widget/nls/en-us, referer: http://bug.mpowerlabs.com/tr_new_case.cgi?plan_id=1
(several)

... File does not exist: C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/bz/testopia/dojo/src/__package__.js, referer: http://bug.mpowerlabs.com/tr_new_case.cgi?plan_id=1
(several)

... tr_new_case.cgi: Use of uninitialized value in split at C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/bz/tr_new_case.cgi line 136., referer: http://bug.mpowerlabs.com/tr_new_case.cgi?plan_id=1

... File does not exist: C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/bz/testopia/dojo/src/dom, referer: http://bug.mpowerlabs.com/tr_new_case.cgi
(several)

... tr_show_case.cgi: Use of uninitialized value in split at C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/bz/tr_show_case.cgi line 404., referer: http://bug.mpowerlabs.com/tr_new_case.cgi
(several)

... tr_show_case.cgi: Use of uninitialized value in string ne at Bugzilla/Testopia/TestCase.pm line 805., referer: http://bug.mpowerlabs.com/tr_new_case.cgi
(several)

I am evaluating if Testopia will work for us.  Has anyone managed to work around this bug and otherwise be happy with Testopia?

Thanks for all the great work from the volunteers!
I've noticed that I can work around the bug (with IE) by opening all four editors before clicking commit.  In the failure repro steps I am just opening one of the four and the other three are lost.  If all four are opened, none are lost.

I thought this might help debug it.  I can, of course, just use Firefox, but I am worried about when someone accidentally uses IE and test data is lost.

Maybe a 'hacky workaround' could be added to open all four up at the beginning of the commit process?
Here is my hack.  It seems to allow IE not to loose the data and doesn't disturb FireFox.  

Add this:

    var version=0;
    if (navigator.appVersion.indexOf("MSIE")!=-1){
        temp=navigator.appVersion.split("MSIE");
        version=parseFloat(temp[1]);
    }
    if (version>=5.5) //NON IE browser will return 0
	    this.gotoEditMode();

to htdocs\bugzilla\testopia\js\DocumentManager.js

So that in the end you have:

DocumentManager.prototype.handleSubmit = function (evt) {

    var version=0;
    if (navigator.appVersion.indexOf("MSIE")!=-1){
        temp=navigator.appVersion.split("MSIE");
        version=parseFloat(temp[1]);
    }
    if (version>=5.5) //NON IE browser will return 0
	    this.gotoEditMode();
		
    var el = document.createElement("input");
    el.setAttribute("id", this.prefix);
    el.setAttribute("name", this.prefix);
    el.setAttribute("type", "hidden");
    var value;
    if (this.widget) {
    value = this.widget.getEditorContent();
    } else {
    value = "";
    for (i = 0; i < this.div.childNodes.length; ++i) {
        value = value + dojo.dom.innerXML(this.div.childNodes[i]);
    }
    }
    el.setAttribute("value", value);
    dojo.dom.insertAfter(el, this.div);
}
You need to log in before you can comment on or make changes to this bug.