Linux: stock cefsimple navigation stalls before document load on Ubuntu 26.04 under Xvfb

[Nevioxis]

Describe the bug

Stock cefsimple opens a window but does not complete document navigation under Ubuntu 26.04/Xvfb.

For loopback HTTP/HTTPS navigation, CEF creates TCP connections and, with HTTPS, completes TLS handshakes, but an instrumented fixture receives no HTTP plaintext bytes or request lines during a bounded nine-second observation.

A separate external HTTPS control against https://example.com/ progresses further: CEF creates a main-frame URL_REQUEST and completes TLS connections, but records no HTTP header events and does not complete the page load within the same observation period.

The original loopback behavior reproduces with CEF 151.3.24 and CEF 146.0.12 in the same Linux VM. A CEF 151 regression has therefore not been established.

To Reproduce

1. Build stock cefsimple from the official Linux x64 CEF standard distribution with USE_SANDBOX=ON. Configure the supplied chrome-sandbox as root:root, mode 4755.
2. Start Xvfb with a 1024x768x24 display and select that display.
3. Start a loopback HTTP fixture:
   • /redirect redirects to /final.
   • /final returns a small HTML page with status 200.
4. Verify that Python urllib can fetch /final.
5. Run:

cefsimple \
  --url=http://127.0.0.1:<port>/redirect \
  --no-first-run \
  --disable-gpu

6. Observe the window and fixture for nine seconds. Repeat with --use-native.
7. Repeat with HTTPS, using a fixture CA trusted by the OS and NSS stores.

Original stock-sample results:

CEF 151.3.24 / HTTP
- Views:  3 TCP accepts, 0 recorded HTTP GETs
- Native: 3 TCP accepts, 0 recorded HTTP GETs

CEF 151.3.24 / HTTPS
- Views:  3 TCP accepts, 2 TLS handshakes, 0 recorded HTTP GETs
- Native: 3 TCP accepts, 2 TLS handshakes, 0 recorded HTTP GETs

CEF 146.0.12 / HTTPS
- Views:  3 TCP accepts, 2 TLS handshakes, 0 recorded HTTP GETs
- Native: 3 TCP accepts, 2 TLS handshakes, 0 recorded HTTP GETs

The original fixture counted GET handlers only. Follow-up instrumentation described below closes that measurement gap for new CEF 151 runs.

Adding --disable-request-handling-for-testing to the CEF 151 HTTPS runs produced the same original counts in both modes. The switch did not change the observed behavior; this does not establish which internal component is responsible.

Expected behavior

cefsimple should request /redirect, follow the redirect to /final, and display the returned page.

Instead, loopback navigation does not produce a document request at the fixture during the bounded observation. Native mode opens an Untitled - Chromium window.

Additional diagnostics

All-method and plaintext-byte loopback observation

The loopback fixture was instrumented to record:

• every parsed request method and raw request line;
• plaintext bytes received before HTTP parsing, after TLS decryption for HTTPS.

The observer self-check successfully detected:

• an OPTIONS /observer-check request;
• an incomplete OPTI request.

Python successfully fetched /final before each browser run. Those preflight connections were excluded from the browser counters.

Stock CEF 151 results over nine seconds:

HTTP / Views
- 3 TCP accepts
- 0 plaintext bytes
- no request lines

HTTP / Native
- 3 TCP accepts
- 0 plaintext bytes
- no request lines

HTTPS / Views
- 2 TCP accepts
- 2 successful TLS handshakes
- 0 plaintext bytes
- no request lines

HTTPS / Native
- 3 TCP accepts
- 2 successful TLS handshakes
- 0 plaintext bytes
- no request lines

No OPTIONS or other HTTP method was hidden by the original GET-only counter in these new runs.

This claim is limited to plaintext bytes received by the fixture during the bounded observation.

External HTTPS control

Stock CEF 151 cefsimple was also run against:

https://example.com/

in both Views and native modes, using the same Xvfb environment and retaining:

