Flipnote Hatena has a specialised browser with its own document structure, text parser, URL handling and remote-preview routines. The research follows what happens after a link is selected: the request, response parsing and creation of the visible controls. Its behaviour differs from a desktop browser. [1]
Pages have several layers
A response may contain textual records, links, metadata and image resources. The client creates internal document objects and connects them to scene controls. Embedded preview assets are interpreted separately from the link or action that opens a Flipnote. Studying the visible page alone can miss a server metadata action behind it. [1][2]
See UGO menus for structured menu resources and the client for route selection. The public wiki also documents web-client commands and authentication, but those pages describe the historical service and should be checked against the particular build being emulated. [2]
Document allocation
The examined V2 document parser allocates 1,024 records of 44 bytes, 512 styles and a 64 KiB text pool, plus head metadata. It tokenises response text, resolves URLs, applies style and element attributes, then connects resulting nodes to page controls. These numbers are original-program observations for the studied V2 path, not generic HTML limits. [1]
Supported document features
The rewritten document routines handle links, class and inline attributes, titles and some table/body structures. The comparison tests still use original code for images, floats and some table handling; complete CSS fetching and cascading have not been recovered. Test pages on the DSi client, because a page that works in a modern browser can still fail there. [1][2]
Remote previews
Fetching a PPM takes a download and file-commit path before frame decoding. A partial HTTP body cannot safely become a local note. Separate the list's TMB or other preview image from the PPM's own thumbnail and from the full animation. [1]
Debugging an empty page
Check method and route, response type, declared length, parse success, document allocation, image resources and final scene dispatch in that order. “HTTP 200” confirms only the network status; it does not prove that the client accepted the document or placed any nodes on screen. [1][2]
Browser-specific HTML metadata
Use uppertitle, uppersubleft, uppersubright, uppersubtop and uppersubbottom for top-screen headings, side labels and boxed text. An upperlink to an NBF or PPM replaces that text with an image. A separate background entry supplies a lower-screen image and its dimensions. The wiki warns that this lower-screen file can have an .nbf suffix while requiring NPF data, with an 8 × 8 size limit in that use. Test the bytes on the client rather than choosing a decoder from the extension alone. [3]
Head metadata also controls playback and page actions. playcontrolbutton enables the player, savebutton supplies the PPM download URL, and autoplay starts playback. Comment, post, favourite, unfavourite and delete buttons each have a named meta field containing their action URL. Yellow stars use starbutton; green/red/blue/purple use starbutton1 through starbutton4, with the colour and wallet count in the value. The wiki also documents an autoscroll flag and a flag for fixed built-in background music. Studio handles these commands itself; desktop browsers do not implement them. [3]