Funky progress bar behavior on View Holds screen

Bug #1717007 reported by Kathy Lussier
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

Evergreen version: 2.12.5 and 3.0beta

The progress bar on the bib record page's View Holds tab will hang in the following situations:

1. When there are holds on the record, but no holds that fall within the context OU pickup library location. If you then click to expand the list to the Consortium, the holds will be successfully retrieved.

2. If you select a hold, click Detail View, and then click to return to List View, the progress bar will hang.

In both cases, I see the following in the Console -

A screencast showing this behavior is available at

Kathy Lussier (klussier)
description: updated
Bill Erickson (berick)
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
status: New → Confirmed
Revision history for this message
Bill Erickson (berick) wrote :

Progress bar fix pushed:;a=shortlog;h=refs/heads/user/berick/lp1717007-funky-hold-progress

This commit makes the progress dialog smarter about resolving multiple simultaneous open calls. Specifically, it plugs up a race condition that allowed multiple modal instances to be open with only one of them getting closed.


Note, however, this only fixes the dialog quirk. The source of the problem noted in this bug is that the holds-for-record grid is rendered twice in quick succession when navigating back from the detail view.

I experimented with disabling the eg-org-selector onchange handler to see if that was the cause (based on bug #1685356), but in this case the onchange is firing in the midst of an active grid refresh (the 2nd one), so it's essentially ignored, because the grid only allows one active refresh at a time.

More research is needed here, since rendering the grid twice could be problematic in other ways. I have a vague memory of this being discussed in another bug, but can't find it now.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.0.0
Revision history for this message
Bill Erickson (berick) wrote :

Adding pullrequest for egProgressDialog fixes, since they'll be good to have regardless.

Galen Charlton (gmc)
Changed in evergreen:
milestone: 3.0.0 → 3.0.1
Revision history for this message
Cesar V (cesardv) wrote :

Worked for me Bill, thanks. Though, I wasn't quite experiencing noticeably stuck progress bars as of late, this patch makes their occurrence less of a problem. I suspect the degree to which the progress bar modal acts weird correlates to how much data loading is taking place in the background initialization of other tabs, for that bib record. In any case, signoff branch here:;a=shortlog;h=refs/heads/user/cesardv/berick_lp1717007-funky-hold-progress_signoff

Bill Erickson (berick)
tags: added: signedoff
Revision history for this message
Galen Charlton (gmc) wrote :

Works for me. Thanks, Bill and Cesar!

Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
assignee: Galen Charlton (gmc) → nobody
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers