Describe the bug

After logging in with Taskcluster, it always leaves us on a tab https://firefox-ci-tc.services.mozilla.com/ . Even though we want to just redirect back to Treeherder.

Treeherder uses Taskcluster's OAuth third-party authorization flow to obtain TC credentials during login. The OAuth flow is initiated from a popup window to keep the main application window clean.

I have tried many approaches to get login to leave me on the same Treeherder tab where they started, but it always leaves me on the URL above.

To Reproduce

The OAuth request we make:

  GET https://firefox-ci-tc.services.mozilla.com/login/oauth/authorize
    ?client_id=treeherder-localhost-5000-client
    &response_type=code
    &redirect_uri=http://localhost:5000/taskcluster-auth
    &scope=hooks:trigger-hook:*
    &state=<nonce>

Treeherder OAuth Login Flow (LDAP)

Steps

1. Click "Login / Register" in the Treeherder navbar
2. A popup window opens to the Mozilla Auth0 login page
3. Enter your email address (e.g., user@mozilla.com)
4. Click "Continue with LDAP (Internal)"
5. Enter your LDAP password
6. Click "Continue"
7. Complete Duo 2FA — a Touch ID / passkey prompt appears, use your fingerprint to authenticate
8. Auth0 redirects the popup to the Treeherder login callback, which saves your Auth0 credentials
9. The popup automatically navigates to Taskcluster OAuth authorization (firefox-ci-tc.services.mozilla.com)
10. If this is your first time (or consent has expired), the TC third-party consent page appears — click "Allow" to grant Treeherder access to your TC credentials
11. TC redirects back to Treeherder's /taskcluster-auth callback, which exchanges the authorization code for TC credentials and stores them
12. The popup window closes itself
13. The original Treeherder tab detects the login via a storage event and updates the UI to show you as logged in

Result

• The Treeherder navbar shows "Logged in as: user@mozilla.com [Your Name]"
• Both Auth0 and Taskcluster credentials are stored in localStorage
• You can now perform authenticated actions (retrigger jobs, custom actions, etc.)

Known issue

After step 10, Taskcluster's OAuth flow opens an additional tab to the TC dashboard (firefox-ci-tc.services.mozilla.com, showing "Hello, [Name]!") in the main browser window. This tab must be closed manually. A fix has been requested from the Taskcluster team.

Expected behavior

When the user completes the third-party authorization (clicks "Allow" on firefox-ci-tc.services.mozilla.com/third-party?...), TC redirects back to our redirect_uri (/taskcluster-auth). The entire flow should stay contained within the window/tab that initiated it.

Actual behavior

After the user approves the third-party authorization, TC:

1. Redirects the current tab to our redirect_uri (correct)
2. Also opens a new tab to https://firefox-ci-tc.services.mozilla.com/ (the TC dashboard, showing "Hello, [user]!")

This second tab opens in the main browser window (the opener), not in the popup window where the OAuth flow is running. This means even though the OAuth popup closes itself after receiving credentials, the TC dashboard tab remains as a leftover tab in the user's main Treeherder window.

Request

Could one of the following be implemented?

1. Proposed fix below.
2. A parameter to suppress the dashboard tab — e.g., &suppress_dashboard=true or &prompt=consent (similar to OpenID Connect's prompt parameter) that tells TC to only redirect to the redirect_uri without opening the dashboard.
3. Open the dashboard in the same window/tab instead of a new tab — if the dashboard tab is needed, opening it in the current window (via redirect or _self) rather than window.open() / _blank would keep it contained in the popup window.
4. Don't open the dashboard at all for third-party OAuth flows — the dashboard is useful for interactive TC logins, but for third-party OAuth authorization, the calling application handles the post-auth experience via redirect_uri.
   Option 3 seems most aligned with OAuth best practices — the authorization server should redirect to the redirect_uri and not inject additional navigation side effects.

Proposed fix:

One line in Main.jsx — set AUTH_STARTED before opening the login window, matching what
SignInDialog.onAuthStart() does:

      10  import { route } from '../utils/prop-types';                                                 
      11  import { withAuth } from '../utils/Auth';
      12  import isThirdPartyLogin from '../utils/isThirdPartyLogin';                                  
      13 +import { AUTH_STARTED } from '../utils/constants';                                    
      14  import isLoggedInQuery from './isLoggedIn.graphql';
      15  
      16  @withApollo

      92        !sessionStorage.getItem(THIRD_PARTY_DID_AUTO_LOGIN_KEY)                                
      93      ) {
      94        sessionStorage.setItem(THIRD_PARTY_DID_AUTO_LOGIN_KEY, 'true');                        
      95 +      localStorage.setItem(AUTH_STARTED, window.env.UI_LOGIN_STRATEGY_NAMES);         
      96        window.open(`/login/${window.env.UI_LOGIN_STRATEGY_NAMES}`);
      97  
      98        return;

Taskcluster version

• "taskcluster-client-web": "87.1.3" package
• Web UI: 97.0.1

Screenshots

Platform:

• OS: Mac
• Firefox: 148.0 (aarch64)
• Chrome: Version 145.0.7632.160 (Official Build) (arm64)

Additional context

I'm hitting this with using Treeherder's Oauth login and Taskcluster. I was able to improve our side of things a fair bit, but was not able to work around this part from Taskcluster.