Login fails with RuntimeError: No locator matched — EMAIL_LOCATORS don't match login page

[matiapa]

Summary

submit_login_form crashes with RuntimeError: No locator matched on <url> while trying to fill the email field on LinkedIn's login page. None of the EMAIL_LOCATORS in linkedin_cli/browser/login.py matched, so resolve_locator (in linkedin_cli/browser/nav.py) exhausted every candidate and raised.

Environment

• Consumed via OpenOutreach (eracle/OpenOutreach), running make run / python manage.py rundaemon
• Platform: Linux aarch64 (Raspberry Pi), Python 3.13.5
• linkedin-agent-cli installed unpinned from PyPI (latest at time of run)

Steps to reproduce

1. Configure a LinkedIn account in OpenOutreach and run make run.
2. Daemon opens the browser, navigates to the login page, and calls authenticate().
3. Crash occurs immediately after "Submitting login form for <email>" is logged.

Full traceback

[INF] Submitting login form for matiglas@hotmail.com
Traceback (most recent call last):
  File "manage.py", line 24, in <module>
    execute_from_command_line(sys.argv)
  File ".../django/core/management/__init__.py", line 443, in execute_from_command_line
    utility.execute()
  File ".../django/core/management/__init__.py", line 437, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File ".../django/core/management/base.py", line 420, in run_from_argv
    self.execute(*args, **cmd_options)
  File ".../django/core/management/base.py", line 464, in execute
    output = self.handle(*args, **options)
  File "openoutreach/core/management/commands/rundaemon.py", line 19, in handle
    self._ensure_newsletter(session)
  File "openoutreach/core/management/commands/rundaemon.py", line 98, in _ensure_newsletter
    profile = session.self_profile
  File ".../functools.py", line 1026, in __get__
    val = self.func(instance)
  File "openoutreach/linkedin/browser/session.py", line 66, in self_profile
    profile = discover_self_profile(self)
  File ".../linkedin_cli/setup/self_profile.py", line 19, in discover_self_profile
    session.ensure_browser()
  File "openoutreach/linkedin/browser/session.py", line 49, in ensure_browser
    start_browser_session(session=self)
  File "openoutreach/linkedin/browser/launch.py", line 45, in start_browser_session
    authenticate(session, username=lp.linkedin_username, password=lp.linkedin_password)
  File ".../linkedin_cli/auth.py", line 94, in authenticate
    auth_flow.run(session)
  File ".../linkedin_cli/page_state.py", line 145, in run
    action(session)
  File ".../linkedin_cli/page_state.py", line 85, in wrapper
    fn(session, *args, **kwargs)
  File ".../linkedin_cli/auth.py", line 67, in _from_login
    submit_login_form(session, session.username, session.password)
  File ".../linkedin_cli/browser/login.py", line 121, in submit_login_form
    human_type(resolve_locator(page, EMAIL_LOCATORS), username)
  File ".../linkedin_cli/browser/nav.py", line 81, in resolve_locator
    raise RuntimeError(f"No locator matched on {page.url}")

Suspected root cause

EMAIL_LOCATORS (linkedin_cli/browser/login.py:25-32) relies on English accessible names for its primary matchers:

EMAIL_LOCATORS = [
    lambda p: p.get_by_role("textbox", name="Email or phone"),
    lambda p: p.get_by_label("Email or phone"),
    lambda p: p.locator('input[autocomplete="webauthn"]'),
    lambda p: p.locator('input[name="session_key"]'),
    lambda p: p.locator('input#username'),
    lambda p: p.locator('form input[type="text"]'),
]

