(WebKit) NoAuth page redirection not happening?

[MetRonnie]

On my fork I tested out running the E2E tests on WebKit in GH Actions MacOS, and consistently got this error for
tests/e2e/specs/url.cy.js:

  1) URL handling
       reroutes to noAuth page if user isnt authorised:
     AssertionError: Timed out retrying after 10000ms: expected 'http://localhost:4173/#/' to include 'noAuth'
      at  (http://localhost:4173/__cypress/runner/cypress_runner.js:118172:143)
      at  (http://localhost:4173/__cypress/tests:30:22)
      at  (http://localhost:4173/__cypress/runner/cypress_runner.js:138785:43)
      at callFn (http://localhost:4173/__cypress/runner/cypress_runner.js:157434:25)
      at  (http://localhost:4173/__cypress/runner/cypress_runner.js:157421:13)
      at finallyHandler (http://localhost:4173/__cypress/runner/cypress_runner.js:4072:27)
      at tryCatcher (http://localhost:4173/__cypress/runner/cypress_runner.js:1807:28)
      at  (http://localhost:4173/__cypress/runner/cypress_runner.js:1519:35)
      at  (http://localhost:4173/__cypress/runner/cypress_runner.js:1576:43)
      at  (http://localhost:4173/__cypress/runner/cypress_runner.js:1621:24)
      at  (http://localhost:4173/__cypress/runner/cypress_runner.js:1701:33)
      at _drainQueueStep (http://localhost:4173/__cypress/runner/cypress_runner.js:2407:27)
      at _drainQueue (http://localhost:4173/__cypress/runner/cypress_runner.js:2400:24)
      at  (http://localhost:4173/__cypress/runner/cypress_runner.js:2416:16)
      at  (http://localhost:4173/__cypress/runner/cypress_runner.js:2286:26)

One possibility is just that it's taking longer than other browsers/Ubuntu and the timeout needs to be raised.

[oliver-sanders]

Found this:

https://stackoverflow.com/questions/62223195/vue-router-uncaught-in-promise-error-redirected-from-login-to-via-a

Sounds like there are multiple redirects going on in the same operation. I get the impression this error might also be ocouring in other browsers, but is only surfacing in the WebKit tests due to this snippet I extracted from the traceback:

  // If the runner can communicate, we should setup all events, otherwise just setup the window and fire the load event.
        if (isRunnerAbleToCommunicateWithAUT) {
          if (this.Cypress.isBrowser('webkit')) {
            // WebKit's unhandledrejection event will sometimes not fire within the AUT
            // due to a documented bug: https://bugs.webkit.org/show_bug.cgi?id=187822
            // To ensure that the event will always fire (and always report these
            // unhandled rejections to the user), we patch the AUT's Error constructor
            // to enqueue a no-op microtask when executed, which ensures that the unhandledrejection
            // event handler will be executed if this Error is uncaught.
            const originalError = autWindow.Error;
            autWindow.Error = function __CyWebKitError(...args) {
              autWindow.queueMicrotask(() => {});
              return originalError.apply(this, args);
            };
          }    

If this is the case, avoiding the double redirect would be the best outcome.

[MetRonnie]

I can't think how we would be redirecting more than once

cylc-ui/src/router/index.js

Lines 66 to 95 in 1cbd0c9

	router.beforeEach(async (to, from) => {
	NProgress.start()
	if (!store.state.user.user) {
	try {
	const user = await router.app.config.globalProperties.$userService.getUserProfile()
	store.commit('user/SET_USER', user)
	} catch (err) {
	store.dispatch('setAlert', new Alert(err, 'error'))
	}
	}
	if (!store.state.user.user.permissions.includes('read') && to.name !== 'noAuth') {
	return { name: 'noAuth' }
	}
	})
	router.beforeResolve((to, from) => {
	if (to.name) {
	let title = to.name
	let workflowName = null
	if (to.meta.toolbar) {
	// When a workflow is being displayed, we set the title to a
	// different value.
	title = to.params.workflowName
	workflowName = to.params.workflowName
	}
	store.commit('app/setTitle', title)
	store.commit('workflows/SET_WORKFLOW_NAME', workflowName)
	store.dispatch('setAlert', null)
	}
	})

[oliver-sanders]

Worth jamming some logging in to find out if this is the case.

Also worth looking at the error, it says we are redirecting from / to {} which looks like an error too, could possibly be cause the re-re-direct if it's an invalid page?

There was another error in the console (which may be unrelated): "[Network] undefined"