🔗 Related Issues

No issue; this is fallout from c27beca214 ([build] repin webref CDDL and drop the reffy CDDL header workaround). Split out of #17970, which cannot be verified on any platform without it.

💥 What does this PR do?

Two independent one-line build fixes. Every Python Bazel target on trunk currently fails, and create-bidi-src_schema fails on Windows.

1. py/BUILD.bazel still names the old Bluetooth CDDL repository. The repin renamed web_bluetooth_all_cddl to bluetooth_scanning_all_cddl in MODULE.bazel and common/webref_cddl.bzl, but py/BUILD.bazel kept the old name, so anything reaching //py:create-bidi-src fails analysis:

ERROR: py/BUILD.bazel:773:14: no such package '@@[unknown repo 'web_bluetooth_all_cddl' requested from @@]//file':
  No repository visible as '@web_bluetooth_all_cddl' from main repository and referenced by '//py:create-bidi-src'

This is already failing on trunk — see Python / windows-smoke and the other ~20 Python jobs in the CI run for c27beca214. It has stayed unnoticed since because the two commits that landed after it touch Java and .NET, and the Python jobs are file-scoped, so they have not run again.

2. A Windows checkout gives the CDDL overlays CRLF endings. .gitattributes normalizes by content (* text=auto) and has no rule for *.cddl, so core.autocrlf rewrites the five overlay files in common/bidi/. The CDDL parser keeps the carriage return inside the production name, so every type those files define becomes unresolvable and schema generation fails:

BiDi schema validation failed:
  moz:debugging.getScriptSource: unresolved type mozDebugging.GetScriptSourceParameters
  moz:profiler.start: unresolved type mozProfiler.StartParameters
  DigitalCredentialsCommand: unresolved type digitalCredentials.SetVirtualWalletBehavior
  BluetoothEvent: unresolved variant bluetooth.DescriptorEventGenerated
  ...

Those four namespaces are exactly the four checked-in overlays — Debugging.cddl, Profiler.cddl, digital-credentials-command.cddl and web-bluetooth-events.cddl. Nothing downloaded from webref is affected, because http_file is not subject to .gitattributes.

🔧 Implementation Notes

I checked the second one rather than inferring it: converting common/bidi/*.cddl to CRLF on macOS and rebuilding //javascript/selenium-webdriver:create-bidi-src_schema reproduces the Windows failure exactly, including the dropped from schema: lines. Reverting the line endings makes it pass again.

The fix is *.cddl text eol=lf, alongside the existing entries for *.java, *.html, *.css and *.js. Normalizing in the generator instead would work, but the rest of the repo already solves this at checkout time, and doing it here keeps every consumer of these files — not just the JS generator — safe.

The two fixes are separate commits so either can be dropped independently.

🤖 AI assistance

• No substantial AI assistance used
• AI assisted (complete below)
  • Tool(s): Claude Opus 5 via Claude Code
  • What was generated: the diagnosis and both fixes; the CRLF reproduction described above was run to confirm the second one
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

//py:create-bidi-src, //py:bidi_protocol, //javascript/selenium-webdriver:create-bidi-src_schema and //py:unit (32/32) all build and pass on this branch; //:buildifier leaves py/BUILD.bazel unchanged. The .gitattributes change cannot be exercised on a POSIX host, so CI's Windows jobs are the real test — they are green on the equivalent commits in #17970, where Python / windows-smoke went from failing to passing.

Worth considering as follow-up: scripts/update_cddl.py renames repositories when webref does, so it would be worth having it check for stale references outside common/webref_cddl.bzl, or having the merge step reject a production name containing whitespace so a line-ending problem fails with a clear message rather than as an unresolved type.

🔄 Types of changes

• Bug fix (backwards compatible)