[OPEN-ILS-DEV] bug in 1.6 client if very long 856?

[Dan Scott]

On Fri, May 06, 2011 at 11:00:19AM -0300, Melissa Belvadi wrote:
> 
> Hello, all. 
> We've run into an error in the staff client  (both Mac and PC versions)
> in 1.6.0.4. 
> 
> We checked with Equinox and they agree that the problem is likely to be
> some kind of internal limit on how long an 856 $u URL can be, since we
> only see the problem when editing records with long ones.  We're not
> sure what the limit actually is, but the sample below apparently
> surpasses it. Maybe we're wrong about the issue being length - maybe it
> is something to do with the punctuation used in the URL, but if so, I
> can't isolate the problem, and either way we need it fixed because these
> are legitimate URLs that we need in our records. 

I can't think of any reason why there would be a limit on the length of
the URLs; that makes no sense to me. See below for a pertinent question
though.
 
> There are actually two bugs - the one that causes the error in the
> first place, and another one where the window containing the error
> message itself is so long that it runs off the screen at the bottom, so
> that we can't get to the window control checkbox/buttons to close the
> error message. So once we get this error, the only thing we can do is
> force-quit the entire EG staff client via the operating system (again,
> both PCs and Macs). 

Hmm. You should be able to hit "Tab" to move the cursor to the
"Acknowledge that you've seen this network error dialogue" checkbox,
then "Space" to put a check in it, then "Enter" (or possibly hit "Tab"
twice, then "Space", then "Enter" - I can't remember exactly which
combination of key commands) even though the controls are off-screen.

At some point I added a maximum length to a dialogue like that to
attempt to prevent it from flowing off-screen; but perhaps it's a
different dialogue that you're seeing, or perhaps my change was
reverted. Ideally we would wrap the error message inside its own box
with scrolling enabled, and have the Ack/OK/Try Again buttons outside of
it.

As to the 856 issue - does your $u subfield really contain two copies of
the URL, like "http://url (http://url)", as the snippet below shows?
This would be unexpected, contrary to spec, and certainly could trip up
naive code that is expecting to just have a URL in the $u subfield. Our
code should be more defensive and not throw a horrible error, but I
strongly suspect the problem is with the second copy of the URL in
brackets in your $u.

> <subfield 
> code=\"u\">http://rlproxy.upei.ca/login?url=http://search.ebscohost.com/login.aspx?direct=true&amp;db=lah&amp;bquery=(((CO+(%22small+animal%22+AND+%22north+american+veterinary+conference%22+AND+%22proceedings%22)))+NOT+(AN+20063121210))&amp;cli0=PY&amp;clv0=200601-200612&amp;type=1&amp;site=ehost-live
> (
> http://rlproxy.upei.ca/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=lah&bquery=(((CO+(%22small+animal%22+AND+%22north+american+veterinary+conference%22+AND+%22proceedings%22)))+NOT+(AN+20063121210))&cli0=PY&clv0=200601-200612&type=1&site=ehost-live
> ) 
> ( 
> http://rlproxy.upei.ca/login?url=http://search.ebscohost.com/login.aspx?direct=true&db=lah&bquery=(((CO+(%22small+animal%22+AND+%22north+american+veterinary+conference%22+AND+%22proceedings%22)))+NOT+(AN+20063121210))&cli0=PY&clv0=200601-200612&type=1&site=ehost-live
> 
> )</subfield>