feat(runtime): integrate public Servo HTTP app origins on Unix - #1
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Analysis CompleteGenerated ECC bundle from 5 commits | Confidence: 65% View Pull Request #2Repository Profile
Changed Files (78)
Top hotspots
Top directories
Analysis Depth Readiness (evidence-backed, 57%)ECC Tools uses this to decide whether recommendations should stay at commit-history/setup guidance or expand into CI, security, harness, reference-set, AI-routing, and team backlog work.
Reference Set Readiness (1/7, 14%)
Likely Future Issues (4)
Suggested Follow-up Work (4)
Copy-ready bodies test: add regression coverage for crates/turvo/src/lib.rs + crates/turvo/src/servo/embedder.rs ## Summary
- Add regression coverage for the recently touched code paths before more changes stack on top.
## Why
- Backfill regression coverage before another change set lands on the touched code paths.
## Touched paths
- `crates/turvo/src/lib.rs`
- `crates/turvo/src/servo/embedder.rs`
## Validation
- Add or extend focused tests that exercise the touched paths.
- Run the affected test suite and verify the new coverage closes the gap.chore: sync config templates for examples/security/tauri.conf.json ## Summary
- Update the example env files, sample configs, or deployment templates that should mirror the changed runtime configuration surface.
## Why
- Backfill example env files or config templates before a fresh setup drifts from the shipped runtime surface.
## Touched paths
- `examples/security/tauri.conf.json`
## Validation
- Update the repo example env file or config template that should reflect the new runtime settings.
- Run the setup, boot, or deployment validation flow that depends on the changed config surface.ci: add failure-mode evidence for .github/workflows/ci.yml + .github/workflows/integration-lockfile.yml ## Summary
- Add CI failure-mode evidence for the recently changed workflow or test-runner surface.
## Why
- Backfill CI failure-mode evidence before another workflow or test-runner change lands on the touched surface.
## Touched paths
- `.github/workflows/ci.yml`
- `.github/workflows/integration-lockfile.yml`
## Validation
- Add or update a CI failure fixture, captured failing log, troubleshooting note, workflow dry-run evidence, or regression test for the changed CI/test-runner behavior.
- Run the affected workflow or test-runner entrypoint locally or in CI and record pass/fail evidence.chore: refresh lockfile and validate CI after dependency updates ## Summary
- Refresh the lockfile and rerun CI after the dependency or workflow changes in this PR.
## Why
- Package or workflow changes without a lockfile refresh tend to turn into noisy follow-up fixes after merge.
## Touched paths
- `.github/workflows/ci.yml`
- `.github/workflows/integration-lockfile.yml`
- `.github/workflows/servo-integration.yml`
## Validation
- Refresh the lockfile in the same package manager used by the repo.
- Run the repo typecheck / test / CI entrypoints that depend on the updated package graph.Generated Instincts (6)
After merging, import with: Files
|
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 44de561f4c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Url::parse(&format!( | ||
| "{transport}://{}.localhost{}", | ||
| url.scheme(), | ||
| &url[url::Position::BeforePath..] | ||
| )) |
There was a problem hiding this comment.
When a same-origin child frame passes the invoke key to a Worker, this HTTP mapping gives that worker the top document's tuple origin, while SourceTracker::authenticate only rejects client.is_nested_browsing_context; Servo represents workers as non-nested clients, so the worker reaches privileged IPC despite its owning frame being denied. The newly added local-frame-worker probe exercises exactly this path, but no production guard distinguishes a Window from a worker, so tuple-origin mapping should not be enabled until worker callers are rejected or bound to their owning document.
AGENTS.md reference: AGENTS.md:L130-L133
Useful? React with 👍 / 👎.
| git apply --check ../patches/tauri/0002-runtime-http-app-origins.patch | ||
| git apply ../patches/tauri/0002-runtime-http-app-origins.patch |
There was a problem hiding this comment.
When the public integration revision contains any follow-up or otherwise differs from the base plus these two patches, this job still tests a reconstructed tree at the hardcoded upstream base rather than e84733018d84c8004645e04cbc8fea8511ae36b1, which is the revision selected by Cargo.toml and patches/tauri/integration.json. Because the workflow never reads that repository/revision, a green compatibility result does not validate the Tauri source shipped in the runtime; check out the recorded revision and reverse-check the patches (as the Servo lane does), or explicitly compare its tree with the reconstructed one.
AGENTS.md reference: AGENTS.md:L93-L95
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| impl<T: UserEvent> Runtime<T> for Servo<T> { | ||
| const CUSTOM_PROTOCOLS_USE_HTTP: bool = true; |
There was a problem hiding this comment.
When an application embeds an unsandboxed app-origin iframe, opting the runtime into HTTP tuple origins makes that child same-origin with the top document, so it can access window.top.__TAURI__ or window.top.__TAURI_INTERNALS__ even though initialization scripts were not injected into the child. Calling the parent's invoke function executes its fetch in the top-level realm, which presents top-Window provenance and the local origin to both SourceTracker and Tauri, bypassing the nested-client rejection entirely. The local-frame fixture only checks that globals are absent on the child and sends raw IPC from the child realm, so it does not cover this direct parent-capability borrowing path; the top-level API must be isolated from same-origin children or validate the actual caller before frame denial can be claimed.
AGENTS.md reference: AGENTS.md:L93-L95
Useful? React with 👍 / 👎.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
1 participant
Summary
Current proof
Deliberate release boundaries
This PR remains draft while the remaining integration and publication gates are executed.