Add title attribute to default UI input for access

[rdela]

See #727

This addresses the first part of that issue, adding title attribute to default UI input for accessibility that matches the placeholder.

Had quite the adventure getting this to build, will document that and changes I made to suppress errors soon, but taking a break to eat.

[rdela]

Alright, back at the old helm ⎈ ☸️

Build issues, starting with code changes…

resolver + edition

Cargo.toml, L5

resolver = "2"

Silences these warnings:

warning: virtual workspace defaulting to resolver = "1" despite one or more workspace members being on edition 2021 which implies resolver = "2"
note: to keep the current resolver, specify workspace.resolver = "1" in the workspace root's manifest
note: to use the edition 2021 resolver, specify workspace.resolver = "2" in the workspace root's manifest
note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions

I chose 2, as suggested, since we are on edition = "2021" via L4 of pagefind/Cargo.toml. When we update to edition = "2024" there, we will want to change to resolver = "3"

More info:

• Cargo > Resolver versions
• Transitioning an existing project to a new edition
• Improve workspace resolver error message when root edition is missing rust-lang/cargo #13579

build playground

Updated Contributing.md to include build step for Playground, introduced since last release: cd pagefind_playground && npm i && npm run build

Fixes cascading errors from pagefind/src/playground.rs when it is not already built for cargo build --release.

   Compiling pagefind v0.0.0 (/pagefind/pagefind)
error: couldn't read `/pagefind/pagefind/vendor/playground/index.html`: No such file or directory (os error 2)
 --> pagefind/src/playground.rs:1:35
  |
1 |   pub const PLAYGROUND_HTML: &str = include_str!(concat!(
  |  ___________________________________^
2 | |     env!("CARGO_MANIFEST_DIR"),
3 | |     "/vendor/playground/index.html"
4 | | ));
  | |__^
  |
  = note: this error originates in the macro `include_str` (in Nightly builds, run with -Z macro-backtrace for more info)

error: couldn't read `/pagefind/pagefind/vendor/playground/pagefind-playground.css`: No such file or directory (os error 2)
 --> pagefind/src/playground.rs:6:34
  |
6 |   pub const PLAYGROUND_CSS: &str = include_str!(concat!(
  |  __________________________________^
7 | |     env!("CARGO_MANIFEST_DIR"),
8 | |     "/vendor/playground/pagefind-playground.css"
9 | | ));
  | |__^
  |
  = note: this error originates in the macro `include_str` (in Nightly builds, run with -Z macro-backtrace for more info)

error: couldn't read `/pagefind/pagefind/vendor/playground/pagefind-playground.js`: No such file or directory (os error 2)
  --> pagefind/src/playground.rs:15:5
   |
15 | /     include_str!(concat!(
16 | |         env!("CARGO_MANIFEST_DIR"),
17 | |         "/vendor/playground/pagefind-playground.js"
18 | |     ))
   | |______^
   |
   = note: this error originates in the macro `include_str` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `pagefind` (lib) due to 3 previous errors

charabia > lindera > lindera-unidic

I was not able to solve this issue and was forced to use cargo build --release instead of cargo build --release --features extended.

cargo build --release --features extended

error: failed to run custom build command for `lindera-unidic v0.32.2`

Caused by:
  process didn't exit successfully: `/pagefind/target/release/build/lindera-unidic-5cdad2f210f08d97/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:rerun-if-changed=Cargo.toml
  cargo::rustc-env=LINDERA_WORKDIR=/pagefind/target/release/build/lindera-unidic-da00be24bddf3f12/out

  --- stderr
  Error: Transport(Transport { kind: Dns, message: Some("resolve dns name 'dlwqk3ibdg1xh.cloudfront.net:443'"), url: Some(Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("dlwqk3ibdg1xh.cloudfront.net")), port: None, path: "/unidic-mecab-2.1.2.tar.gz", query: None, fragment: None }), source: Some(Custom { kind: Uncategorized, error: "failed to lookup address information: nodename nor servname provided, or not known" }) })
warning: build failed, waiting for other jobs to finish...

From what I was able to determine, this issue triggers when --features extended flag is added because of L91 of pagefind/Cargo.toml

