sporadic g.doc_id is undefined error in volume/copy creator

[Jason Etheridge]

Appears to be a race condition/mozilla breakage with pushing xulG to sub-interfaces. Can happen from Holdings Maintenance / Item Status when adding items/volumes. Eyeballs welcome.

[Steve Callender (stevecallender)]

Just to add to it. I was able to trigger this by logging into a brand new staff client session, recalling an item in the catalog, going to Actions for this record > Add Volumes and was able to trigger this error. I can't seem to trigger it at will though and I'm not really noticing a pattern right now that will force it to happen.

[Jason Stephenson (jstephenson)]

Set to incomplete pending confirmation in 2.1+ and with the new Xulrunner branch: https://bugs.launchpad.net/evergreen/+bug/942134

[Kathy Lussier (klussier)]

I can confirm that this bug still occurs in 2.2.

[Thomas Berezansky (tsbere)]

I am not positive, but this branch (needs testing!) may fix this issue:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/fix_race_conditions

[Jason Etheridge (phasefx)]

Thomas, this looks very good. The only thing I was able to break was Item Status, Actions for Selected Items->Show Last Few Circulations, on an item with a circ history. The error was TypeError: g.circ is undefined, with subsequent circ summaries giving TypeError: g.circ is null

-- Jason

[Jason Etheridge (phasefx)]

And that was in circ_brief.xul

[Thomas Berezansky (tsbere)]

I have force-pushed a fix for that issue (loop scoping is annoying).

[Ben Shum (bshum)]

We tried running this code for the past week and discovered two issues so far:

1) Editing MARC records (via marc editor and flat text editor) results in a FIXME error "Record not likely updated." even though the record is actually being changed and the next retrieval shows the changed record.

2) Adding volumes/copies were no longer automatically shown once complete; it required a manual reload of holdings maintenance to view new holdings.

[Robert Heller (heller)]

Random data point: Running the 2.3 client using the *native* xulrunner, Version 10.0.12-1.el5_9, on a CentOS 5.9 (32-bit) Linux system, with a T1 link to the server: a whole day *without* this error. Normally the cataloger gets this error numerious times. I don't know is this is luck or what.

[Tim Spindler (tspindler-cwmars)]

We have a report of this happening in our install of 2.3.3.

[Robert Heller (heller)]

As far as I am aware, the bug has crawled back under its rock -- it has been *completely* absent since I set things up to use the 10.0.12 and more recently the 17.0.3 *Linux* versions of xulrunner on our CentOS 5.9 (32-bit) Linux systems. Presently we are using the 2.3.cwmars101 version of the staff client. The bug might still be there, but maybe the newer versions of xulrunner reduce the exposure of the conditions that trigger it. What verison of xulrunner is shipped with the C/W Mars Staff Client installer? I can't tell -- when run under Wine, xulrunner just displays boxes instead of its version number, but given the number of boxes, I am guessing 1.9.x... I wonder if it makes sense to ship a newer version of xulrunner. Note the application.ini file indicates that the max version is 14.*, but the staff client is happy with xulrunner 17.* and according to the developers, even newer versions should work as well (it has appearently been tested with version 19).

[Tim Spindler (tspindler-cwmars)]

Evergreen v. 2.3.4

We have had recent reports of this bug again. Several of our libraries have reported getting this error in the last 3 weeks.

[Andrea Neiman (aneiman)]

As this seems to be entirely associated with XUL, I'm marking this as won't fix.