Skip to content

[WIP] Fix failing GitHub Actions job 'build' - #1

Closed
velzie with Copilot wants to merge 1 commit into
masterfrom
copilot/fix-github-actions-build-failure
Closed

[WIP] Fix failing GitHub Actions job 'build'#1
velzie with Copilot wants to merge 1 commit into
masterfrom
copilot/fix-github-actions-build-failure

Conversation

Copilot AI commented Jun 20, 2026

Copy link
Copy Markdown

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Fix the failing GitHub Actions job "build"
Analyze the Actions logs, identify the root cause of the failure, and implement a fix.
Check run ID: 82262421160
Job URL: https://github.com/HeyPuter/firefox-wasm/actions/runs/27798164994/job/82262421160

Copilot AI requested a review from velzie June 20, 2026 17:15
Copilot stopped work on behalf of velzie due to an error June 20, 2026 17:15
@velzie velzie closed this Jun 20, 2026
@velzie
velzie deleted the copilot/fix-github-actions-build-failure branch June 20, 2026 17:18
codebutler pushed a commit to codebutler/firefox-wasm that referenced this pull request Aug 11, 2026
An embedder had no way to know when pixels first reach the canvas. `load()`
resolving means the DOCUMENT finished loading, and in GPU mode WebRender
presents autonomously off the refresh driver — so a window sits blank for as
long as RenderThread's device init takes (3.1–4.5s measured under software GL)
with nothing to wait on. That reads as a broken embed, and the only workaround
available downstream was a settle timer, i.e. a guess.

gl_present_yield is the one place that observes the present: the browser
implicit-presents during the macrotask it yields for, so by the time its
setTimeout callback runs, that frame is up. It now reports each present to the
main thread via emscripten's CMD_CALL_HANDLER (whose dispatch is
per-instance-correct, so two embedded instances on a page don't cross wires),
and Gecko exposes `firstPaint`.

Picking WHICH present means "there is content" took three traces, and both
obvious rules are wrong:

  A: present HeyPuter#1 t=27.6s, load stop t=27.8s, present HeyPuter#2 t=29.3s
  B: load stop t=24.2s, present HeyPuter#1 t=27.5s, present HeyPuter#2 t=29.8s
  C: load stop t=50.8s, present HeyPuter#1 t=55.3s, present HeyPuter#2 t=58.1s

"First present" is blank in A. "First present after the load settles" is blank
in B and C, where that present IS HeyPuter#1. The invariant across all three is that the
compositor's opening present is a device-init frame carrying no content, so
firstPaint requires BOTH: the load has settled AND the present index is >= 2.
The >= 2 is empirical, not derived — Gecko exposes no first-contentful-paint to
an embedder — and it is commented as such rather than dressed up.

Reporting stops after PRESENT_REPORT_CAP presents so a long-running engine isn't
posting a message per frame forever; reaching the cap resolves firstPaint anyway,
so a pathological first load degrades to "uncover" instead of wedging an embedder
that awaits it. GECKO_PRESENT_DEBUG logs the trace that produced the table above.
Software mode never presents this way and resolves once the engine is up.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants