chromedriver cannot connect to chrome

[thegunz]

Worked on Monday for my checkin, then stopped today on my return flight. Chrome was 109 when this first error was thrown:
selenium.common.exceptions.WebDriverException: Message: unknown error: cannot connect to chrome at 127.0.0.1:65194
from session not created: This version of ChromeDriver only supports Chrome version 110
Current browser version is 109.0.5414.121

So I opened chrome and let it update to 110. Then ran the script again and got this error:
selenium.common.exceptions.WebDriverException: Message: unknown error: cannot connect to chrome at 127.0.0.1:65324
from unknown error: unable to discover open pages

[jdholtz]

Hi. Thanks for reporting this. I can reproduce the issue. It seems like Google changed the way headless in Chrome works as of version 110. This was fixed in version 3.4.5 of undetected_chromedriver (see here). To update you can run pip install --upgrade undetected_chromedriver.

However, I am getting a 429 error when trying to set up my account. Does this error occur for you as well? It might be with the recent changes in undetected_chromedriver.

[jdholtz]

Hey @thegunz, I provided a fix for this on the chrome_configuration branch. Can you downgrade Google Chrome to 109 and download Chromedriver version 109 (can be found here). Also, make sure undetected_chromedriver is the version in the requirements.txt because the new version seems to have some issues.

To get those changes, run git pull && git checkout chrome_configuration and make sure to specify chromedriver_path in the config.json (you can see the details in the Configuration Doc).

[darrylwhiting]

It appears that upgrading undetected_chromedriver to 3.4.5 allows me to use the CONFIRMATION_NUMBER FIRST_NAME LAST_NAME method with Chrome 110.0.5481.78. I see the correct UTC time for my departing flight with a valid check-in timeframe about 8 hours from now. Am I risking a possible error that mean my flight won't check-in?

[jdholtz]

I haven’t been able to test undetected chromedriver 3.4.5 (it wasn’t working for me), so I don’t know for sure if it will work. If you do decide to proceed, please let me know if it works.

Could you also test if it successfully works when providing a username and password, if possible?

[darrylwhiting]

When using username and password I get the following: KeyError: 'customers.userInformation.firstName'

[darrylwhiting]

Ya, I am getting 429 as well:
{'code': 429999999, 'message': 'Error.', 'messageKey': 'ERROR', 'httpStatusCode': 'BAD_REQUEST', 'requestId': '', 'infoList': []}

At this point I will chance the other method.

[darrylwhiting]

Checking in to flight from 'Blah' to 'Meh' for JOHN DOE

Failed to check in to flight 1A2WXYZ for JOHN DOE Reason: Too Many Requests 429.
Check in at this url: https://mobile.southwest.com/check-in

And also when I logged into the .com site, and then did a manual check in, I got an error about "appendChild" that was thrown by Southwest.com, and I had to use a different Check-in button, so I wonder if this is partly on the SW's side?

Edit - This is what I clicked initially that threw the apendChild Pop Up Error Box (Note: the html below is after I checked in, so it may have been slightly different, but it still throws the same error):

<div class="landing-air-upcoming-trips-banner-details--item_right"><div class="landing-air-upcoming-trips-banner-call-to-action"><div class="landing-air-upcoming-trips-banner-call-to-action--container"><a href="/air/check-in/review.html?clk=HPTRIPSLINKHASBP&amp;searchToken=SNIP SNIP class="actionable actionable_link actionable_extra-small-link actionable_suffix link"

After the error was thrown, and I clicked OK to clear the pop up, I had to use the lower right Check-in button, below all the flight details. I wish I was awake enough to have done all this with Network trace on, but oh well.

Edit 2 - GOT IT!!!! This is the error I receive if I interact with the "banner" Check-in button

checkInPageFormEdit: An error has occurred: Cannot read properties of undefined (reading 'appendChild')

Screenshots for Pop-up and Check-in Button: screens

[jdholtz]

That’s strange. Unfortunately, I don’t have any upcoming flights to try, so I won’t be able to test this for a while. Hopefully it is just from Southwest’s side and they fix it soon.

[thegunz]

