site-kit-wp: Tag Manager setup/settings blocks user while container data is loading without loading indicator

Bug Description

It takes a long time (10 seconds plus) for Site Kit to recognize a non Site Kit placed GTM snippet and populate the account and container fields with that manually inserted information. While this may be in relation to a lookup of all Tag Manager accounts during the wait users there are a couple of issues:

  1. Users may be uncertain on how to proceed, do they wait or do they exit (there is no loading indicator and the “Confirm and Continue” buttons are greyed out
  2. The pre-populated GTM account and container are not necessarily the correct GTM account and container (this should be addressed once #4209 is has been resolved)
  3. It only changes to the correct pre-populate data after the wait/lookup

https://recordit.co/IW511jun1l

An improvement for this would be for the field to be not pre-populated and ideally a loading indicator would appear.

Steps to reproduce

  1. Insert GTM manually with the code snippet in the head and body of your site
  2. Connect GTM within Site Kit. It takes some time for GTM to populate with the correct GTM already connected, in the meantime showing possibly incorrect data

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

  • The primary loading indicator shown while loading Tag Manager setup or settings-edit views should continue to be shown under the following conditions:
    • The presence of an existing tag is not yet finished resolving
    • An existing tag is present and its permissions check has not finished resolving
  • A new loading indicator should be shown to the right of the container selects in the Tag Manager setup and settings views when the live container version is loading
    • It should use the same type of mini progress bar that is used for the compatibility checks which happen on the splash screen, i.e. next to the disabled CTA button. The small text above it should say:

      Checking tags

    • Only a single loading indicator should be shown for this which should show regardless of which container(s) the version data is being fetched for

Implementation Brief

  • In assets/js/modules/tagmanager/components/setup/SetupMain.js: and assets/js/modules/tagmanager/components/settings/SettingsEdit.js components:
    • Continue showing the progress bar when hasExistingTag and hasExistingTagPermision is undetermined by expanding the logic that sets the ProgressBar as viewComponent. ie. if ( ... || hasExistingTag === undefined || hasExistingTagPermission === undefined ) { ...
  • In assets/js/modules/tagmanager/components/setup/SetupForm.js and assets/js/modules/tagmanager/components/settings/SettingsForm.js:
    • Get the accountID, internalContainerID and internalAMPContainerID using the getAccountID, getInternalContainerID and getInternalAMPContainerID selectors from the MODULES_TAGMANAGER store.
    • Define isResolvingWebGetLiveContainerVersion and isResolvingAMPGetLiveContainerVersion using the isResolving with getLiveContainerVersion as the first argument and array of accountID and internalContainerID / internalAMPContainerID as the second argument of the isResolving selectors respectively. ie.
const isResolvingWebGetLiveContainerVersion = useSelect( ( select ) =>
  select( MODULES_TAGMANAGER ).isResolving( 'getLiveContainerVersion', [
    accountID,
    internalContainerID,
  ] )
);

Test Coverage

  • No changes needed.

QA Brief

QA:Eng

  • Create a Google Tag Manager account manually
  • Open wp-content/themes/twentytwentyone/header.php file. Make sure you’re on the Twenty Twenty One theme. If not add the scripts respectively.
  • Copy the scripts and add it to the <head> and <body> tags respectively
  • Go to the Site Kit settings page and connect/setup Tag Manager
  • Verify the new loading animation with the text Checking tags… along with the small ProgressBar while the container is loading data. Please refer to the screenshot attached in the PR description.
  • Once connected, go the settings connected services and edit the Tag Manager and refresh the page
  • Verify the new loading animation with the text Checking tags… along with the small ProgressBar while the container is loading data. (The loader might be visible only on the first time in the setting page)
  • Verify the same loading behaviour without an existing tag

Changelog entry

  • Update Tag Manager setup and settings edit views with loading indicator while tags are being checked.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 23 (3 by maintainers)

Most upvoted comments

@wpdarren – in this case, because the container it is checking the tags for is known during the initial load (ie it’s initially set via settings), the check may finish before the main loader is done so it appears as though it doesn’t happen, but it just starts earlier. This actually only happens if there is no existing tag because it takes extra time to determine the account ID if there is an existing tag, but if settings are saved it’s already known.

In this case, you should be able to see it by:

  • removing the existing tag
  • saving the settings with a different container
  • restoring the existing tag
  • going back to settings edit

Give that a try and let me know if that does it for you. It’s not entirely required that it’s always seen in all cases. The important thing here is that the user is not blocked from proceeding (disabled submit button) due to these checks which are in progress which weren’t visible before. The submit button can be disabled for various reasons, but this was the only one where everything in the form appeared valid and the submit button could be “stuck” disabled for a second or two without any indication as to why.

@hussain-t regarding the QAB, this issue is not specific to an existing tag case (at least for the “Checking tags” indicator). Tags are checked both for an existing tag but also any time the user chooses a specific container under normal circumstances.

Would you please update the QAB to clarify?

@felixarntz the best placement would be next to the submit button IMO (as with compatibility checks) as it is providing more context as to why the button is disabled. That doesn’t work in both places without more substantial changes so I think putting the progress bar next to the selects is the next best place. We should make it clear though that only one progress bar should be added regardless of which containers are fetching versions (rather than one per container). I’ll update the ACs.

@aaemnnosttv Shouldn’t the small progress bar display on the right of the dropdown instead? That would be closer to how we have on the splash screen for the compatibility checks and IMO would look better. I think the mock you have above is a bit odd as it makes me think this dropdown is an autocomplete that is loading, but what we’re loading here doesn’t really affect the content of that dropdown.

Regarding the ACs, should we finalize the copy as “Checking tags”? That would work for me.

@aaemnnosttv

thoughts on changes to the ACs here? I think we could update it to simply keep the container’s progress bar spinning while tag permissions were being resolved? i.e. adding an another selector for hasFinishedResolution for getTagPermission( containerID )?

Sgtm! I’ve added a note to the ACs.

@felixarntz mostly LGTM, my only suggestion would be to maybe make the messaging more generic (like “Checking configuration/containers”) or have it without a label (just a progress bar). We can probably start on this and finalize the exact wording later though. I’ll add this to the AC so we can move it forward to IB.

@aaemnnosttv Using the mini progress bar like we do in the compatibility checks sounds good to me. I’ve defined this in the ACs. If that looks good to you, let’s move this to IB.

@jamesozzie I’ve noticed this one as well although I’ve never seen it take longer than a few seconds. I can imagine for some users this could take a bit longer and makes for a confusing experience.

@felixarntz I’ve added preliminary ACs but let’s define how the loading state should look as it’s a bit different than other modules where the progress bar would replace the select for example. Here we could maybe add a spinner next to the submit button which is disabled. Alternatively, we could show the mini progress bar with a message similar to the compatibility checks we do during initial set up. Thoughts?