chore (deps) bump chromedriver from 130.0.4 to 146.0.6

[GCHQDeveloper581]

Bumps chromedriver from 130.0.4 to 146.0.6

Partly raised to explore problems seen with browser testing in #2278.

[lzandman]

I've pulled your branch and ran it on my MacBook. The UI tests fail at the same location (line 420) for me. At the Character encoding test. I ran CyberChef both on bare metal and in a Docker container. Both running my locally installed version of Chrome, which now is compatible with this ChromeDriver update. Same failed result.

Running Character encoding:
───────────────────────────────────────────────────────────────────────────────────────────────────
  ✔ Element <#rec-list li.operation> was not present after 14 milliseconds.
  ✔ Expected element <#input-text .cm-content> text to that equal: "" (7ms)
  ✔ Expected '不要恐慌。'  to be equal('不要恐慌。'): 
  ✔ Element <#snackbar-container> was not visible after 4 milliseconds.
  ✔ Element <#input-text .chr-enc-select .cm-status-bar-select-scroll> was visible after 6 milliseconds.
  ✔ Element <#input-text .chr-enc-select .cm-status-bar-select-scroll> was not visible after 5 milliseconds.
  ✔ Expected element <#input-text .chr-enc-value> text to that equal: "UTF-8" (5ms)
  ✔ Element <#output-loader> was not visible after 5 milliseconds.
  ✔ Expected element <#bake span> text to equal: "BAKE!" (10ms)
  ✔ Element <#stale-indicator> was not visible after 5 milliseconds.
  ✔ Element <#output-loader> was not visible after 7 milliseconds.
  ✖ NightwatchAssertError
   Timed out while waiting for element <#snackbar-container .snackbar-content> to be present for 5000 milliseconds. - expected "visible" but got: "not found" (5083ms)

    Error location:
    /Users/leon/git/CyberChef_GCHQDeveloper581/tests/browser/01_io.js:420
    –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
     418 |         /* Output encoding should be autodetected */
     419 |         browser
     420 |             .waitForElementVisible("#snackbar-container .snackbar-content", 5000) 
     421 |             .expect.element("#snackbar-container .snackbar-content").text.to.equal("Output character encoding has been detected and changed to UTF-8");
     422 | 
    –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––


  FAILED: 1 assertions failed and  11 passed (5.442s)

[GCHQDeveloper581]

I've pulled your branch and ran it on my MacBook. The UI tests fail at the same location (line 420) for me. At the Character encoding test. I ran CyberChef both on bare metal and in a Docker container. Both running my locally installed version of Chrome, which now is compatible with this ChromeDriver update. Same failed result.

So - I've seen the same in one of my later, manual tests. At node v18 and node v20 it's happy but falling apart above that. As I said in my comment on #2278 - I'd reached the point where it felt I was just repeating the steps you'd been taking to get things (mostly) working in V24, so I stopped, but can continue if you feel extra pairs of eyes will help (won't be till later this week now).

[lzandman]

So - I've seen the same in one of my later, manual tests. At node v18 and node v20 it's happy but falling apart above that.

I still haven't succeeded in getting the v18 or v20 UI tests to run 100% OK. I'm will first focus on fixing that. If they work for you, it must mean there's something wrong with my setup. I should be able to run master branch without any code changes (except maybe the ChromeDriver version upgrade) and get 100% succeeded tests. So weird...

[GCHQDeveloper581]

For what it's worth, I'm running the v18 tests successfully in a Visual Studio Code devcontainer using the modifications in GCHQDeveloper581@7e5c00a

(plus updating the chromedriver version, but I wanted to keep that out of that diff)

The tests need to be run using
xvfb-run --server-args="-screen 0 1200x800x24" npx grunt testui
(as in the github actions)

[lzandman]

I need to look into this. I'm not that experienced using Github Codespaces. I started one based on master, but that didn't have Chrome installed. And my system doesn't have xvfb-run. When I have the time I'll look at your branch to see what you are doing here.

[lzandman]

