updated the DOM element selector for the new freedom site

[MikolajKawalec]

No description provided.

[Copilot]

Pull request overview

This pull request updates the login automation to handle changes in the Freedom website's DOM structure. The site now opens login in a new browser tab rather than on the same page, requiring additional window handling logic.

Changes:

• Changed login button selector from By.LINK_TEXT to By.CSS_SELECTOR with class a.nav_link-login
• Added logic to switch to the new login tab that opens when clicking the login button

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Booza1981]

Code Review

Verdict: Approve with minor suggestions — this is a targeted, sensible fix for a real DOM change on freedom.to (login now opens a new tab).

Looks good

• The selector change (By.LINK_TEXT → By.CSS_SELECTOR a.nav_link-login) is the right move — the site's nav structure changed and a class-based selector is more stable than text matching.
• Tab switching (switch_to.window(window_handles[-1])) correctly targets the newest tab, and the existing WebDriverWait for #session_email still guards the credential entry on the new tab. Good reuse of existing flow.

Suggestions (non-blocking)

1. Race on tab open — time.sleep(1) is a fixed wait. If the new tab takes >1s, window_handles may still list only one handle and [-1] would point at the original page, causing a NoSuchWindowException. Consider WebDriverWait(self.driver, 10).until(EC.number_of_windows_to_be(2)) before switching.
2. No fallback if the site reverts — if freedom.to ever returns to same-tab login, this PR would switch to a bogus handle. A check that the new tab actually contains the login form (#session_email) before committing would make it robust.
3. Verify the post-login check — after switching tabs and logging in, the dashboard check (blocklist-checklist) runs on the login tab. Confirm the dashboard loads there (not back on the original tab) before closing the PR; if it redirects back, a switch is needed post-login.

Note

This has been open since Feb 2026 and Copilot already reviewed it (COMMENTED). The change is low-risk and confined to the login function. Recommend merging once the author confirms the dashboard check passes on the switched tab.

[Booza1981]

Verdict: Comment

Looks good

• The selector change is a genuine fix: By.LINK_TEXT, "Log In" was the only remaining LINK_TEXT lookup in the file (grep confirms), and the new a.nav_link-login CSS selector targets the redesigned site. The new-tab handling (switch_to.window(window_handles[-1])) is the right pattern for a login flow that opens a fresh tab, and it is placed before the credential-filling waits, so the WebDriverWait calls operate on the correct context.

Issues

• No wait after the tab switch. The switch happens immediately after click() + time.sleep(1). If the new tab is slow to open, window_handles[-1] may still be the original tab (or the handle list may not yet include the new tab), and the subsequent WebDriverWait(..., 10) for session_email would then time out against the wrong page. Recommend waiting for the expected window count first, e.g. WebDriverWait(self.driver, 10).until(lambda d: len(d.window_handles) > 1) before switching. This is the most likely flake point.
• No verification that the new tab is the login page. If the site ever opens a different tab (e.g. a marketing page), the script will fail confusingly. A cheap guard: after switching, assert the URL contains login (or wait for session_email with a longer timeout).

Suggestions (non-blocking)

• The time.sleep(1) after the click is a magic number; the window-count wait above would make it unnecessary.
• Consider closing the original tab after login (self.driver.close() + switch back) so the session runs in a single tab — not required, but keeps later window_handles[-1] assumptions predictable.

Note

• PR is ~6 months old (Feb 2026), from external contributor MikolajKawalec, no prior reviews, no CI in the repo. Mergeable. The change is small and directionally correct; the tab-switch race is worth addressing before merge, or accept it as a best-effort fix for a personal automation script. Not a blocker for a personal tool, but I would not merge without at least the window-count wait.