Make Evergreen resilient in the face of Chrome's prefetching and prerendering

Bug #2044033 reported by Galen Charlton
120
This bug affects 26 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Undecided
Unassigned

Bug Description

Discussion on the Evergreen mailing list [1] suggests that the Chrome prerendering feature [2] can result in users getting blank/white screens when loading the staff interface, especially (?) or only if (?) Hatch is installed.

As noted by John Amundson, when that happens, the following console message is observed when the page hangs:

sending to Hatch:
{"key":"eg.workstation.all","action":"get","msgid":1}

This has been observed in (at least) Evergreen 3.7, 3.9, and 3.11.

As noted by Garry Collum and confirmed by others, turning off Chrome prerendering by turning off the "Preload pages" setting has brought relief.

However, it would be worthwhile to track this down further so that Evergreen (+ Hatch) can function regardless of the state of the prerendering setting and to identify what can (or cannot) be prerendered safely [3]. Like it or not, documenting instructions to turn off what, from the point of view of most users, is an obscure setting, will not be an adequate user experience in the long run.

[1] http://list.evergreen-ils.org/pipermail/evergreen-general/2023-November/002251.html
[2] https://developer.chrome.com/blog/prerender-pages/
[3] https://docs.google.com/document/d/1_9XkDUKMGf2f3tDt1gvQQjfliNLpGyFf36BB1-NUZ98/edit#heading=h.ukrmtvqhutp7

Revision history for this message
Galen Charlton (gmc) wrote :

Thus far, it looks like one way to cut the Gordian knot would be to have the server respond to all requests (to just the staff interface?) that include "prerender" in the Sec-Purpose header with an error code. Not, of course, what Google prefers - but needs must.

There's an argument to be made that prerendering could be helpful to speed up loading the Evergreen staff interface, but I have a feeling that it may take a fair amount of effort to have that work smoothly in all configurations.

tags: added: hatch performance
Revision history for this message
Diane Disbro (ddisbro) wrote (last edit ):

Evergreen 3.9
Hatch enabled
Chrome browser
Staff at my library continue to experience white screen after disabling Chrome Preload, though the occurrence is less frequent (at last report!).

description: updated
Revision history for this message
Terri (terrim) wrote :

We are still experiencing this white screen issue. FREQUENTLY:)

Revision history for this message
corina thorne (cplstaff) wrote :

We are still experiencing the white screen and slowness, here at Carrollton Public Library.

Revision history for this message
Jessica Woolford (jwoolford) wrote :

Marking as confirmed based on comments and reports from libraries.

Changed in evergreen:
status: New → Confirmed
Revision history for this message
April Gore (drclstaff) wrote :

Doniphan - ipley County Library has been experiencing white screens, slow and buffering regularly for the last 2 weeks.

Revision history for this message
Jeff Godin (jgodin) wrote :

Last week, testing here on Windows 10 with Hatch and Chrome and Evergreen 3.10 and 3.11 had shown that Chrome 118, 120, and 121 were not exhibiting the issue.

Only Chrome 119 was affected (again, in our testing).

We WERE able to reproduce on Chrome 119 versions as high as 119.0.6045.160, which is current stable.

Today, I am unable to reproduce on this version.

Previously, the problem could be reliably reproduced by enabling the Bookmarks Bar, adding some bookmarks to the Evergreen staff client, and using those links. The first attempt usually failed with a partially-loaded page lacking the username and workstation in the upper right, and a "reload" resolved the symptoms.

With Chrome 119, turning off "Preload pages" resolved the issue for us, and using the Group Policy and/or cloud-managed Chrome policies to turn off Chrome's network prediction behaviors was beneficial.

During our previous testing, we did not disable Chrome variations / field trials.

Since we are unable to reproduce today, I suspect that at least some of the symptoms may be related to Chrome variations / field trials.

For anyone currently experiencing the problem that is solved by disabling "Preload pages", could you please share your Evergreen version, steps to reproduce, as well as the output of the following chrome:// URL?

chrome://version/?show-variations-cmd

Thanks!

Revision history for this message
Jeff Godin (jgodin) wrote :

By examining chrome://version/?show-variations-cmd on a Chrome instance that was known to be recently impacted by this, I was able to identify a likely variation / field trial.

Launching Chrome with the following flags (and with "Preload pages" not otherwise disabled) greatly helps in the effort to reproduce. Tested on Windows 10 with Chrome 119.0.6045.160 against Evergreen 3.11.

"C:\Program Files\Google\Chrome\Application\chrome.exe" --force-fieldtrials="*Prerender2BookmarkBarTrigger/Default/" --force-fieldtrial-params="Prerender2BookmarkBarTrigger.BothMouseDownAndMouseHover_20231102:prerender_bookmarkbar_on_mouse_hover_trigger/true/prerender_bookmarkbar_on_mouse_pressed_trigger/true/prerender_start_delay_on_mouse_hover_ms/300" --enable-features="BookmarkTriggerForPrerender2<Prerender2BookmarkBarTrigger"

Further testing shows that only the --enable-features part may be required to reproduce with 119.0.6045.160:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --enable-features="BookmarkTriggerForPrerender2<Prerender2BookmarkBarTrigger"

With this command line, I am able to reproduce the problem (or possibly a slight variation of it) on Chrome 118.0.5993.144 (extended stable).

So far, I have been unable to reproduce the issue with Chrome 120 (beta) or Chrome 121 (dev). I don't know if I should find that encouraging or not. Absent a clear bug report and test case to confirm, we should probably not assume that the issue is a bug that has already been fixed. :-(

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.