Charabia gets included there and depends on Lindera which depends on lindera-unidic, and tries to link to unidic-mecab-2.1.2.tar.gz. Apparently the solution is to update Lindera, which for us means updating to Charabia v0.9.3.

LMK if I am clear to do bump to 0.9.3 from 0.8.8 here on L52 of pagefind/Cargo.toml, or if you want that separately.

This is already long, so will add notes on build browser testing in a separate comment.

[rdela]

Back again, new and improved, for build browser testing notes.

Here is my experience opening this PR, and some ideas for expanding the “Test suite” section of CONTRIBUTING.md.

As instructed, I ran:

npx toolproof@latest

then screenfuls of errors like this first one:

thread 'tokio-runtime-worker' panicked at toolproof/src/definitions/browser/mod.rs:86:18:
called `Result::unwrap()` on an `Err` value: "Could not auto detect a chrome executable"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This turns out to be because toolproof uses chromiumoxide and its browser. If you read the chromiumoxide README carefully all the way to the References section at the bottom, you may discover rust-headless-chrome and, from there, if you are fortunate, this extraordinarily helpful comment:

/// If the CHROME environment variable is set, default_executable will
/// use it as the default path. Otherwise, the filenames google-chrome-stable
/// chromium, chromium-browser, chrome and chrome-browser are
/// searched for in standard places. If that fails,
/// /Applications/Google Chrome.app/... (on MacOS) or the registry (on Windows)
/// is consulted. If all of the above fail, an error is returned.

You may realize then that you stopped installing Google Chrome in 2020, and that seemingly testing pagefind has an unspecified dependency on Headless Chrome being on the system, which started shipping alongside Chrome in v59 and got a big update in Chrome 112.

Deeply discouraged, but still even more enthusiastic to contribute to this outstanding project, you end up choosing Headless Chromium and its “precompiled headless_shell binaries […] available for download under the name chrome-headless-shell via Chrome for Testing infrastructure,” (stable channel).

After locating the chrome-headless-shell you need (mac-arm64 in my case, since I am on a M series Apple silicon Mac), downloading, and installing it, you set the CHROME environment variable to its path. In my case, I added this line to ~/.bash_profile after I put the chrome-headless-shell-mac-arm64 folder in ~/Applications (note this is in my user folder, on purpose):

export CHROME="/Users/your-user-name-goes-here/Applications/chrome-headless-shell-mac-arm64/chrome-headless-shell"

You can check if the environment variable is set with the env command on Mac

Finally, you will be able to run the tests, however, the first time it runs you will probably have to bypass Gatekeeper.

If a security alert reading:

"chrome-headless-shell" Not Opened
Apple could not verify "chrome-headless-shell" is free of malware that may harm your Mac or compromise your privacy.

Try these steps:

1. Go to Apple menu > System Settings.
2. Navigate to Privacy & Security and click the Open Anyway button in order to give access to the blocked app. Note that this option will be displayed only after you try to run the problematic app.

You may need to click Done, probably several times, and/or rerun the npx toolproof@latest command.

Once you see the alert, go to System Settings and Allow Anyway. You may then see yet another security alert:

Open "chrome-headless-shell"?
Apple is not able to verify that it is free from malware that could harm your Mac or compromise your privacy. Don't open this unless you are certain it is from a trustworthy source.

And need to click Open Anyway.

Even after than, when 206 of 209 tests ran for me, 3 tests failed every time:

[…]

✘ [16.249s] Base Modular UI Tests > LEGACY Pagefind Modular UI searches

[…]

✘ In my browser, I evaluate {js}
--- ERROR ---
Error in step "In my browser, I evaluate {js}":
js: |-
  let val = await toolproof.querySelector(".pagefind-modular-list-link");
  toolproof.assert_eq(val.innerHTML, `world`);
--
Failed assertion: Error: querySelector timed out at 16000ms, no elements matching ".pagefind-modular-list-link"
browser console:

[…]

✘ [16.209s] Base Modular UI Tests > Pagefind Modular UI searches

[…]

✘ In my browser, I evaluate {js}
--- ERROR ---
Error in step "In my browser, I evaluate {js}":
js: |-
  let val = await toolproof.querySelector(".pagefind-modular-list-link");
  toolproof.assert_eq(val.innerHTML, `world`);