--no-first-run
--disable-gpu

Sandboxing remained enabled.

Python fetched https://example.com/ successfully with status 200 before each CEF run.

Neither CEF run displayed the Example Domain page within nine seconds. Native mode remained Untitled - Chromium.

Unlike the loopback traces, both external-run CEF netlogs contained a main-frame URL_REQUEST_START_JOB for https://example.com/ and recorded two successful TLS connections.

However:

• no recorded target-request NetLog event contained an HTTP header event;
• no completed page load was established;
• the target request's captured progression ended after COMPUTED_PRIVACY_MODE.

The external case therefore progresses further than the loopback case but still does not complete document loading.

The netlogs also contain connection-refused attempts, so this diagnostic does not isolate a particular failing component.

SIGTERM was used after the bounded observation and left the NetLog files without their final JSON delimiters. The original files were retained; only the missing delimiters were reconstructed in memory for analysis. No events after termination are claimed.

Screenshots

No screenshots attached. Exact command lines, X11 window observations, fixture counters, plaintext/request-line observations, callback logs, and NetLogs were captured.

Versions

• OS: Ubuntu 26.04.1 LTS, x86_64, disposable VM
• Kernel: 7.0.0-31-generic
• Display: Xvfb, 1024x768x24
• Compiler used for both CEF 151 and CEF 146 sample builds: /usr/bin/c++
• Compiler version: c++ (Ubuntu 15.2.0-16ubuntu1) 15.2.0
• CEF binary version: 151.3.24+g2384915+chromium-151.0.7922.174
• CEF revision: 2384915b7b1f0fe5ad1107e48d80c34e86b698d7
• Comparison version: 146.0.12+g6214c8e+chromium-146.0.7680.179

The compiler version was verified from the CMake compiler metadata for both sample builds.

Additional context

• Same-version CEF sample: Reproduces with stock cefsimple in both Views and native-window modes. cefclient has not been tested.
• Same-version Google Chrome: Not tested.
• The same minimal CEF client source was built against both SDKs. It reproduces the loopback failure with HTTP and HTTPS, including in a mode without request handlers.
• In the instrumented minimal client, loopback navigation reaches OnBeforeBrowse but does not reach OnBeforeResourceLoad.
• When navigating from about:blank, the main-frame URL remains about:blank.
• An earlier CEF 151 minimal-client loopback NetLog showed target preconnect activity without a page URL_REQUEST.
• The newer external HTTPS control differs: it does create a main-frame URL_REQUEST, but no completed HTTP response/page load is observed.
• No --no-sandbox switch was used.
• No certificate-verification-bypass switch was used.
• No NetworkServiceSandbox override was used.
• Without --no-first-run, CEF 151 displayed a Chromium terms window. That initial run was treated as inconclusive.
• These results do not establish a loopback-only or Local Network Access-specific problem.
• These results do not establish NetworkServiceSandbox as the cause.
• These results do not establish a CEF 151 regression.

Question for CEF maintainers

What could allow stock cefsimple and a minimal CefClient to create a browser and begin network navigation, but fail to complete the document request?

In loopback tests, CEF establishes TCP/TLS connections but sends no HTTP plaintext during the bounded observation. In an external HTTPS control, CEF creates a main-frame URL_REQUEST and completes TLS, but no HTTP header events or completed page load are observed.

Is there a known Ubuntu 26.04/Xvfb startup, sandbox, session, or command-line requirement that could explain this behavior?

The identical loopback behavior on CEF 146 and CEF 151 does not establish a CEF 151 regression.

The reproduction steps, commands, measurements, and reported results were executed and verified by the reporter. AI tools assisted with diagnostic planning and editing of this report.

Assisted-by: OpenAI Codex
Assisted-by: ChatGPT

[magreenblatt]

Try running with --no-sandbox --disable-dev-shm-usage

[Nevioxis]

@magreenblatt I tested the suggested flags in the disposable Ubuntu 26.04 VM.

