This appears to be running headless Chrome and not "normal" Chrome.

[Thinking out loud ..] Wondering about the matrix of python versions and browsers versions. Not sure the origin of these specific combinations but it may be worth checking overall what we are testing to see if there are gaps. For example here it look like we have switched from testing normal Chrome with Python 3.8 to Python 3.7.

And with the expanding versions of Python to 3.9, 3.10 how does these fit into the mix. @aaltat always had the strong opinion of limiting the overall testing to just the latest versions. He has very good reason for this - essentially limited resources and time- although I keep wanting expand the testing matrix. I'll say I have no strong reasons for this nor have I overcome the real issue of limited resources. One idea I had was to make this a separate GitHub workflow file which would not "block" - this stil doesn't resolve the real issue of support. We both agree that being able to publicly state what is supported - i.e. what we have tested against - is important and should be done.
This background info I think is important just so all understand all the previous thinking and work that has gone into the current test setup. This way we can build upon that experience and not struggle through the same without changes or improving upon that experience. I'm not opposed to change but am wanting to learn from others experiences in order to make better.

Good catch, I will fix this to normal chrome. 3.8 was not tested previously, despite what some of the task names state. This is because 3.8 was not(and is not) included in the matrix.

I would prefer to get rid of this if python-version == xx && yy=zz and just use the matrix to define browsers and python+rf versions. Maybe even Selenium versions in the future, though this is not realistic at the moment. I realize this results in a lot of jobs very quickly but as far as I can tell Github Actions are free for public repositories and the only limit is 20 concurrent jobs. I think this would further encourage making current tests more robust or not-flaky by fixing timing issues and such, and also to help create robust tests in the future.

The conditions on python version I believe were to limit the overall matrix. I'm good with expanding it. I would say possibly in another pull request.

Yeah definitely not doing that in this pull request.