Browser Contexts: Isolated Sessions

Browser contexts solve a fundamental challenge you faced in Selenium: testing multi-user scenarios without the resource overhead and complexity of launching separate browser instances. In Selenium, when you needed to test how an admin and regular user see different data simultaneously, you either launched multiple WebDriver instances or carefully managed cookie clearing between test steps. Both approaches created maintenance overhead and timing complexity.

Think of a browser context as a completely isolated user session that believes it's the only user of the browser. Each context maintains its own authentication state, cookies, localStorage, sessionStorage, and even network cache. Yet all contexts share the same browser engine, dramatically reducing memory usage compared to multiple browser instances while providing perfect isolation for testing complex user interaction scenarios.

A single browser instance typically consumes 50-100MB of base memory, while each additional context adds only 5-10MB. This efficiency enables testing scenarios with dozens of simultaneous user sessions that would be prohibitively expensive with separate browser instances. However, contexts aren't free - each maintains its own JavaScript execution environment and network state, so plan for reasonable limits based on your test infrastructure.

Context Configuration for Realistic Testing

Context configuration enables testing scenarios that would require separate devices or network setups in traditional approaches. You can simulate mobile users, different geographic locations, various network conditions, or specific browser permissions within the same test execution. This configuration power transforms contexts from simple isolation containers into comprehensive environment simulation tools. You can find the code examples used in this lesson in the 05-playwright-context-management solution folder of our test repository.

[Test]
public async Task TestAcrossMultipleUserEnvironments()
{
    var browser = await Playwright.Chromium.LaunchAsync();

    // Desktop admin user
    var desktopAdmin = await browser.NewContextAsync(new()
    {
        ViewportSize = new() { Width = 1920, Height = 1080 },
        UserAgent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0"
    });

    // Mobile user with different location
    var mobileUser = await browser.NewContextAsync(new()
    {
        ViewportSize = new() { Width = 375, Height = 667 }, // iPhone SE dimensions
        UserAgent = "Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) Safari/604.1",
        Geolocation = new() { Latitude = 37.7749f, Longitude = -122.4194f } // San Francisco
    });

    // Test how the same application behaves across different environments
    var adminPage = await desktopAdmin.NewPageAsync();
    var mobilePage = await mobileUser.NewPageAsync();

    await Task.WhenAll(
        adminPage.GotoAsync("https://www.saucedemo.com/"),
        mobilePage.GotoAsync("https://www.saucedemo.com/")
    );

    // Verify responsive design works correctly
    var adminProducts = new ProductsPage(adminPage);
    var mobileProducts = new ProductsPage(mobilePage);

    // Both should see products, but layout might differ
    await adminProducts.ShouldBeDisplayedAsync();
    await mobileProducts.ShouldBeDisplayedAsync();

    // Mobile might have different interaction patterns
    // (This would be app-specific - SauceDemo doesn't actually differ)

    await browser.CloseAsync();
}

Context isolation fundamentally changes how you approach testing complex user scenarios. Instead of building elaborate test data setup and teardown procedures to simulate different user states, you create authentic user sessions that behave exactly like real browser usage while maintaining perfect separation for reliable test results.

Managing Multiple Tabs and Windows

Your Selenium experience with multiple windows involved a reactive pattern that created race conditions and timing issues. You performed an action that might open a new window, then immediately started polling the window handles collection, hoping the new window had appeared and fully loaded before your search timed out. This approach required complex coordination between window switching, timing management, and state verification that made multi-window testing fragile and difficult to maintain.

Playwright transforms this reactive complexity into a proactive, declarative pattern that eliminates timing issues while integrating seamlessly with the Page Object architecture you've been building. Instead of hunting for windows after they appear, you declare your intent to capture new pages before triggering the actions that create them. This approach prevents race conditions while providing immediate access to strongly-typed Page Objects that represent the new windows.

The Strategic Value of Multi-Tab Testing

