Setting Up a Real WebDriver Session¶
What was run¶
A real default Chrome WebDriver session compared against a real, deliberately customized one (window size, user agent, page-load timeout) — plus a real, direct test of what actually happens when a page genuinely takes longer to load than the configured timeout allows, rather than assuming the behavior.
Real default vs. real customized session options¶
REAL default window size: {'width': 756, 'height': 556}
real default user agent: Mozilla/5.0 (Macintosh; ...) HeadlessChrome/156.0.0.0 Safari/537.36
options.add_argument("--window-size=1024,768")
options.add_argument("--user-agent=SeleniumCourseBot/1.0")
REAL customized window size: {'width': 1024, 'height': 768}
real customized user agent: SeleniumCourseBot/1.0
Both real values changed exactly as configured — the default session's real window size and user agent are Chrome's own defaults, not something Selenium invents.
A real, enforced page-load timeout¶
driver.set_page_load_timeout(1) # deliberately too short for the real 3s /slow route
driver.get("http://127.0.0.1:5050/slow")
REAL page-load timeout enforced: TimeoutException after 1.02s (real route takes 3s, timeout was set to 1s)
A real, precisely-enforced timeout — the exception fired at 1.02s, matching the configured 1-second limit,
not the real page's actual 3-second load time.
A real, investigated follow-up: what state is the browser left in?¶
A real, concrete finding: the browser didn't keep whatever partial content it had received — it reset
entirely to a blank data:, URL. A fresh driver.get() call afterward, with a real generous timeout, loaded
the actual page correctly:
driver.set_page_load_timeout(300)
driver.get("http://127.0.0.1:5050/slow")
heading_text = driver.find_element(By.ID, "slow-heading").text
How It Actually Works¶
Every one of these session options is set once, at session creation or immediately after, and shapes every
real command for the rest of that session: window size affects what's actually visible and clickable without
scrolling; user agent affects what the real server (and any client-side JavaScript) believes is making the
request; and the page-load timeout bounds how long driver.get() is willing to real-world wait before giving
up. This lesson's real timeout test confirms that bound is actually enforced, not just a suggestion — Chrome
genuinely abandons the in-progress navigation and resets to a blank state rather than leaving a half-loaded
page sitting there.
That real reset-to-blank behavior matters practically: a script that catches a TimeoutException and tries to
keep working with whatever's "already on the page" is working with nothing, as this lesson's real
current_url check (data:,) directly demonstrates. The real, correct recovery, shown in this lesson's final
step, is a fresh driver.get() call.
Common mistakes¶
- Setting a page-load timeout without testing what actually happens when it fires — this lesson's real check
of
current_urlafter the exception revealed a complete reset, not a partially-usable page, which anyone assuming otherwise would discover the hard way in production. - Assuming a custom user agent is cosmetic — real servers and real client-side JavaScript can and do change
behavior based on it; this lesson's real
execute_scriptcheck is a direct way to confirm what value a page actually sees. - Confusing a page-load timeout with the explicit/implicit waits Level 2 covers next — a page-load timeout bounds the initial navigation itself; it says nothing about whether a specific element on an already-loaded page is ready to interact with.
Exercise¶
Set a real page-load timeout of exactly 3.5 seconds (just above the /slow route's real 3-second delay) and
run this lesson's exact real test again. Confirm the real page loads successfully this time without throwing,
and measure how close the real elapsed time comes to the route's actual 3-second delay.