With stock CEF 151 cefsimple:

--no-sandbox --disable-dev-shm-usage

did not restore navigation. Both Views and native modes still established TLS connections but recorded 0 GETs.

I also repeated the test with the minimal client. Its frozen diagnostic build intentionally rejects --no-sandbox, so I made a separate disposable copy whose only functional changes were:

• CefSettings.no_sandbox = true
• adding --no-sandbox --disable-dev-shm-usage

All three minimal-client modes still failed with the same bounded result 124:

bare:         2 TCP, 2 TLS, 0 GET
instrumented: 2 TCP, 2 TLS, 0 GET
direct:       3 TCP, 2 TLS, 0 GET

The full Chromium-only integration test also still timed out during navigation after 5 seconds. The fixture received only the Python preflight GET /final; no browser GET /redirect arrived.

So disabling the sandbox and adding --disable-dev-shm-usage did not change the observed failure in this VM. This makes sandboxing or /dev/shm handling alone insufficient to explain it, although I am not ruling out other Linux/Chromium runtime interactions.

[magreenblatt]

Your next test should be with vanilla Chromium to see if it has the same issue.

[Nevioxis]

@magreenblatt I completed the follow-up investigation and found an environment/session cause for the navigation delay in this Ubuntu 26.04/Xvfb VM.

The original 9-second observation was reproducible, but longer runs showed that this was not a permanent navigation deadlock. In the affected session, stock CEF 151 eventually sent the target request after roughly 25 seconds.

The important difference was that the browser shell had a valid Xvfb DISPLAY, while the systemd --user service manager did not. In that state xdg-desktop-portal-gtk could not open the X display.

Publishing the same active Xvfb display before browser launch:

systemctl --user import-environment DISPLAY

removed the abnormal delay.

I repeated this as a controlled A/B/A/B test using the same stock CEF binary, profile, flags, Xvfb display, fixture socket, and exact URL:

DISPLAY absent:     first GET 25.553 s
DISPLAY published:  first GET  0.439 s
DISPLAY absent:     first GET 25.391 s
DISPLAY published:  first GET  0.465 s

Portal units were reset between the legs.

With the corrected session, stock CEF 151.3.24+g2384915+chromium-151.0.7922.174 passed all eight loopback combinations:

• HTTP / HTTPS
• direct / redirect
• Views / native

First target requests occurred in 0.518–2.044 seconds. Redirect cases reached /redirect and then /final, expected page titles appeared, and trusted HTTPS worked without certificate bypasses or sandbox-disabling flags.

External https://example.com/ also loaded normally. The previous roughly 25-second NetLog gap before NETWORK_DELEGATE_BEFORE_START_TRANSACTION fell to approximately 108–150 ms in the configured runs.

The unchanged minimal CEF probe also passed all 12 tested mode/protocol/flow combinations without the previous bounded 124 result.

I additionally tested standalone Chromium distributions. Chrome for Testing 146.0.7680.179, 151.0.7922.174, and 153.0.8010.47 all showed delayed/failing behavior in the original session state, but loaded the tested loopback and external targets promptly after DISPLAY was imported into systemd --user. Ubuntu's Chromium snap 153.0.8010.47 behaved differently and was already fast for HTTP/external HTTPS, so Chromium engine version alone does not explain the original behavior.

No CEF or application source change was required. I did not use --no-sandbox, --ignore-certificate-errors, a NetworkServiceSandbox override, or a CEF pin change.

Based on these results, the actionable cause of the navigation delay in this reproduction was the incomplete Xvfb/user-session setup: services activated through the user service manager could not see the browser's X display. I don't currently see evidence that a CEF source patch is justified.

The precise internal Chromium/portal callback responsible for the ~25-second wait has not been traced, so I am limiting the conclusion to the demonstrated environment-level cause.

Thanks for pointing me toward the standalone Chromium comparison; it helped narrow this down considerably.