Test: Comprehensive JS event tracking for lifecycle states

[jellefoks]

This PR enhances the test_lifecycle.sh integration test to actively monitor and verify standard DOM lifecycle events (focus, blur, freeze, and unfreeze/resume) during Starboard OS state transitions.

Key Additions & Robustness

• Monitoring focus/blur and freeze/unfreeze: Injects a JavaScript event logger (window.event_log) via DevTools to actively record focus, blur, freeze, resume, and visibilitychange events dispatched by the application. This ensures that the web application receives the proper standard Web APIs signaling when the underlying platform transitions between states.
• Deterministic Event Queuing: Replaces brittle sleep-based timing with a deterministic "pop-from-front" array queue approach. The test explicitly waits for the array to populate and pops each expected event individually, ensuring that the correct sequence of events is fired.
• Robust Load Environment: The test now relies on a base64-encoded data:text/html URL payload using a simple HTML string. This completely bypasses QuotaDatabase IO locks, ServiceWorker database conflicts, and complex JavaScript garbage collection crashes (often seen when testing against heavy remote origins like YouTube TV), ensuring reliable testing of the underlying event delivery without temporary file conflicts.
• State Verification: Validates that document.hasFocus() and document.visibilityState accurately reflect the true lifecycle state prior to verifying the individual dispatched events. We're testing more comprehensively and more reliably.

Bug: 448156280

[github-actions]

🤖 Gemini Suggested Commit Message

---

test: Verify lifecycle JS event dispatch

This change enhances the lifecycle test script to track and verify
JavaScript events during Starboard lifecycle transitions. It injects
an event logger into the DOM via CDP and uses a robust polling mechanism
to assert the correct dispatch of visibilitychange, focus, blur, freeze,
and resume events.

This improves test coverage and reliability for critical lifecycle
event handling, ensuring Cobalt behaves as expected when responding
to system-level state changes.

Bug: 10008

---

💡 Pro Tips for a Better Commit Message:

1. Influence the Result: Want to change the output? You can write custom prompts or instructions directly in the Pull Request description. The model uses that text to generate the message.
2. Re-run the Generator: Post a comment with: /generate-commit-message

[gemini-code-assist]

Code Review

This pull request enhances the lifecycle testing tools by introducing a more robust event-driven verification mechanism. Key changes include updating cdp_js_helper.py to support remote hosts and polling for readiness, and modifying test_lifecycle.sh to use a local HTTP server and an injected event logger for precise state transition tracking. Feedback focuses on improving time measurement reliability in Python, addressing potential port conflicts and remote testing limitations in the shell scripts, and refining process termination and string matching logic for better stability.

[gemini-code-assist]

Using asyncio.get_event_loop().time() is generally fine within a running loop, but time.monotonic() is the standard and more robust way to measure elapsed time for timeouts in Python, as it is independent of the event loop state and clock adjustments.

[gemini-code-assist]

The HTTP server is started on a hardcoded port (4000). This can cause conflicts if multiple instances of the test are run on the same machine or if the port is already in use. Additionally, the cleanup logic at the start of the script (lines 25-41) does not check for or terminate stale HTTP server processes from previous failed runs, which could lead to the new server failing to start.

[gemini-code-assist]

The --url is hardcoded to 127.0.0.1. If the test is run against a remote device (by setting TEST_LIFECYCLE_HOST), Cobalt running on that device will attempt to connect to a server on its own loopback interface rather than the machine running this script. Consider using the actual IP address of the host machine or making this configurable to support remote testing scenarios.

[gemini-code-assist]

Using kill -9 (SIGKILL) for the HTTP server is unnecessary as a first resort. It's better to use SIGTERM (the default for kill) to allow the process to exit gracefully. This applies to both instances where the server is terminated (lines 144 and 148).

Suggested change

	kill -9 $SERVER_PID 2>/dev/null || true
	kill $SERVER_PID 2>/dev/null || true

[gemini-code-assist]

Using kill -9 (SIGKILL) for the HTTP server is unnecessary as a first resort. It's better to use SIGTERM (the default for kill) to allow the process to exit gracefully.

Suggested change

	kill -9 $SERVER_PID 2>/dev/null || true
	kill $SERVER_PID 2>/dev/null || true

[gemini-code-assist]

The transition from an exact match to a substring match ([[ "$RESULT" == *"$EXPECTED"* ]]) is risky and can lead to false positives. For example, if the expected state is visible, this condition would incorrectly pass if the result is an error message containing that word (e.g., ERROR: visible state not reached). Since cdp_js_helper.py now returns clean string representations of the values, an exact match is safer and more reliable.

Suggested change

	if [[ "$RESULT" == *"$EXPECTED"* ]]; then
	if [ "$RESULT" == "$EXPECTED" ]; then