Web Staff Client - Sign in screen workstation dropdown loads slowly

Bug #1643698 reported by Terran McCanna
This bug report is a duplicate of:  Bug #1646166: Hatch 2.12 Omnibus. Edit Remove
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Undecided
Unassigned

Bug Description

On the login screen in the 2.11 web client:

The Username and Password fields load immediately, but the Workstation dropdown list does not load for 3 or 4 seconds. If the staff person begins typing in the username and password too soon, whatever they've typed in is cleared out when the workstation list loads, and has to be retyped.

I'm not sure of the best resolution - perhaps the Username & Password fields could be hidden until the Workstation list is available?

Michele Morgan (mmorgan)
Changed in evergreen:
status: New → Confirmed
Revision history for this message
Michele Morgan (mmorgan) wrote :

I have noticed this in testing as well. Entering the username and password, then seeing it blanked each time they login can be a source of frustration for staff users.

Rather than hiding the Username and Password fields until the workstation loads, perhaps keeping them visible, but disabling text entry until the workstation choices load would be an option?

Hiding the fields may give the impression that the login screen takes longer to load than it actually does.

Revision history for this message
Bill Erickson (berick) wrote :

When this happens, does it look like the page is reloading while entering values in the form? Similarly, does it happen during the second login if you login, logout, then immediately log back in?

Revision history for this message
Terran McCanna (tmccanna) wrote :

>>When this happens, does it look like the page is reloading while entering values in the form?<<

Yes

>>Similarly, does it happen during the second login if you login, logout, then immediately log back in?<<

Yes

Revision history for this message
Michele Morgan (mmorgan) wrote :

Hmm, I would answer the first question as No. I don't see any indication that the page is still loading.

Revision history for this message
Terran McCanna (tmccanna) wrote :

It looks like the page is completely loaded at first when I begin typing, but then looks like it reloads the entire page when I'm partway through.

Revision history for this message
Michele Morgan (mmorgan) wrote :

I did a quick screencast of reloading the login page a few times. This is in Chrome, and for testing purposes, the username and password is remembered by the browser. Note that as the workstation info fills in, the username is blanked:

https://www.screencast.com/t/v6xQf1Vcmu

Revision history for this message
Bill Erickson (berick) wrote :

Thanks for the screencast, Michele. I was finally able to reproduce this in Windows. (I don't see it on Linux or Mac). What I see in the logs is a brief pause before the XMLHttpRequest to Hatch finally fails. This step in the page load process is completely different in the new Hatch code, so there's a chance bug #1646166 will resolve this. I'll try to confirm today (unless someone beats me to it).

Revision history for this message
Bill Erickson (berick) wrote :

Confirmed bug #1646166 resolves the issue for me.

I recreated on a Win 10 machine talking to a local VM running master, issue occurred. Installed Hatch branch on VM with Hatch disabled in the browser, issue did not occur. Enabled Hatch, issue still did not occur.

I'll leave the bug as is until others confirm.

Revision history for this message
Michele Morgan (mmorgan) wrote :

I can confirm that the slow-loading of the workstation selector does NOT occur on Kathy Lussier's MassLNC server that's running the Hatch branch.

Revision history for this message
Bill Erickson (berick) wrote :

Thanks, Michele. Marking this as a duplicate of bug #1646166 so we can track when the fix is released.

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.