Before diving into implementation mechanics, understanding when multi-tab scenarios provide genuine testing value helps you make architectural decisions about when this complexity is justified. Multi-tab testing becomes valuable when you need to verify how applications handle concurrent user sessions, test information comparison workflows that real users perform across multiple windows, or validate that application state remains consistent when users navigate through different entry points simultaneously.

Common scenarios where multi-tab testing provides business value include comparing product details across multiple items before making purchase decisions, verifying that help documentation opens correctly without disrupting checkout workflows, and testing that external links maintain proper authentication context when users return to the original application window.

Event-Driven Page Management in Practice

The event-driven pattern requires understanding the relationship between your intent declaration, the action that triggers page creation, and the Page Object instantiation that makes the new window accessible within your test architecture. This pattern works by setting up an event listener that captures the page creation event the moment it occurs, eliminating the timing window where traditional polling approaches might miss the new window or attempt to interact with it before it's fully ready.

The Internet Herokuapp provides an excellent example for demonstrating multi-window management in a controlled environment. This site's "Multiple Windows" page specifically tests the window handling capabilities that were challenging in Selenium but become straightforward with Playwright's event-driven approach.

// Integrating multi-tab workflows with Page Object patterns
public class MultipleWindowsPage
{
    private readonly IPage _page;

    public ILocator ClickHereLink { get; }
    public ILocator PageTitle { get; }

    public MultipleWindowsPage(IPage page)
    {
        _page = page;
        ClickHereLink = _page.GetByText("Click Here");
        PageTitle = _page.Locator("h3");
    }

    public async Task NavigateAsync()
    {
        await _page.GotoAsync("https://the-internet.herokuapp.com/windows");
    }

    public async Task<NewWindowPage> OpenNewWindowAsync()
    {
        // Set up listener before triggering the action that opens new window
        var newPageTask = _page.Context.WaitForPageAsync();

        // Click the link that opens a new window
        await ClickHereLink.ClickAsync();

        // Capture the new window when it appears
        var newPage = await newPageTask;
        await newPage.WaitForLoadStateAsync();

        // Return Page Object representing the new window
        return new NewWindowPage(newPage);
    }

    public async Task VerifyOriginalPageTitleAsync()
    {
        // Verify original page remains accessible without window switching
        await Assertions.Expect(PageTitle).ToHaveTextAsync("Opening a new window");
    }
}

public class NewWindowPage
{
    private readonly IPage _page;

    public ILocator PageTitle { get; }
    public ILocator PageContent { get; }

    public NewWindowPage(IPage page)
    {
        _page = page;
        PageTitle = _page.Locator("h3");
        PageContent = _page.Locator("body");
    }

    public async Task VerifyNewWindowContentAsync()
    {
        await Assertions.Expect(PageTitle).ToHaveTextAsync("New Window");
        await Assertions.Expect(PageContent).ToContainTextAsync("New Window");
    }

    public async Task CloseAsync()
    {
        await _page.CloseAsync();
    }

    public async Task<string> GetWindowTitleAsync()
    {
        return await _page.TitleAsync();
    }
}

// Test demonstrating multi-window workflow
public class MultipleWindowsTests : PageTest
{
    [Test]
    public async Task DemonstrateMultiWindowWorkflow()
    {
        // Navigate to the multiple windows test page
        var windowsPage = new MultipleWindowsPage(Page);
        await windowsPage.NavigateAsync();

        // Verify we start on the correct page
        await windowsPage.VerifyOriginalPageTitleAsync();

        // Open new window using event-driven pattern
        var newWindow = await windowsPage.OpenNewWindowAsync();

        // Verify the new window opened with correct content
        await newWindow.VerifyNewWindowContentAsync();
        var newWindowTitle = await newWindow.GetWindowTitleAsync();
        TestContext.WriteLine($"New window title: {newWindowTitle}");

        // Verify original window remains accessible without switching
        await windowsPage.VerifyOriginalPageTitleAsync();
        TestContext.WriteLine("Original window remains accessible");

        // Compare content between windows
        var originalTitle = await Page.TitleAsync();
        Assert.That(originalTitle, Is.Not.EqualTo(newWindowTitle),
            "Windows should have different titles");

        // Perform actions in new window
        await newWindow.VerifyNewWindowContentAsync();

        // Return to original window for additional testing
        // (No explicit switching needed - original page object still works)
        await windowsPage.VerifyOriginalPageTitleAsync();

        // Clean up the new window
        await newWindow.CloseAsync();

        // Verify original window still functions after cleanup
        await windowsPage.VerifyOriginalPageTitleAsync();
        TestContext.WriteLine("Multi-window workflow completed successfully");
    }
}

