Bug 229284 – Safari webextension cannot pick up cookies from Safari started by safaridriver

• Component: WebDriver
• Status: RESOLVED INVALID

[Max]

Created attachment 435850 [details]
Cookies are not updated after refresh

Hi, I am working on automation tests for Safari webextension. Currently if I install webextension and open Safari instance, then go to simple page that set cookies, webextension can pick it up.
In case I start tests using safaridriver, it opens Safari instance, opens simple page that set cookies, but when I click on webextension icon, then click "Stop session", I see webextension did not pick up cookies.

This extension just get all the cookies for the current tab, using the API here  https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies/getAll.

I am checking it on Safari 14.1.1 and macOS Big Sur. Same behavior I see on Safari Technology Preview.

Can someone help me with it? Link with WDIO project example - https://github.com/idem7x/safaribug.

[Max]

Created attachment 435851 [details]
Cookies updated after refresh for simple safari instance

[Radar WebKit Bug Importer]

<rdar://problem/82378188>

[Max]

Hi, any updates on this issue?

[Blaze Burg]

Hello Max,

When being driven by safaridriver, Safari uses what is essentially a private browsing session. So cookies that were set before the test session are not accessible, and any cookies set in the test session will not be visible afterwards. This is pretty fundamental to the design of safaridriver and isn't likely to change.

However, we would consider new API to better support the testing situation for Web Extensions in the context of WebDriver. If you have some functionality in mind---for example to enable/disable extensions via WebDriver API---please file a separate bug with that information.

[Lu Xu]

(In reply to BJ Burg from comment #4)
> Hello Max,
> 
> When being driven by safaridriver, Safari uses what is essentially a private
> browsing session. So cookies that were set before the test session are not
> accessible, and any cookies set in the test session will not be visible
> afterwards. This is pretty fundamental to the design of safaridriver and
> isn't likely to change.
> 
> However, we would consider new API to better support the testing situation
> for Web Extensions in the context of WebDriver. If you have some
> functionality in mind---for example to enable/disable extensions via
> WebDriver API---please file a separate bug with that information.

Hi BJ,
I think this issue is not related with private browsing session. The issue is when using safaridriver, the WebExtension can't obtain all the cookies using this API https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies/getAll.

These cookies are not set before or after the test, these cookies are set from the server after opening the web page.

[Max]

Please take a look on comment above.

[Max]

This is very critical for us, as we cannot run tests with safaridriver.
Please take a look.

[Max]

Help!)

[Lu Xu]

Hi team, any update on this?
Here is more details on this:
I open Safari Browser normally and go to a web page, the web server will set a bunch of cookies as below
https://drive.google.com/file/d/1u1WU1HU4Teu-el853n2uRXDBT_DraIS0/view?usp=sharing
Then I go to WebExtension background and use the browser.cookies.getAll API, it will return all the cookies correctly
https://drive.google.com/file/d/1QwuAQuvJoAlMv6EVHKUjr5-WOalA7qF1/view?usp=sharing


I use WebDriver to repeat the above tests, the web server set a bunch of cookies as well (there are 8 non-http-only cookies in total)
https://drive.google.com/file/d/1_4AMkwBmftEW3LmUtfblt3Z8zFHsIQU5/view?usp=sharing
But the browser.cookies.getAll never return all the cookies, it can only get partial of them
https://drive.google.com/file/d/1DTkVBVsMy0BiPUD2B2EAkeiJ6QapjJRA/view?usp=sharing

Please take a look, thank you!

[Lu Xu]

This can also be reproduced on amazon.com, facebook.com.
Safari Version Version 15.0 (15612.1.29.41.4, 15612)

[Brent Fulgham]

Resolving using the mildly offensive 'Invalid' category to indicate this is not an implementation bug.

SafariDriver opens what is essentially a private browsing session, so this is expected behavior.