Hani/ Fix test_multiple_saved_logins.py on Linux

[sv-hyacoub]

Relevant Links

Bugzilla: 2052308

Description of Code / Doc Changes

• Fix Fix tests/password_manager/test_multiple_saved_logins.py on Linux

Process Changes Required

Mark the relevant boxes, delete irrelevant lines.

• Adds a dependency (rerun uv sync)
• Modifies a git hook (rerun ./devsetup.sh)
• Changes the BasePage
• Changes or creates a BOM/POM (name the object model): _
• Changes CI flow
• Changes scheduled Beta / DevEdition / RC
• Changes Autofill L10n harness

Screenshots or Explanations

N/A

Comments or Future Work

N/A

Workflow Checklist

• Reviewers have been requested.
• Code has been linted and formatted.
• If this is an unblocker, a message has been posted to #dte-automation in Slack.

Thank you!

[github-actions]

The fix is correct and minimal — allowing pyautogui on Linux when a display is available fixes gui_sequence for headed tests.

One thing worth noting: on modern Linux systems using Wayland, DISPLAY may not be set even when a display exists (the relevant variable would be WAYLAND_DISPLAY). If CI or developer machines ever use Wayland, the condition could be extended to:

if sysname == "Linux" and not os.environ.get("DISPLAY") and not os.environ.get("WAYLAND_DISPLAY"):

Not blocking, just something to keep in mind if this surfaces on Wayland setups.

[github-actions]

Overall: Good, targeted fix. The change to conditionally load pyautogui on Linux only when DISPLAY is absent is the right approach for Xvfb-based headed CI runs.

Two notes:

1. _get_gui_auto caching bug (pre-existing): When _make_gui_auto returns None (no display), _gui_auto stays None, so every call to _get_gui_auto will repeatedly call _make_gui_auto instead of short-circuiting. Worth fixing separately with a sentinel value.

2. Wayland (low priority): The DISPLAY check only covers X11/XWayland. If the environment ever moves to native Wayland (WAYLAND_DISPLAY set, no DISPLAY), pyautogui would be imported but fail at runtime since it lacks Wayland support. Currently not an issue as pyautogui requires X11 anyway, but worth a comment.

[github-actions]

Review

The fix is logically sound — previously, _make_gui_auto returned None unconditionally for all Linux, even when a display server was available. The new condition correctly limits that to headless Linux only.

One concern: Wayland compatibility

When WAYLAND_DISPLAY is set but DISPLAY is not (pure Wayland, no XWayland), pyautogui will be imported but its mouse/keyboard operations may fail at runtime since pyautogui has limited native Wayland support. This could produce obscure errors at the call sites (self.gui.press, self.gui.moveTo, etc.) rather than a clean None check.

Worth confirming that the CI Linux environment runs with XWayland (i.e., DISPLAY is also set), or that pyautogui operations are verified to work in that environment.

Pre-existing minor issue (not introduced here): The _get_gui_auto caching doesn't work when _make_gui_auto returns None — _gui_auto stays None so the factory is called on every BasePage.__init__. Low impact but worth noting.

Manifest change looks appropriate.

[github-actions]

When running on pure Wayland (WAYLAND_DISPLAY set, DISPLAY unset), pyautogui will be imported here but its underlying X11-based operations may fail at runtime. If CI uses Wayland without XWayland, calls like self.gui.press() / self.gui.moveTo() could raise errors instead of gracefully skipping.

Consider whether you also need to verify that at least DISPLAY is set (XWayland present) before enabling pyautogui on Wayland, or add a try/except around the import to handle environments where pyautogui loads but can't operate.

[ben-c-at-moz]

I'm actually extremely surprised this works. Let's talk about it tomorrow...I was sure we were not able to use any amount of PyAutoGUI on Wayland at the moment.