This example demonstrates several key advantages of Playwright's approach over Selenium's window handle iteration. The event listener captures the new window immediately when it appears, eliminating the timing window where traditional polling might fail. The original page object remains fully functional without requiring explicit window switching or focus management. Most importantly, each window gets its own strongly-typed Page Object that encapsulates the appropriate locators and behaviors for that specific window context.

The pattern also handles edge cases automatically. If the new window fails to open due to popup blockers or other browser restrictions, the WaitForPageAsync() task will timeout with a clear error message rather than leaving your test in an ambiguous state. This built-in error handling eliminates the defensive programming that characterized robust Selenium window management.

Resource Management and Cleanup Patterns

While Playwright handles most page lifecycle management automatically, explicit cleanup of additional tabs prevents memory accumulation in long-running test suites and ensures consistent performance across test executions. Each IPage object maintains browser resources and JavaScript execution contexts, so developing consistent cleanup patterns becomes important as you build more sophisticated multi-window test scenarios.

// Proper resource management for multi-tab scenarios
public async Task<T> WithNewTabAsync<T>(Func<IPage, Task<T>> tabOperation)
{
    // Generic helper method for clean tab management
    var newPageTask = _page.Context.WaitForPageAsync();

    // Trigger the action that opens the new tab
    // (This would be parameterized based on specific needs)

    var newPage = await newPageTask;
    await newPage.WaitForLoadStateAsync();

    try
    {
        // Execute the tab-specific operation
        return await tabOperation(newPage);
    }
    finally
    {
        // Ensure cleanup happens even if operation fails
        await newPage.CloseAsync();
    }
}

The event-driven page management pattern eliminates the race conditions and window handle complexity that made multi-window testing challenging in Selenium while providing immediate access to strongly-typed Page Objects that integrate naturally with the architectural patterns you've been building throughout this course. This approach transforms previously complex automation scenarios into straightforward workflows that express clear business intent.

Working with Frames and Iframes

Iframes represent one of the most challenging aspects of web automation because they create deliberate isolation boundaries within web pages. Understanding why these boundaries exist helps you appreciate the automation challenges they create and the elegance of Playwright's solution.

When web applications embed content from different domains or need to isolate untrusted content for security reasons, they use iframes to create separate document contexts within the main page. Each iframe maintains its own DOM tree, JavaScript execution context, and security boundaries. This isolation protects the main page from potentially malicious iframe content, but it also means that your automation code cannot directly access elements inside iframes using standard page locators.

Your Selenium experience involved switching the WebDriver's global context to the iframe, performing actions within that frame context, then explicitly switching back to the default content. This context switching approach created several maintenance challenges: you needed to track your current context location, handle cases where frame switching failed due to timing issues, and ensure that you always returned to the correct context after iframe operations completed.

FrameLocator: Eliminating Context Switching Complexity

Playwright's FrameLocator concept transforms iframe interaction from a context management problem into a natural extension of the locator system you've been mastering throughout this course. Instead of changing your automation's global focus to interact with iframe content, you create locators that are automatically scoped to specific iframe boundaries. This scoping happens dynamically during each interaction, meaning the iframe can reload, change content, or even temporarily disappear without breaking your locator definitions.

