Endless-Loop when Depth > 2

[Stefan Niedermann]

If i select with the "v"-Button a Depth larger than 2, i get a endless loop.

See the Loading-Circles on the right top corner.

[Kinto Soft]

Administration > System > Troubleshooting and Support > Logging and Profiling > Default Loggers > Configure

[Stefan Niedermann]

Both, firefox and chrome are doing the same on the surface: draw many loading circles (as in screenshot top right). i have no IE to test.

i'm sorry, i can't see anything in the log files. where do i enable

com.docminer.*

com.estreetsoft.*

logging?

[Kinto Soft]

Wow, how much different they are!

While Chrome points to a possible server call disruption (likely because some exception raised from the add-on code):

dwr.engine.remote.handleCallback engine.js:861

(anonymous function) VM2935:6

(anonymous function) VM2935:7

dwr.engine._eval engine.js:600

dwr.engine.transport.xhr.stateChange engine.js:1648

Firefox points to an attempt to draw null (undefined) issues:

[10:20:09.723] Unerwarteter Wert translate(undefined,undefined) beim Parsen des Attributs transform. @

[translate(X,Y) is an HTML5 instruction to locate graphic SVG elements in the (X,Y) coordinates when called from the transform function]

I mean they are very different symptoms regarding to the same issue. Well, maybe the Chrome stops the execution when an exception is raised and the call aborted (this is the expected behavior) while Firefox continues with undefined values. But, in general, Chrome and FF (even IE) should work just in the same way, therefore this is quite strange.

I think the key is in the JIRA server log. Do you see anything there?

[Stefan Niedermann]

It is reproducable with different issues in different projects. it happens on some issues if i change depth from 1 to 2, in some other issues if i change depth from 2 to 3, but on each issue it happens at the same time.

Sorry 'bout the autosave, this is not true. ignore this statment.

Chrome Console shows:

Error: Problem parsing d="M,CNaN, NaN, ," batch.js:22
a batch.js:22
(anonymous function) batch.js:24
Tn batch.js:22
Ma.each batch.js:24
Ma.attr batch.js:24
update batch.js:2064
(anonymous function) batch.js:2272
processIssue batch.js:1557
(anonymous function) batch.js:1508
dwr.engine.remote.handleCallback engine.js:861
(anonymous function) VM2935:6
(anonymous function) VM2935:7
dwr.engine._eval engine.js:600
dwr.engine.transport.xhr.stateChange engine.js:1648
batch.req.onreadystatechange engine.js:1493

Firefox Console shows:

[10:20:09.723] Unerwarteter Wert translate(undefined,undefined) beim Parsen des Attributs transform. @ https://example.com/s/de_DEx1iaa1/787/29/41f5a6eb3f80a2ee4f58d3c8a2673097/_/download/contextbatch/js/jira.view.issue,atl.general/batch.js:23

in english: unexpected value translate(undfined, undefined) while parsing the attribute "transform".

JIRA-Version: 5.1.8

[Kinto Soft]

and might you also please look at the javascript console of your browser? I've reviewed the code and this might happen whether some error occurs while calling to the server to retrieve more issues. In this case, the error message would be logged into the browser console...

[Kinto Soft]

well, of course, and enable the logs on JIRA for the following packages:

com.docminer.*

com.estreetsoft.*

My guess is that something is going wrong at the server side and for an unknown reason (at the moment) some linked issues cannot be fetched by the add-on at the server raising an exception (which is written in the JIRA logs) and making the client abort the call without removing the spinner.

[Kinto Soft]

Looking at this.

Is it there any pattern to reproduce it? Does it happen with the same issues and every time that you see them? Or does it happen randomly (some times everything works fine and some times just the same issue has this behavior)?

This is a very painfull issue for us, especially since the "autosave"-option is enabled by default.

How does the autosave option impact on this? I do not figure out how it might be related to this issue.

[Stefan Niedermann]

Any news here? This is a very painfull issue for us, especially since the "autosave"-option is enabled by default.