guideXOS Navigator Browser

Purpose: describe what the current browser stack can do today, and where it is still intentionally limited.

guideXOS Server Wiki

Browse the Server branch documentation by topic.

Reading status labels

Implemented Partial Experimental Planned Not Yet Verified

guideXOS Server is moving quickly, so each page calls out what is present in the current Server source tree, what is partially wired, what is experimental, and what remains roadmap work.

Navigator is real, not just a placeholder

The repo contains a substantial navigator.cpp implementation plus HTTP and HTML parsing helpers. Built-in app metadata marks guideXOS Navigator as available in both hosted and bare-metal paths, and hosted smoke diagnostics in server.cpp exercise Navigator behavior in detail.

Current status: functional browser work with clear hosted validation. Known gaps: HTTPS remains environment/policy gated; JavaScript and full parity across environments remain outside the current milestone. Back to /Wiki/Server

guideXOS Navigator in the current hosted desktop environment.

Capabilities visible in current source

Capability	Status	Notes
HTTP text document fetching	Implemented	`guide_web_http.h` exposes plain `http://` GET/POST support for text documents.
URL parsing and relative link resolution	Implemented	HTTP URL parsing and forgiving relative-link resolution are explicit in the code.
HTML subset parsing	Implemented	Parser supports headings, paragraphs, links, lists, pre/code, forms-lite controls, images, and embedded style blocks.
Forms-lite	Partial	Hosted smoke diagnostics explicitly mention GET forms and hosted POST behavior, while also documenting bare-metal POST as unsupported.
Bookmarks and find-in-page	Implemented	Hosted smoke diagnostics call both out as active capabilities.
Remote images and local PNG support	Partial	Navigator source and hosted smoke diagnostics show image handling work, but with explicit limits and safety caps.
TLS / HTTPS	Policy / environment gated	Hosted Navigator uses Schannel; the bare-metal path requires secure entropy and other validated TLS prerequisites.
JavaScript, cookies, compression, caching	Planned / Out of scope	These are explicitly outside the current milestone in the HTTP layer comments.

Hosted path

Best-evidenced mode today. Hosted diagnostics in server.cpp explicitly test Navigator window creation, toolbar widgets, HTTP, file pages, CSS-lite, forms-lite, and link behavior.

Implemented

Bare-metal path

Navigator is registered as available in bare-metal metadata and kernel app registration, but detailed parity with hosted behavior should still be treated carefully.

Partial

HTTPS/TLS and secure entropy

Navigator's HTTPS/TLS path is different from plain HTTP. Mbed TLS / PSA crypto must receive cryptographically secure random data before TLS operations can safely proceed. The supported bare-metal OS random path currently consumes QEMU's transitional PCI virtio-rng device when the launcher exposes it. Without secure entropy, crypto initialization and TLS fail closed rather than falling back to timer values or deterministic pseudo-random data.

QEMU may therefore establish the entropy prerequisite for HTTPS in a way that a physical machine currently cannot. This is a hardware-like virtual RNG source, not TLS emulation or a bypass. See Build and Testing for the exact QEMU arguments and troubleshooting markers.

HTTP does not require the RNG. HTTPS also depends on the current trust-store, wall-clock, hostname-validation, and policy checks, so a working HTTP connection does not prove that TLS is ready. Broader bare-metal HTTPS remains fail-closed until the complete validated policy is active.