web/: embed the TV's Chromium (libcbe) in a native app

[mariotaku]

Adds a web/ family alongside media/: two samples that link /usr/lib/libcbe.so — the TV's own Chromium, the engine every webOS web app already runs inside — and put a real web view in a native app, with no WAM and no web app package.

web/
  libcbe/    reconstructed headers and the link stub, shared by both
  cbe/       the smallest thing that puts a web page on screen
  hybrid/    SDL2 and a web view in one process, swapping which one is shown

Why this needed reverse engineering

There is no SDK for libcbe. No headers ship on the device or in the NDK, and the library is a stripped 70 MB blob with a C++ ABI. The headers in web/libcbe/webos/ were reconstructed from two sources that agree with each other:

• firmware symbol tables (dev-toolbox-cli/common/data/*/libcbe.so.json), which give every name and signature across every release;
• WAM's own vtables — libWebAppMgr.so contains BlinkWebView and WebAppWaylandWindow, the only in-firmware subclasses, which pin down slot order and object size. operator new(32) followed by a subclass writing its first field at offset 8 says webos::WebViewBase is exactly a vptr plus one pimpl pointer.

Three facts are load-bearing and are commented as such:

• WebViewDelegate has no virtual destructor — adding one shifts every slot by two. WebAppWindowDelegate does have one, so the two classes are not symmetric.
• The delegate is 24 slots, not the 17 with recoverable names. libcbe indexes past them, and a short vtable reads whatever follows it in memory. Leaving them out segfaults a few hundred milliseconds into the first page load, which is how they were found.
• Chromium is built -fno-rtti and exports no typeinfo for these classes, so subclasses must agree.

The shape of the API

WebOSMain() is Chromium's content main: it takes the process over, re-execs the binary for the renderer, owns the message loop, and never returns. There is no "initialise the web view, then carry on".

The seam is the one WAM uses — libcbe pumps the default GMainContext on its browser UI thread, so work queued there before WebOSMain() runs on that thread once Chromium is up. That is where windows and web views may first be created, and it is also how web/hybrid drives SDL: g_timeout_add(16, Pump, ...) polls SDL events and repaints, so both toolkits share one thread and switching views is a plain function call.

webOS 4 only

Both bounds are ABI, not caution. webOS 3's libstdc++ has no GLIBCXX_3.4.21, so nothing can call exports mangled with std::__cxx11::basic_string there without statically linking a newer runtime. webOS 5 replaced the free WebOSMain() with a webos::WebOSMain class and changed WebViewBase's constructor; webOS 6 added a second parallel API under neva_app_runtime. The webos:: API itself is unchanged from 3.4 to 11.2, so a webOS 5+ variant is a small delta rather than a rewrite.

Nothing is bundled: the system libcbe has /usr/lib/cbe/webos_resources.pak compiled in and finds ICU, the V8 snapshots and the locale paks itself.

Verified on hardware

49LK5900, webOS 4.4.3, by display capture rather than by logs alone:

• web/cbe renders a page full-screen at 1920x1080 and registers with LSM and SAM as the foreground card;
• web/hybrid runs both views from one process and switches in both directions, with the page's exit button reaching native code through TitleChanged, and re-entry resuming the suspended page without reloading;
• RunJavaScript() works; LoadExtension("palmsystem") plus a trusted trust level turns delegate slots 19/20 into a synchronous JS↔native RPC (PalmSystem.getResource(...) returned a value produced in C++);
• loading the app's own page.html over file:// needs three settings — without SetAllowUniversalAccessFromFileUrls the renderer is killed mid-load with bad IPC message, reason 114 rather than being told no. SetWebSecurityEnabled(false) is not needed.

Not verified: the remote. Every transition was driven by a test hook calling the same functions a key press calls; synthetic keys via /dev/uinput are not routed to the app by LSM. The SDLK_RETURN and Back paths are wired but unexercised, and both READMEs say so. Lifecycle (SAM relaunch/close, background suspend) is not implemented either.

web/cbe/README.md and web/hybrid/README.md carry the details, including the two heavier JS bridges and why the two-app alternative costs more than it looks.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AYYTWYi9WkpdpJ5EpwZD9i

[mariotaku]

Keyboard focus in the web view: a limitation, and a dead end

Walked the whole sign-in flow on a 49LK5900 (webOS 4.4.3) one remote key at a time, injecting with com.webos.service.networkinput/test/sendKeyCode and comparing frames pixel-by-pixel. The flow works, but not as nicely as it should, and the reason is worth recording before someone else spends the afternoon on it.

What actually happens

step	key (evdev)	result
1	—	native panel, (not signed in)
2	OK 28	→ web view, params handed over in the URL
3	OK 28	nothing — pixel-identical frame, no log line
4	Tab 15	focus → Username, virtual keyboard appears
5	Enter 28	nothing
6	Tab 15	focus → Password, keyboard stays
7	Tab 15	focus → Log in, keyboard dismissed
8	Enter 28	submit → redirect intercepted → signed in as demo

So by remote it is OK, Tab, Tab, Tab, Enter. By pointer it is a single click, because mouse events carry their own target and need no focused element.

Two facts fall out of this that are useful beyond the focus problem:

• Input is exclusive to whichever window owns it. Not one [sdl] key line appeared between steps 3 and 8 — the SDL loop is completely deaf while the web view is up. Leaving the web view therefore cannot be an SDL concern.
• SetUseVirtualKeyboard(true) works, and the VKB behaves properly: up for text inputs, dismissed on a button.

The web view starts with nothing focused

Enter does nothing until Tab establishes focus. Tab is not merely moving focus, it is creating it — and after that, Enter activates a focused button (though it still never submits from a text input).

Three attempts to fix it, all failed:

attempt	result
autofocus on the Log in button	CSS ring appears, Enter still does nothing
webview->SetFocus(true) on show	no change, and Tab stopped rescuing it
page-side .focus() on load	no change

All reverted. The third made things worse and I had stacked the changes without re-verifying between them, so it took a revert to get back to known-good — the committed version does still work as the table above.

My diagnostic was also unreliable throughout: page console.log never reached the log even with --enable-logging=stderr and --v=1, so a keydown logger in the page produced nothing and proved nothing. Worth fixing before the next attempt.

The one real clue

libcbe says so itself:

ERROR:webos_view.h(123)] Not implemented reached in
  virtual void WebOSView::OnWidgetActivationChanged(views::Widget*, bool)

Widget activation is a stub in this build. In Chromium's views that is what hands focus to the FocusManager, so nothing ever becomes the focused element. That fits every observation: pointer fine, keyboard dead, Tab working because focus traversal does not depend on prior activation. If that is the cause, no amount of page-side JavaScript will fix it.

Worth trying next

• SetCSSNavigationEnabled(true) — webOS's own spatial navigation, plausibly the intended focus mechanism on a TV, and exported by libcbe.
• Fix page-console logging first, so the next attempt has a working diagnostic instead of guesswork.
• ForwardWebOSEvent() exists and could inject a synthetic Tab, but WebOSEvent has an exported vtable and no exported constructors, so building one is guesswork of a different kind.

Not blocking the PR: the sample works by pointer, and by remote with the extra Tabs. Flagged here rather than papered over.