[OPEN-ILS-GENERAL] Webbies all the way down

[Jeff Godin]

On Thu, Jun 6, 2019 at 2:45 PM Durrence, April <april.durrence at ncdcr.gov>
wrote:

> Hi all,
>
>
>
> This morning, we have had a rash of reports from multiple library systems
> within the consortium of problems that replicate the ones reported in these
> bugs:
>
>
>
> https://bugs.launchpad.net/evergreen/+bug/1708951
>
> https://bugs.launchpad.net/evergreen/+bug/1731305
> https://bugs.launchpad.net/evergreen/+bug/1797923
> https://bugs.launchpad.net/evergreen/+bug/1731272
> https://bugs.launchpad.net/evergreen/+bug/1724348
>
>
>
> None of the libraries report making changes to the default view and most
> seem to have Chrome version 74 (v.74.0.3729.167) or 75 (v.75.0.3770.80).
>
>
>
> We have tried this experiment that did not work:
>
> -Clear the cache
> -Log back into Webby
> -Choose a catalog search
> -Click “set default view” once the catalog search screen is up (working
> properly the first time)
>
>
>
> Anyone else having this issue today or have any potential
> solutions/experiments/workarounds for us to try to resolve for frustrated
> front-line staff?
>

April-

We encountered something that sounds like what you describe starting
yesterday, and shared some of our experiences on IRC starting here:
http://irc.evergreen-ils.org/evergreen/2019-06-05#i_408546

It's not necessary to read the entire conversation there, but feel free.
I'll summarize here:

Chrome 75.0.3770.80 introduced a race condition where loading content in an
iframe could fail in a way that in Evergreen results in this nested iframe
where the actual desired content does not load, or rarely loads.

There are two Chrome issues documenting the issue and the Chrome team's
handling of it, but nothing in the way of a quick fix can be found there. I
suggest that interested parties star one or both issues to keep tabs on
their progress, while implementing a workaround (see below).

Most of the discussion is in the second issue here:

https://bugs.chromium.org/p/chromium/issues/detail?id=971368
https://bugs.chromium.org/p/chromium/issues/detail?id=971641

The problem has already been fixed in the Chrome codebase, but the version
which includes the fix has not yet been released to the stable channel.

There is some discussion in the issue above about pausing the rollout of
Chrome 75.0.3770.80 and/or backporting a fix to release a new version of
Chrome 75. I didn't see any conclusions there yet.

In the meantime, we found that the issue was resolved on Evergreen systems
where we had deployed the changes in Evergreen bug 1797923, "Browser client
iframe (catalog, etc.) loading page":
https://bugs.launchpad.net/evergreen/+bug/1797923

This change should already be present in Evergreen 3.1.7 and up, Evergreen
3.2.1 and up, and Evergreen 3.3.

We found the problem was no longer reproducible on systems where we had the
loading screen changes in place.

Chrome 75 also introduces support for a new loading="eager" iframe element,
which we put in place as part of our testing and left in place, though it
seems likely that this is not strictly required to work around the Chrome
bug.

Hopefully this information is useful to you and others!

-jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20190606/3ccefd96/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 8625 bytes
Desc: not available
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20190606/3ccefd96/attachment-0001.png>