--
Failed assertion: Error: querySelector timed out at 16000ms, no elements matching ".pagefind-modular-list-link"
browser console:

[…]

✘ [16.234s] Pagefind Playground can be output

[…]

✘ snapshot: In my browser, the result of {js}
--- ERROR ---
Error in step "snapshot: In my browser, the result of {js}":
js: |-
  // Only exists when the result data loads
  let pinButton = await toolproof.querySelector(".result:nth-of-type(1) > code > button");
  let title = await toolproof.querySelector(".result:nth-of-type(1) > code");

  return title.innerText;
snapshot_content: '╎0: [0.29812253] ☆ /res-zero/ — title title title'
--
Failed assertion: Error: querySelector timed out at 16000ms, no elements matching ".result:nth-of-type(1) > code > button"
browser console:

[…]

Finished running tests

Passing tests: 206
Failing tests: 3
Skipped tests: 0

Some tests failed in 45.479 seconds

To get those 3 failing tests to pass, you will need to bypass Gatekeeper for these three linked binaries as well:

• ~/Applications/chrome-headless-shell-mac-arm64/libEGL.dylib
• ~/Applications/chrome-headless-shell-mac-arm64/libGLESv2.dylib
• ~/Applications/chrome-headless-shell-mac-arm64/libvk_swiftshader.dylib

Until you do, you will see security alerts each time you run npx toolproof@latest:

"libGLESv2.dylib" Not Opened; Apple could not verify "IibGLESv2.dylib" is free of malware that may harm your Mac or compromise your privacy.

and need to click Done, probably several times.

Once you see the alert, go to System Settings like you did before for chrome-headless-shell, and Allow Anyway for each one.

You may see yet another security alert:

Open "libvk_swiftshader.dylib"?
Apple is not able to verify that it is free from malware that could harm your Mac or compromise your privacy. Don't open this unless you are certain it is from a trustworthy source.

And need to click Open Anyway for each, like you did for chrome-headless-shell.

[bglw]

👋 @rdela — catching up here finally. Change looks good 🙂

Addressing comments:

resolver + edition

All looks good here!

build playground

Likewise!

charabia > lindera > lindera-unidic

You're clear to bump Charabia in this PR :) I see that is failing our CI builds as well, so much appreciated for doing the investigation work ❤️

Sisyphean browser testing adventure

Sorry that this was such a mission to get going! This is one reason we haven't yet pushed Toolproof more broadly. For now, I might just link off to this comment from the docs for users who need to go down the direct headless_shell install path.

Medium term, I'd like to support a pathway to using a Firefox install. (Useful also for ensuring cross-browser support). And longer term, we'd like to round out the nascent https://github.com/CloudCannon/pagebrowse — which wraps https://github.com/tauri-apps/wry to provide a puppeteer-like interface over a system webview rather than a full browser. Toolproof actually supports a small subset of the steps already with --browser pagebrowse, but not enough to run the full suite (nor to run cross-platform). But one day :)

---

Thanks again for jumping in! I'll wait til you've had a chance to bump Charabia and have the extended tests pass, then we can merge.

[rdela]

Alright I bumped charabia in the last commit and

cd pagefind && cargo build --release --features extended

runs smoothly at last, and we also are all green on all 209 tests on my end

[rdela]

[…] For now, I might just link off to this comment from the docs for users who need to go down the direct headless_shell install path.

Medium term, I'd like to support a pathway to using a Firefox install. (Useful also for ensuring cross-browser support). And longer term, we'd like to round out the nascent https://github.com/CloudCannon/pagebrowse — which wraps https://github.com/tauri-apps/wry to provide a puppeteer-like interface over a system webview rather than a full browser. Toolproof actually supports a small subset of the steps already with --browser pagebrowse, but not enough to run the full suite (nor to run cross-platform). But one day :)

This all sounds great, I should have known you have something even more marvelous in store. Happy to help however I can❣️

[bglw]

Thanks @rdela ! Sorry for the slow merge turnaround on this 😅

[rdela]

Thank you! Understand completely, I have been out of band/away from keyboard since you merged this. Huzzah!! Hooray accessibility and placehoders :)