I started a local dev container in VSCode from your branch. I'm able to run CyberChef. I'm also able to connect to it from my local machine, though I did have to first make it bind to 0.0.0.0 by editing Gruntfile.js:

...
devServer: {
    host: "0.0.0.0",
...

But when I run xvfb-run --server-args="-screen 0 1200x800x24" npx grunt testui I get:

node ➜ /workspaces/CyberChef_GCHQDeveloper581 (devcontainer-with-chrome-and-xvfb) $ xvfb-run --server-args="-screen 0 1200x800x24" npx grunt testui
Running "connect:prod" (connect) task
Started connect web server on http://localhost:8000

Running "exec:browserTests" (exec) task

[00 Nightwatch] Test Suite
────────────────────────────────────────────────────
>> - Starting ChromeDriver on port 9515...
>> ⚠ Failed to connect to ChromeDriver on localhost with port 9515.

───────────────────────────────────────────────────────────────────────────────────────────────────

  ️TEST FAILURE (149ms): 
   - 1 error during execution; 
   - 2 other test suites were aborted; 
   - 0 tests failed; 
   - 0/NA tests passed
   - 8 skipped

   ✖ 1) 00_nightwatch

  - OTHER ERRORS:
>> Error
>>     An error occurred while creating a new ChromeDriver session: [Error] Server terminated early with status 0
>>   Verify if ChromeDriver is configured correctly; using:
>>   {
>>      start_process: true,
>>      server_path: './node_modules/.bin/chromedriver',
>>      port: 9515,
>>      host: 'localhost',
>>      ssl: false,
>>      default_path_prefix: '',
>>      proxy: undefined,
>>      cli_args: {}
>>   }
>> 
>>  
>>   More info might be available in the log file: /workspaces/CyberChef_GCHQDeveloper581/tests/browser/output/00_nightwatch_chromedriver.log
    SKIPPED (at runtime):
    - Loading screen
    - App loaded
    - Operations loaded
    - Recipe can be run
    - Test every module
    - Move around the UI
    - Search
    - Alert bar

 Wrote HTML report file to: /workspaces/CyberChef_GCHQDeveloper581/tests/browser/output/nightwatch-html-report/index.html

>> Exited with code: 10.
>> Error executing child process: Error: Process exited with code 10.
Warning: Task "exec:browserTests" failed. Use --force to continue.

Aborted due to warnings.

[GCHQDeveloper581]

How odd. It definitely should work!

Take a look at the log file it indicates, /workspaces/CyberChef_GCHQDeveloper581/tests/browser/output/00_nightwatch_chromedriver.log
when I was getting things going there was usually a good clue there.

[lzandman]

For what it's worth, I'm running the v18 tests successfully in a Visual Studio Code devcontainer using the modifications in GCHQDeveloper581@7e5c00a

My /workspaces/CyberChef_GCHQDeveloper581/tests/browser/output/00_nightwatch_chromedriver.log says:

rosetta error: failed to open elf at /lib64/ld-linux-x86-64.so.2

This seems to happen, because the ghcr.io/kreemer/features/chrometesting:1 dev container feature that you introduced always installs a "linux64" (x86-64/amd64) version of Chrome for Testing. I'm running a dev container locally in Docker on Apple Silicon, so I would need the mac-arm64 version of Chrome for Testing. Or force my devcontainer to run emulated as amd64.

[GCHQDeveloper581]

Thats ... suboptimal.

I'm not even sure the chrome-mac-arm64 version would work for you in a dev container as it depends whether it's built against MacOS or Linux-arm64 libraries (and given there's also a chrome-mac-x64 version I'd somewhat suspect the latter).

You could try the "npx @puppeteer/browsers install chrome:latest" method of getting chrome to see where that gets you, but when I tried this method I then hade to manually coerce nightwatch/chromedriver to look in the right place for the chrome binary.

(and given it still points at the same downloads source it quite likely would have similar problems).

[lzandman]

I tried several things yesterday, but gave up. Pretty frustrating.
However, I should be able to just run things locally, not in the container. I'm still puzzled by that encoding UI test failing.

The good thing is I'm learning about devcontainers, LOL.