Do you think that when running with headless mode, it load all the cookies in the browser?
I donât know.
As for plain old browsers (decade old FF, IE), yes, I could trick them to load the cookies I injected. Therefore previously I had a guess that I can trick Chrome (and Headless Chrome) to load all cookies by starting it with specific User Profile specified. I did some experiments and observations, but I could not see how Chrome works internally.
I have developed a library (WebDriverFactory4ks) but I am not sure if it is useful.
I would recommend to you, @ziyaad.ellahee , not to use this, not to try to trick Chrome. I suppose that you might encounter more cases where you are refused by Chrome somehow, like âYou must enrole your browser to authenticateâ.
I did a quick check.
No, no cookies are loaded. I am not sure if cookies are stored into the Chrome User Profile but not loaded next time, or if cookies are not stored into the user profile at all. I am afraid, my WebDriverFactory4ks library is useless.
I havenât been able to verify if a cookie which were saved by the 1st session into a Chrome User Profile âKatalonâ is reloaded into the 2nd session and sent injected into a HTTP request header. Perhaps I need to invent a HTTP server for this verification.
Yes, what confused me is that, when the same test is run with UI, it pass but in headless mode it fail.
There is a mystery somewhere. What are the difference when test via UI & headless?
I have no idea.
Nobody can be sure about the internal of browsers. I think you should not depend on heuristics about the browserâs behaviour.
I ran both test via UI and headless, only difference i noticed:
In UI:
Starting ChromeDriver 95.0.4638.17 (a9d0719444d4b035e284ed1fce73bf6ccd789df2-refs/branch-heads/4638@{#178}) on port 8189
Via Headless:
Starting ChromeDriver 95.0.4638.17 (a9d0719444d4b035e284ed1fce73bf6ccd789df2-refs/branch-heads/4638@{#178}) on port 17977
Is this something that we can play with?
I donât think so.
8189 and 17977 â these are the port number which Chrome browser listens for incoming messages from ChromeDriver. The port number is decided dynamically by ChromeDriver when it launches the Chrome browser. The port number itself means nothing functional, I think.
I have examined this issue, and found that the ChromeDriverFactory of v0.3.5 of WebDriverFactory4ks does NOT reload the cookies saved by the 1st session into the 2nd session. See Make sure if a Chrome Headless browser launched with a User Profile specified retain ALL cookies that have been created ¡ Issue #11 ¡ kazurayam/WebDriverFactory4ks ¡ GitHub for your interest.
Due to this problem, I think that WebDriverFactory4ks v0.3.5 is effectively useless. People should not use this at all.
This problem might require deep hack. I have no idea, at the moment, if I could improve this in future.