I was not able to downgrade to chrome 109 on my managed work PC, so I upgraded undetected_chromedriver to 3.4.5. I ran the script for a flight I have today (already checked in) hoping I'd at least see a successful outcome telling me my boarding position. Unfortunately, got this error result (removed my conf # & name): Failed to check in to flight XXXX for [firstname] [lastname] Reason: Too Many Requests 429. Check in at this url: https://mobile.southwest.com/check-in Hopefully this will help troubleshoot the issue

…

On Wed, Feb 8, 2023 at 7:48 PM Joey H ***@***.***> wrote: Hey @thegunz <https://github.com/thegunz>, I provided a fix for this on the chrome_configuration <https://github.com/jdholtz/auto-southwest-check-in/tree/chrome_configuration> branch. Can you downgrade Google Chrome to 109 and download Chromedriver version 109 (can be found here <https://chromedriver.chromium.org/downloads>). Also, make sure undetected_chromedriver is the version in the requirements.txt because the new version seems to have some issues. To get those changes, run git pull && git checkout chrome_configuration and make sure to specify chromedriver_path in the config.json (you can see the details in the Configuration Doc). — Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWITM244MKVSIVENVITGGSLWWREH7ANCNFSM6AAAAAAUV3KTEQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jdholtz]

Yeah, this is the current issue I get as well when trying to log in. undetected_chromedriver changed some of its anti-bot algorithms, so that could be the issue. I’ll keep up with the undetected_chromedriver repository and hopefully they will have a fix soon.

Edit: It appears that after Chrome version 110, many companies updated their anti-bot detection, so we will have to wait for an update from undetected_chromedriver. See the discussion here

[zderick]

I was able to overcome this by downloading an older version of chrome. 108 in my case from here: http://mirror.cs.uchicago.edu/google-chrome/pool/main/g/google-chrome-stable/

And then adding a parameter when we initialize the driver here: https://github.com/jdholtz/auto-southwest-check-in/blob/master/lib/webdriver.py#L44

Chrome(options=self.options, ..., version_main=108)

[jdholtz]

Thanks for testing @zderick. I was also able to test with the same parameters on version 109 with success.

Here are my results from doing different tests:

• With Undetected ChromeDriver v3.4.5, the script doesn't log in successfully with any version of Chrome.
• With Undetected ChromeDriver v3.1.7 (the current version in the script), the script logs in successfully with Chrome v108 (@zderick's testing) and v109. However, it doesn't work with Chrome version 110.

I assume the current script works with any Chrome version <= 109. Instead of adding the ChromeDriver path to the configuration, I can allow users to specify the chrome version. Then, the script can limit Google Chrome versions to <= 109 until v110+ works with undetected_chromedriver.

Can anyone verify a check-in works using Chrome version <= 109? You can follow what @zderick did above to specify the version. If you can't figure that out, let me know and I will create a branch so you can specify the version in the configuration file.

[darrylwhiting]

If the status is the same by next Friday, I can try again with an older version of Chrome (v109). I actually prefer this since another site I regularly "watch" may have broken too. :)

[molmedo1]

Thanks for testing @zderick. I was also able to test with the same parameters on version 109 with success.

Here are my results from doing different tests:

• With Undetected ChromeDriver v3.4.5, the script doesn't log in successfully with any version of Chrome.
• With Undetected ChromeDriver v3.1.7 (the current version in the script), the script logs in successfully with Chrome v108 (@zderick's testing) and v109. However, it doesn't work with Chrome version 110.

I assume the current script works with any Chrome version <= 109. Instead of adding the ChromeDriver path to the configuration, I can allow users to specify the chrome version. Then, the script can limit Google Chrome versions to <= 109 until v110+ works with undetected_chromedriver.

Can anyone verify a check-in works using Chrome version <= 109? You can follow what @zderick did above to specify the version. If you can't figure that out, let me know and I will create a branch so you can specify the version in the configuration file.

flying tomorrow and didnt come here to check issue unfotunately. I got the too many request error even though i changed the chromedriver options to 109 . NOW i have downgraded UC to 3.1.7 and using chromev109. I fly back Sunday. Will test and report back

[jdholtz]

I added the option to specify the chrome version in the config.json in the chrome_version branch. There isn't documentation on it yet, but you can view the config.example.json for an example on how to use it. Just input the main version (108, 109, etc.). The default is 109.

Note: It does not work in Docker yet

[everettsouthwick]

I added the option to specify the chrome version in the config.json in the chrome_version branch. There isn't documentation on it yet, but you can view the config.example.json for an example on how to use it. Just input the main version (108, 109, etc.). The default is 109.

Note: It does not work in Docker yet

I made some local changes to the Dockerfile that may help (I replaced where it installs google-chrome-stable):

ARG CHROME_VERSION="109.0.5414.119-1"
RUN wget --no-verbose -O /tmp/chrome.deb https://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_${CHROME_VERSION}_amd64.deb \
  && apt install -y /tmp/chrome.deb \
  && rm /tmp/chrome.deb

Modified from here: https://unix.stackexchange.com/questions/233185/install-older-versions-of-google-chrome-stable-on-ubuntu-14-10

[jdholtz]

Thanks @everettsouthwick! I will use that to make changes in the Dockerfile (or you can submit a PR), but I’ll wait for verification that a check-in works first.

[molmedo1]

Thanks for testing @zderick. I was also able to test with the same parameters on version 109 with success.
Here are my results from doing different tests:

• With Undetected ChromeDriver v3.4.5, the script doesn't log in successfully with any version of Chrome.
• With Undetected ChromeDriver v3.1.7 (the current version in the script), the script logs in successfully with Chrome v108 (@zderick's testing) and v109. However, it doesn't work with Chrome version 110.

I assume the current script works with any Chrome version <= 109. Instead of adding the ChromeDriver path to the configuration, I can allow users to specify the chrome version. Then, the script can limit Google Chrome versions to <= 109 until v110+ works with undetected_chromedriver.
Can anyone verify a check-in works using Chrome version <= 109? You can follow what @zderick did above to specify the version. If you can't figure that out, let me know and I will create a branch so you can specify the version in the configuration file.

flying tomorrow and didnt come here to check issue unfotunately. I got the too many request error even though i changed the chromedriver options to 109 . NOW i have downgraded UC to 3.1.7 and using chromev109. I fly back Sunday. Will test and report back

Using config file with v109 and UC 3.1.7 worked like a charm!!! Was able to add multiple conf# which I forgot the script could do. B06&B07 not bad. Thanks everyone.

[ryanjchan]

For what its worth, I was getting the same WebDriverExceptions and only updated UC (undetected-chromedriver==3.4.6). I do not have issues reading the reservation page anymore so I assume the checkin should work as well.

The chrome I am running is - Google Chrome 110.0.5481.77

[jdholtz]

@molmedo1 glad to hear it worked. I will merge the latest changes from the chrome_version branch, and then I can release version 2!

[jdholtz]

@ryanjchan could you try to log in? You can see in this comment that it scheduled the check-in successfully but still failed to actually perform the check in. I am also trying with the latest version of Chrome and undetected_chromedriver and getting a 429 error when trying to log in.

[ryanjchan]

I get a 404 when attempting the checkin since it is too soon? (Not sure what the behavior is, should this url only work if its within the checkin window?)

When checking the .com the url returns {"code":400120102,"message":"","httpStatusCode":"BAD_REQUEST","requestId":"","infoList":[""]}

The initial GET for a checkin fails (mobile-air-operations/v1/mobile-air-operations/page/check-in/) so I never get to the POST to checkin.

I'll try to check the output when the flight comes around later this week.

[jdholtz]

Yes, that 404 is expected. You can see that happen on the Southwest website as well.

[vdude8]

Just a quick comment (maybe this is already known): I was having the same issue, and I changed the headless mode in webdriver.py by adding the argument "--headless=new". Based on what I'm reading, it should be "--headless=chrome" for versions 96-108, and 109 and beyond should be set to "new". Just checked into two flights now on Chrome 110!

source: https://www.selenium.dev/blog/2023/headless-is-going-away/

[jdholtz]

Thanks @vdude8 for finding this! This was implemented in the latest versions of undetected_chromedriver, but I'm still getting detected by Southwest so I just ported that feature to the chrome_version branch.

[jdholtz]

Hey @everettsouthwick, I tried to implement the Docker version specification, but I couldn't figure out a way to simultaneously allow the user to download the latest version automatically or a specific version if specified. If anyone else figures it out, feel free to make a pull request.