The key insight behind FrameLocator lies in treating iframe content as scoped targets rather than separate contexts requiring explicit navigation. This approach aligns perfectly with Playwright's locator philosophy while eliminating the state management complexity that characterized Selenium iframe automation.

// Example demonstrating iframe interaction with the-internet.herokuapp.com
public class FramesPage
{
    private readonly IPage _page;

    public ILocator PageTitle { get; }
    public ILocator NestedFramesLink { get; }

    public FramesPage(IPage page)
    {
        _page = page;
        PageTitle = _page.Locator("h3");
        NestedFramesLink = _page.GetByRole(AriaRole.Link, new() { Name = "Nested Frames" });
    }

    public async Task NavigateAsync()
    {
        await _page.GotoAsync("https://the-internet.herokuapp.com/frames");
    }

    // Navigation method that follows user workflow to nested frames
    public async Task NavigateToNestedFramesAsync()
    {
        var newPageTask = _page.Context.WaitForPageAsync();

        // Open Nested Frames page in a new tab using Ctrl+Click
        await NestedFramesLink.ClickAsync(new LocatorClickOptions { Modifiers = new[] { KeyboardModifier.Control }});

        // Capture the new window when it appears
        var newPage = await newPageTask;
        await newPage.WaitForLoadStateAsync();

        // Verify navigation completed successfully
        await Assertions.Expect(newPage).ToHaveURLAsync("https://the-internet.herokuapp.com/nested_frames");

        // Return Page Object representing the new window
        return new NestedFramesPage(newPage);
    }

    // Demonstrate that main page content remains accessible
    public async Task VerifyMainPageAccessibilityAsync()
    {
        // No context switching needed - main page elements remain accessible
        await Assertions.Expect(_page.GetByText("Nested Frames")).ToBeVisibleAsync();
    }
}

public class NestedFramesPage
{
    private readonly IPage _page;
    private readonly IFrameLocator _topFrame;
    private readonly IFrameLocator _leftFrame;
    private readonly IFrameLocator _middleFrame;
    private readonly IFrameLocator _rightFrame;
    private readonly IFrameLocator _bottomFrame;

    public NestedFramesPage(IPage page)
    {
        _page = page;

        // Create frame locators for the nested frame structure
        _topFrame = _page.FrameLocator("frame[name='frame-top']");

        // Left and middle frames are nested within the top frame
        _leftFrame = _topFrame.FrameLocator("frame[name='frame-left']");
        _middleFrame = _topFrame.FrameLocator("frame[name='frame-middle']");
        _rightFrame = _topFrame.FrameLocator("frame[name='frame-right']");

        // Bottom frame is at the same level as top frame
        _bottomFrame = _page.FrameLocator("frame[name='frame-bottom']");
    }

    public async Task NavigateAsync()
    {
        await _page.GotoAsync("https://the-internet.herokuapp.com/nested_frames");
    }

    // Method demonstrating interaction with nested frame content
    public async Task VerifyFrameContentAsync()
    {
        // Interact with content in the left frame (nested within top frame)
        await Assertions.Expect(_leftFrame.GetByText("LEFT")).ToBeVisibleAsync();

        // Interact with content in the middle frame (also nested within top frame)
        await Assertions.Expect(_middleFrame.GetByText("MIDDLE")).ToBeVisibleAsync();

        // Interact with content in the right frame
        await Assertions.Expect(_rightFrame.GetByText("RIGHT")).ToBeVisibleAsync();

        // Interact with content in the bottom frame (separate from top frame hierarchy)
        await Assertions.Expect(_bottomFrame.GetByText("BOTTOM")).ToBeVisibleAsync();
    }

