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

Bug #787561 reported by Jason Etheridge on 2011-05-24
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

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.

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
Changed in evergreen:
assignee: Jason Etheridge (phasefx) → nobody

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) wrote :

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

Changed in evergreen:
status: New → Incomplete
Kathy Lussier (klussier) wrote :

I can confirm that this bug still occurs in 2.2.

Changed in evergreen:
status: Incomplete → Confirmed
Thomas Berezansky (tsbere) wrote :
Jason Etheridge (phasefx) wrote :

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) wrote :

And that was in circ_brief.xul

Thomas Berezansky (tsbere) wrote :

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

Ben Shum (bshum) wrote :

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.

no longer affects: evergreen/2.1
Changed in evergreen:
status: Confirmed → Triaged
Robert Heller (heller) wrote :

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.

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

Robert Heller (heller) wrote :

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).

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.

Ben Shum (bshum) on 2013-08-22
no longer affects: evergreen/2.2
no longer affects: evergreen/2.3
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers