[ChromeDriver] Tests failing with invalid argument: Unsupported locator strategy: null

[tmepple]

Issue

Similar to #468 all of my previously working Wallaby tests are now failing locally on cast_as_element/2. I felt like the newest Chromedriver was causing it by complaining about an "Unsupported locator strategy: null" but I downgraded to 2.46 and still seeing the issue. Also downgraded Wallaby to 0.22 and still seeing it.

Using Wallaby 0.23, Chromedriver 77.0.3865.40, MacOS 10.14.6, Elixir 1.9.1, and Erlang 22.0.7. My installed Chrome version is also 77.0.3865.40 so it should be compatible with the driver.

Manual testing shows everything is working properly with the rendered HTML.

Test Code & HTML

Simplest possible test:

  test "viewing the homepage shows the proper static title", %{session: session} do
    session
    |> visit("/")
    |> assert_has(css("h1.title", text: "Environmental Information"))
  end

Error Message:

1) test viewing the homepage shows the proper static title (ZenterraWeb.HomeFeatureTest)
     apps/zenterra_web/test/zenterra_web/features/home_feature_test.exs:4
     ** (FunctionClauseError) no function clause matching in Wallaby.Experimental.Selenium.WebdriverClient.cast_as_element/2

     The following arguments were given to Wallaby.Experimental.Selenium.WebdriverClient.cast_as_element/2:

         # 1
         %Wallaby.Session{driver: Wallaby.Experimental.Chrome, id: "aed12e5e5b063f90649681cf7ed0c68a", screenshots: [], server: Wallaby.Experimental.Chrome.Chromedriver, session_url: "http://localhost:54263/session/aed12e5e5b063f90649681cf7ed0c68a", url: "http://localhost:54263/session/aed12e5e5b063f90649681cf7ed0c68a"}

         # 2
         {"message", "invalid argument: Unsupported locator strategy: null\n  (Session info: chrome=77.0.3865.90)\n  (Driver info: chromedriver=77.0.3865.40 (f484704e052e0b556f8030b65b953dce96503217-refs/branch-heads/3865@{#442}),platform=Mac OS X 10.14.6 x86_64)"}

     Attempted function clauses (showing 2 out of 2):

         defp cast_as_element(parent, %{"ELEMENT" => id})
         defp cast_as_element(parent, %{"element-6066-11e4-a52e-4f735466cecf" => id})

     code: |> assert_has(css("h1.title", text: "Environmental Information"))
     stacktrace:
       (wallaby) lib/wallaby/experimental/selenium/webdriver_client.ex:566: Wallaby.Experimental.Selenium.WebdriverClient.cast_as_element/2
       (elixir) lib/enum.ex:1340: anonymous fn/3 in Enum.map/2
       (stdlib) maps.erl:232: :maps.fold_1/3
       (elixir) lib/enum.ex:1964: Enum.map/2
       (wallaby) lib/wallaby/experimental/selenium/webdriver_client.ex:43: Wallaby.Experimental.Selenium.WebdriverClient.find_elements/2
       (wallaby) lib/wallaby/driver/log_checker.ex:6: Wallaby.Driver.LogChecker.check_logs!/2
       (wallaby) lib/wallaby/browser.ex:1140: anonymous fn/3 in Wallaby.Browser.execute_query/2
       (wallaby) lib/wallaby/browser.ex:146: Wallaby.Browser.retry/2
       test/zenterra_web/features/home_feature_test.exs:7: (test)

[mhanberg]

I am not able to reproduce this.

Are you still seeing this?

[tmepple]

Thanks for looking into this. Yes, I just upgraded to the latest Chromedriver v78 and still seeing this issue on all my tests. It looks like Wallaby is POST-ing the proper params %{using: "css selector", value: "h1.title"} to the chromedriver /elements so I'm not sure why it's complaining about an unsupported locator strategy when everything previously worked great.

It doesn't appear to be a widespread problem so I tried to make a minimal reproduction using a vanilla Phoenix app. I tested that "Welcome to Phoenix!" appears properly in <h1> on the home page and it works properly.

My app has significant ReactJS client-side rendering compared to the basic Phoenix app which shouldn't matter but besides that I can't think of a difference that could cause this. I will experiment more when I have some time.

[wyrdforge]

Basically, I ran into the same behaviour with a similar test on the default phoenix page, when setting up wallaby. I tried a fix from an older project, where in the 1.7 container, wallaby even refused to start on any version above Chrome 0.69.x

The elixir:1.9 container would install 0.73.xxxxxx by default, which constantly results in a cast_as_element/2 error, but with an 'invalid id', as soon, as I use Wallaby.Query.

I manually add headless chrome v68 from a deb archive and use chromedriver 2.41 in my dev/test Dockerfile for now. This also works in my current case., though this feels not the best option.

[PragTob]

This is weird. I definitely have chromedriver tests working with wallaby on that standard alpine linux elixir images. I think the chrome driver versions are a bit old there (73 or so) but it definitely runs all our tests.

[viniciussbs]

I'm facing this issue, too.

• Wallaby 0.23
• ChromeDriver 76.0.3809.126
• Chrome 78.0.3904.70
• MacOS 10.13.6
• Elixir 1.9.1
• Erlang 22.0.1

[wyrdforge]

AFAIK, we should use the ChromeDriver matching the Chrome version in the newer CD releases.

If you are lucky, this may solve your issue already. In my older applications, I went down in versions step by step, until I reached a combination, that worked (in my case Chrome/Chromium 0.68 and ChromeDriver 2.41).

I will try this again with my current project and hopefully find something viable. Maybe the issues arise only in the ubuntu, not the alpine based elixir docker image.

[tmepple]

@wyrdforge It's recommended to use the same ChromeDriver version as the installed Chrome version. At this point they have sync'ed the version numbers. I am running it locally on MacOS, not on CD, so using the latest stable v78. It may still work to downgrade to 2.41 but probably not for very long.

[mhanberg]

@viniciussbs Are you seeing the "Unsupported locator strategy: null" error or just a FunctionClauseError with cast_as_element?

[viniciussbs]

@mhanberg just a FunctionClauseError with cast_as_element. But I've updated my ChromeDriver version to match the Chrome version - as @tmepple suggested - and that fixed the issue. Just a brew cask reinstall chromedriver and problem solved.

[viniciussbs]

Maybe we could put a caveat in the README mentioning that Chrome and ChromeDriver versions should match.

[mhanberg]

@tmepple are you still experiencing this error? If not, can we close this issue if it doesn't seem to be a problem with Wallaby?

I think we definitely need to elevate errors like this instead of masking them as a FunctionClauseError, but I will take care of that separately.

@viniciussbs I can add a section to the readme about the chrome/chromedriver versions.

[wyrdforge]

I was able to boil my problems down to the docker image. The preinstalled chromedriver version is that from the distribution (0.73 for chromium and chromedriver/chromium-driver. Upgrading to 0.78 breaks things, as chrome is preferred in the newer version over chromium, but chromedriver is not and chromium-driver 0.73 is used. If I stick solely to the distribution versions, all tests run as expected.

@mhanberg I add to this, as the masked error is highly misleading. Especially, as it seems, we can get different error results and messages for the same (basic) cause.

[tmepple]

@mhanberg Unfortunately I am still seeing the error Unsupported locator strategy: null on all my tests. I've googled it and there have been some very recent reports from other ecosystems but no conclusive cause yet.

Since the same type of query works fine when testing the fresh Phoenix landing page I will find some more time trying to determine the difference in my page versus that besides just the use of React.

[tmepple]

I never solved this issue but I did rewrite the tested functionality using LiveView in a fresh new Phoenix project and am not seeing this error in the new app.

I think the other commenters who were seeing similar errors found a way to work around them all so will close now and hope it doesn't happen again!