If LinkedIn serves the login page in a non-English locale (e.g. Spanish, based on the account's region), get_by_role/get_by_label won't match on the translated label, and apparently none of the CSS fallbacks matched either in this run — suggesting either a locale-driven DOM/attribute change, or LinkedIn served an interstitial/different login variant that none of the fallbacks anticipated.

Two things that would help narrow this down and make the failure more debuggable:

1. resolve_locator's RuntimeError doesn't capture page HTML/screenshot on failure, so there's no artifact to inspect after the crash — enabling a dump (similar to DUMP_PAGES in nav.py) on locator-resolution failure would make future reports actionable.
2. If the locale hypothesis is right, the login locators need either a locale-agnostic strategy (e.g. matching on id/name/type attributes only, without relying on translated accessible names) or explicit multi-locale label lists.

I don't have a captured screenshot/HTML from this run, but can attempt to repro with DUMP_PAGES=true if useful.

[matiapa]

Root-caused this with a live (unauthenticated, no credentials submitted) reproduction against the real login page. Two independent bugs stack here:

1. The login page's language is IP-geolocated, not client-negotiated.

Tested with a Playwright context from an Argentina-based host:

• Default (no overrides): document.documentElement.lang == "es", form labels are "Email o teléfono" / "Contraseña".
• Forced locale="en-US" + Accept-Language: en-US,en;q=0.9 header + ?geo=us&hl=en query params: still served in Spanish. LinkedIn ignores all client-side language signals for the logged-out login page.
• Setting a lang=v=2&lang=en-us cookie on .linkedin.com (LinkedIn's own site-language override): this works, page renders in English.

So EMAIL_LOCATORS'/PASSWORD_LOCATORS' first two candidates (get_by_role(..., name="Email or phone"), get_by_label("Email or phone")) can legitimately find zero matches on any non-English-geo host, with no code bug involved — it's a page-language problem, not a locator problem, for those two.

2. Even in English, the CSS-attribute fallbacks are stale, and get_by_label can grab a hidden duplicate field.

Current DOM (English, via the cookie above) for the two real inputs:

<input type="email" id="«Refvl3ksopa55j6»" autocomplete="username webauthn" ...>
<input type="password" id="«R2nvl3ksopa55j6»" autocomplete="current-password" ...>

• No name attribute at all → input[name="session_key"] never matches.
• id is a React-generated hash, not username → input#username never matches.
• type="email", not type="text" → form input[type="text"] never matches.
• autocomplete="username webauthn" (two tokens) → the exact-match input[autocomplete="webauthn"] never matches.

So all four CSS fallbacks in EMAIL_LOCATORS are dead weight against the current markup, regardless of language.

Separately, the page renders two copies of the email input sharing one <label> — one hidden (display/visibility hidden, not exposed in the accessibility tree) and one visible:

get_by_label("Email or phone") → 2 matches: [hidden, visible]  (DOM order: hidden first)
get_by_role("textbox", name="Email or phone") → 1 match: [visible]  (a11y-tree-based, skips the hidden one)

resolve_locator's factory(page).first + wait_for(state="visible") means any locator strategy that matches the hidden duplicate before the visible one will time out waiting for visibility that never comes — e.g. get_by_label, or a naive input[type="email"] fallback someone might add later. get_by_role (the actual first candidate today) happens to dodge this because ARIA hides the duplicate from the a11y tree, which is presumably why the reported traceback failed before even reaching get_by_label — candidate 1 found nothing (wrong language), and everything after it either also found nothing (wrong language / stale attrs) or would've hit the hidden-duplicate hang.

Verified fix (end-to-end, using the real installed resolve_locator/EMAIL_LOCATORS/PASSWORD_LOCATORS/SUBMIT_LOCATORS from this package): pre-seeding the browser context with the lang=v=2&lang=en-us cookie before navigating to /login makes all three resolve correctly as-is — candidate 1 (get_by_role) matches on the first try for both email and password, no changes needed to the locator lists themselves.

Suggested upstream improvements:

1. Drop or fix the 4 stale CSS-attribute fallbacks in EMAIL_LOCATORS/PASSWORD_LOCATORS (name="session_key", #username, input[type="text"], exact autocomplete="webauthn") — they no longer match current LinkedIn markup and give false confidence.
2. Since get_by_role/get_by_label-based candidates only work when the page is served in English, consider either (a) documenting that callers must ensure an English-language session (e.g. via the lang cookie) before calling authenticate(), or (b) making the login locators language-agnostic (attribute/structure-based) so the library works regardless of the host's geolocation.
3. resolve_locator picking .first in raw DOM order (rather than first visible match) is a latent trap for any locator that can match a hidden duplicate — worth a locator.filter(visible=True) guard or equivalent, independent of this specific bug.

We've worked around this on the OpenOutreach side by injecting the lang cookie before first login (doesn't require any linkedin_cli changes), but flagging here since it'll bite any consumer running from a non-English-geo host.