    // Method showing how to extract content from frames for test verification
    public async Task<Dictionary<string, string>> GetAllFrameContentsAsync()
    {
        var frameContents = new Dictionary<string, string>();

        // Extract text content from each frame for verification
        frameContents["left"] = await _leftFrame.Locator("body").TextContentAsync() ?? "";
        frameContents["middle"] = await _middleFrame.Locator("body").TextContentAsync() ?? "";
        frameContents["right"] = await _rightFrame.Locator("body").TextContentAsync() ?? "";
        frameContents["bottom"] = await _bottomFrame.Locator("body").TextContentAsync() ?? "";

        return frameContents;
    }
}

public class FramesTests : PageTest
{
    [Test]
    public async Task DemonstrateNestedFrameInteraction()
    {
        // Start from the main frames page
        var framesPage = new FramesPage(Page);
        await framesPage.NavigateAsync();

        // Navigate to nested frames following the user journey
        var nestedFramesPage = await framesPage.NavigateToNestedFramesAsync();

        // Verify we can interact with all nested frame content
        await nestedFramesPage.VerifyFrameContentAsync();

        // Extract content for detailed verification
        var frameContents = await nestedFramesPage.GetAllFrameContentsAsync();

        // Verify each frame contains expected content
        Assert.That(frameContents["left"].Trim(), Is.EqualTo("LEFT"));
        Assert.That(frameContents["middle"].Trim(), Is.EqualTo("MIDDLE"));
        Assert.That(frameContents["right"].Trim(), Is.EqualTo("RIGHT"));
        Assert.That(frameContents["bottom"].Trim(), Is.EqualTo("BOTTOM"));

        // Verify main page remains accessible throughout iframe interactions
        await framesPage.VerifyMainPageAccessibilityAsync();

        TestContext.WriteLine("Successfully completed frame workflow from navigation through interaction");
    }
}

The FrameLocator pattern transforms iframe interaction from a complex context management challenge into a natural extension of Playwright's locator system. This integration eliminates the state management complexity that characterized Selenium iframe automation while providing more reliable interaction patterns that handle dynamic frame content and timing variations gracefully. The approach scales naturally from simple iframe scenarios to complex nested frame hierarchies while maintaining the architectural consistency that makes automation frameworks maintainable and reliable.

Handling JavaScript Dialogs

JavaScript dialogs presented a unique challenge in Selenium automation because they blocked the browser's main thread and required immediate handling through the Alert interface. Your Selenium experience involved switching to alert contexts, reading alert text, and either accepting or dismissing the dialog before continuing with test execution. This imperative approach required precise timing and created fragile scenarios when dialog timing was unpredictable.

Playwright transforms dialog handling into a declarative, event-driven pattern where you define how dialogs should be handled before they appear. This proactive approach eliminates timing issues while integrating cleanly with the Page Object architecture you've been building throughout this course.

Event-Driven Dialog Pattern in Practice

The key insight behind Playwright's approach lies in declaring your dialog handling intent before triggering actions that might create dialogs. This pattern prevents the race conditions and blocking behavior that made dialog testing challenging in Selenium while keeping dialog handling logic together with the Page Object methods that trigger dialogs.

// Page Object demonstrating integrated dialog handling
public class JavaScriptAlertsPage
{
    private readonly IPage _page;

    public ILocator AlertButton { get; }
    public ILocator ConfirmButton { get; }
    public ILocator PromptButton { get; }
    public ILocator Result { get; }

    public JavaScriptAlertsPage(IPage page)
    {
        _page = page;
        AlertButton = _page.GetByText("Click for JS Alert");
        ConfirmButton = _page.GetByText("Click for JS Confirm");
        PromptButton = _page.GetByText("Click for JS Prompt");
        Result = _page.Locator("#result");
    }

    public async Task NavigateAsync()
    {
        await _page.GotoAsync("https://the-internet.herokuapp.com/javascript_alerts");
    }

