iframe_wrapper

Odoo's rich text field is for fragments: a paragraph, a list, some formatting inside a page that already has its own styles. It is the wrong tool for a value that is a complete HTML document, because the document's own styles would leak into the interface around it and its head metadata would be discarded.

This widget solves that by putting the document in an iframe. Inside that frame the document has its own root, its own head and its own styles, and none of it reaches the Odoo page. What renders is what a browser would render if you opened the value as a file.

It is purely a viewer. There is no editing, no toolbar and no way to change the value from the widget; whatever produced the document is responsible for its content.

The use case is previewing something generated elsewhere: a rendered report, a templated email, a supplier's document. Showing it as a fragment inside the form either breaks the layout or misrepresents the output, and both are worse than not showing it.

The constraint worth planning for is sanitization. On an HTML field, Odoo strips markup it considers unsafe, and a complete document is mostly markup of exactly that kind: head tags, style blocks, meta elements. The widget's own source flags this, and the practical consequence is that a preview like this usually needs the field configured to keep its content intact, which is a decision to make deliberately rather than discover.

On a text field

<field name="rendered_document"
       widget="iframe_wrapper"/>

A text field is the simplest carrier, because nothing sanitizes its content.

On an HTML field

# on the model, so the document survives
body = fields.Html(sanitize=False)

Without relaxing sanitization the head and styles are removed before rendering, which is what the source comment warns about.

What it is not

<field name="body" widget="html"/>

The rich text editor, for fragments users edit. This widget is a viewer for whole documents.

The implementation is one effect. When the field's value changes, the widget opens the iframe's document, writes the value into it and closes it. That is the entire rendering path.

Using document.write is unusual enough that the source carries a paragraph justifying it. The argument is that the alternative, building the document through DOM methods, forces the frame to be created with its own html, head and body already in place, so the value would have to be split into pieces and appended individually, which makes attributes on the outermost nodes and complex parsing awkward. Writing the string wholesale sidesteps all of it.

Because the write is inside an effect keyed on the value, a recomputed document does refresh in place, unlike several other viewer widgets in Odoo that read their value once at startup.

Two limits follow from the approach. The frame has no source attribute, so the document runs in the page's own origin rather than sandboxed, and nothing in the widget restricts what the document may contain. That is fine for server-generated content and worth thinking about for anything else.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify this page after the release.

Behavior is unchanged. The write into the frame, the effect keyed on the value and the supported types are all identical. The differences are internal, following the wider component migration.