Browser Sessions

## A browser session names a browser, not an application Almost every Appium session names an application: the capability set carries an artifact, the driver installs it, and everything afterwards happens inside it. A **browser session** is the other shape. You send the standard W3C capability `browserName`, you leave the application artifact out, and the driver treats the phone's own browser as the application under test. Nothing of yours is installed, and the first command you send already runs against a web page instead of against a native view hierarchy. `browserName` is one of the twelve capability names the W3C reserves, so it travels **without** the `appium:` vendor prefix while nearly everything beside it in the same payload carries one. That is a useful tell when you read someone else's capability block: the unprefixed `browserName` is the line that turns the whole session into a web session. What makes this a topic rather than a footnote is that the word *browser* resolves to two different products, reached by two different bridges, depending on which platform the session asked for. ## Android means Chrome, and Chromedriver answers the web half On Android the browser Appium drives is Google Chrome, whose package is `com.android.chrome`. The Android drivers launch it, and the web half of the session — finding elements in the page, clicking them, reading the title — is answered by a **Chromedriver** process rather than by the on-device Android agent. The session reports its context as `CHROMIUM`, the name Appium gives a Chrome-backed web context. - `browserName` is the ask; `com.android.chrome` is the package that actually launches. - Chromedriver, not the on-device UiAutomator2 server, answers the page-level commands. - The context is `CHROMIUM`, so the driver is not looking at a native view tree when you start. - Chrome has to be present on the device or emulator image; there is nothing else for the session to open. - The `appium:safari*` capabilities mean nothing here — they belong to the other platform. ## iOS means Safari, and Apple's remote web inspector answers it On iOS the browser is **Safari** and the driver is **XCUITest**. XCUITest launches Safari and drives the page through Apple's remote web inspector — an Apple debugging facility, not a Chromedriver. Because Safari's start-up is under the driver's control, XCUITest also exposes preferences that apply *before* your first command lands: - `appium:safariInitialUrl` decides which page Safari is showing when the session hands control back to you. - `appium:safariAllowPopups` decides whether script-opened pop-up windows are allowed through. - `appium:nativeWebTap` decides whether a click on a web element becomes a real native tap at translated screen coordinates. - Once the session is running, `mobile: updateSafariPreferences` is the XCUITest execute method for changing Safari preferences mid-run. ## The two, side by side | | Android | Apple's side | |---|---|---| | Driver | UiAutomator2 and the Android drivers | XCUITest | | Browser | Chrome, package `com.android.chrome` | Safari | | Web bridge | a Chromedriver process | Apple's remote web inspector | | Context reported | `CHROMIUM` | not a `CHROMIUM` context | | Start-up preferences | no `appium:safari*` family | `appium:safariInitialUrl`, `appium:safariAllowPopups`, `appium:nativeWebTap` | The row that matters most in practice is the third one. Two different bridges means two different failure modes, two different sets of logs, and two different pieces of machinery to keep working as the platforms move. ## A worked case: the farm weigh-in dashboard Say the livestock-weighing product for farms ships a native weighing app and, beside it, a responsive weigh-in dashboard that farmhands open in whatever browser their phone came with. Checking that dashboard is exactly what a browser session is for. The Android job asks for `browserName` alongside the Android platform and gets Chrome; the iOS job asks for `browserName` alongside the Apple platform and gets Safari, and can be told to open `https://farm.example/weigh-in` immediately with `appium:safariInitialUrl`. From the moment each session is up, the code that types a weight, picks an animal tag and submits the record is ordinary WebDriver code and can be shared between them. What cannot be shared is the sentence "we tested it in *the* mobile browser". You tested it in two browsers, deliberately, because that is what the two platforms give you. ## Where this goes wrong 1. Treating `browserName` as a free choice of browser. Each platform answers with its own browser; the capability is how you ask for a browser session, not a menu of every browser on the handset. 2. Expecting an `appium:safari*` key to have an Android effect. Those keys are XCUITest's, and the Android side has no member of that family. 3. Writing one setup helper that hides the divergence, then being surprised that one page-level failure has two entirely different explanations underneath it. 4. Forgetting the device is still there: a browser session runs on a real device or emulator, with that device's screen size, keyboard and network conditions.