[robobun]

Element::set_tag_name on an HTML void element (<img>, <br>, <input>, <hr>, ...) rewrites only the start tag. A void element has no end tag in the input, so nothing closes the new name. When a browser re-parses the output, every following sibling becomes a child of the renamed element, and after a rename to textarea, title, style or script the rest of the document becomes its text:

// element!("img", |el| { el.set_tag_name("picture")?; Ok(()) })
"<img src=a.png><p>next</p><p>last</p>"  =>  "<picture src=a.png><p>next</p><p>last</p>"
// element!("br", |el| { el.set_tag_name("textarea")?; Ok(()) })
"<br><p>next</p></body></html>"          =>  "<textarea><p>next</p></body></html>"

The DOM equivalent (createElement + copy attributes + replaceWith) gives an empty, closed element with its siblings intact. The doc comment asks for "the same content model", but the library already knows the element is void (can_have_content() is false), and the caller has no good way to close it: after("</picture>", ContentType::Html) is push_front, so it only works if it is the last after() call across all handlers, it leaves a stray end tag under remove()/replace(), and it is wrong for /> elements in foreign content.

This was found by differential fuzzing of Bun's HTMLRewriter against Chromium: 8 of 12 void-to-non-void renames diverged from the DOM (the 4 that agreed had no following siblings), while 157/157 other renames agreed.

Change

StartTag gets an emit_end_tag flag. Element::set_tag_name sets it when the element cannot have content, is in the HTML namespace, and the new name is not itself a void element name. serialize_self then writes </name> right after the start tag, which puts it before any after() content, and drops a decorative />. Unchanged:

• a rename to another void name (hr -> br): no end tag, </br> would even parse as a second <br>;
• a self-closing element in foreign content (<svg><circle/>): /> closes it whatever it is called;
• remove(), remove_and_keep_content(), replace(): the start tag is not serialized, so neither is the end tag;
• can_have_content() stays false, so prepend/append/set_inner_content remain no-ops and end_tag_handlers() stays None (the written end tag runs no handlers). The rename only keeps the element empty and closed; it does not turn it into a container.

The void-name list moves from selectors_vm::stack::is_void_element to Tag::is_void_html_element so both callers share it (the ESI special case stays in the stack).

Nine existing tests in element.rs rename a matched <img> as a marker (sanitizer_bypass1, void_element, ...); their expectations now include the end tag. New tests cover the cases above in UTF-8 and EUC-JP.

[robobun]

@orium would you have time to look at this one? It comes from the same fuzzing run as #329, #331 and #332 (Bun's HTMLRewriter against Chromium). It changes the emitted bytes in one case only: an HTML void element renamed to a name that is not void. The nine updated expectations are tests that used an <img> rename as a match marker. If you prefer a different shape, for example an opt-in setting, I can rework it. #338 is the related question about ContentType::Text inside <script>/<style>, and it needs only a yes or no on the direction.