    // Method that handles alert dialog as part of complete workflow
    public async Task TriggerAndHandleAlertAsync()
    {
        var alertHandled = false;
        string alertMessage = "";

        // Define the handler function separately so we can remove it later, before using another event handler
        async void AlertHandler(object sender, IDialog dialog)
        {
            alertMessage = dialog.Message;
            Assert.That(dialog.Type, Is.EqualTo(DialogType.Alert));
            await dialog.AcceptAsync();
            alertHandled = true;
        }

        // Attach the handler
        _page.Dialog += AlertHandler;

        try
        {
            // Trigger the dialog
            await AlertButton.ClickAsync();

            // Verify dialog was handled correctly
            Assert.That(alertHandled, Is.True, "Alert dialog should have appeared");
            await Assertions.Expect(Result).ToHaveTextAsync("You successfully clicked an alert");

            TestContext.WriteLine($"Handled alert with message: {alertMessage}");
        }
        finally
        {
            // Always remove the handler, even if an exception occurs
            _page.Dialog -= AlertHandler;
        }
    }

    // Method demonstrating confirm dialog with decision logic
    public async Task HandleConfirmDialogAsync(bool shouldAccept)
    {
        var confirmHandled = false;

        async void ConfirmHandler(object sender, IDialog dialog)
        {
            Assert.That(dialog.Type, Is.EqualTo(DialogType.Confirm));

            if (shouldAccept)
            {
                await dialog.AcceptAsync();
            }
            else
            {
                await dialog.DismissAsync();
            }
            confirmHandled = true;
        }

        _page.Dialog += ConfirmHandler;

        try
        {
            await ConfirmButton.ClickAsync();

            Assert.That(confirmHandled, Is.True, "Confirm dialog should have been handled");

            var expectedResult = shouldAccept ? "You clicked: Ok" : "You clicked: Cancel";
            await Assertions.Expect(Result).ToHaveTextAsync(expectedResult);
        }
        finally
        {
            _page.Dialog -= ConfirmHandler;
        }
    }

    // Method showing prompt dialog with input validation
    public async Task HandlePromptDialogAsync(string inputText)
    {
        var promptHandled = false;

        async void PromptHandler(object sender, IDialog dialog)
        {
            Assert.That(dialog.Type, Is.EqualTo(DialogType.Prompt));
            await dialog.AcceptAsync(inputText);
            promptHandled = true;
        }

        _page.Dialog += PromptHandler;

        try
        {
            await PromptButton.ClickAsync();

            Assert.That(promptHandled, Is.True, "Prompt dialog should have been handled");
            await Assertions.Expect(Result).ToHaveTextAsync($"You entered: {inputText}");
        }
        finally
        {
            _page.Dialog -= PromptHandler;
        }
    }
}

Integration with Page Object Workflows

Dialog handling becomes most valuable when integrated into realistic user workflows rather than tested in isolation. The event-driven pattern enables building complete scenarios where dialog handling represents one step in a larger business process, maintaining the architectural consistency that characterizes maintainable automation frameworks.

// Test demonstrating complete dialog workflow integration
[Test]
public async Task DemonstrateDialogWorkflowIntegration()
{
    var alertsPage = new JavaScriptAlertsPage(Page);
    await alertsPage.NavigateAsync();

    // Test alert handling in sequence
    await alertsPage.TriggerAndHandleAlertAsync();

    // Test confirm dialog with acceptance
    await alertsPage.HandleConfirmDialogAsync(shouldAccept: true);

    // Test confirm dialog with dismissal
    await alertsPage.HandleConfirmDialogAsync(shouldAccept: false);

    // Test prompt dialog with custom input
    await alertsPage.HandlePromptDialogAsync("Playwright automation test");

    TestContext.WriteLine("All dialog types handled successfully within integrated workflow");
}

Playwright's event-driven dialog handling eliminates the timing complexity that made JavaScript dialog testing challenging in Selenium while integrating naturally with Page Object methods. This declarative approach keeps dialog handling logic together with the actions that trigger dialogs, creating more maintainable code that expresses clear business intent rather than getting lost in technical dialog management details.