A dispatch desk submits a packing reference to a server-generated label preview. The form uses target="label-preview" so staff can keep the dispatch screen open. A change adds rel="noopener" expecting to isolate the preview. The important question is whether the next submission creates an isolated context or reuses a window that already has an opener.
Read the result-window attributes together
<form action="/label-preview" method="post"
target="label-preview" rel="noopener">
<label for="packing-ref">Packing reference</label>
<input id="packing-ref" name="packingRef" required>
<button type="submit">Open label preview in a new tab</button>
</form>
The example assumes your application implements /label-preview and accepts the submitted reference. The button warns about another tab, but the target name can refer to a context already open. Inspect the result instead of treating the attribute string as proof of isolation.
For a straightforward new result, target="_blank" states the intent clearly. MDN documents that _blank on a form implicitly provides the same opener isolation as rel="noopener". MDN's noopener reference also describes ordinary nonempty target names as being treated like _blank when choosing a new context. Our existing-window result is a reason to test that path explicitly rather than infer its behavior from the general description.
Choose the interface requirement first. A fresh isolated preview and a persistent named preview window have different navigation behavior. Do not remove opener isolation just to make a tab-count test pass without reviewing the receiving page and the application's communication design.
Separate opener access from the source-address header
noopener does not by itself suppress the Referer request header. Use rel="noreferrer" when this navigation should omit referrer information; that relation also implies the noopener behavior:
<form action="/label-preview" method="post"
target="_blank" rel="noreferrer">
This is an alternative opening tag for the same form. rel accepts a space-separated set of supported relation values. Writing both noopener noreferrer is redundant for opener isolation because noreferrer already includes it. MDN noreferrer reference
Suppressing referrer information does not remove packingRef from the request body. The preview server still receives the fields deliberately submitted to it. Keep the endpoint, data, and access controls appropriate for that task. For broader source-address policy, see HTML referrerpolicy.
Confirm that the application still uses native navigation
The form's rel describes the navigation created by the form. If a submit handler calls preventDefault() and sends fetch, there is no native form-result window for these attributes to configure. A later window.open() call is a separate navigation decision.
Check the activated submit button too. Its formtarget can override the form's target. A “Download label” button and a “Preview label” button can therefore reach different browsing contexts even though they belong to the same form. The native form encoding guide shows the related need to read submit-button overrides rather than inspecting the form alone.
Do not add rel="opener" reflexively when a preview script reports window.opener === null. Determine whether the preview genuinely needs to control or communicate with the dispatch page. If it does, design and test that communication deliberately, including origins and message validation, rather than treating an opener reference as proof of a successful preview.
Check the received result over HTTP
In the local Chrome 155 check, a plain named-target POST opened a window with an opener, and the next POST reused it. Adding noopener while retaining that name still reused it with the opener present. A later _blank submission created a fresh window with window.opener === null. With _blank and noreferrer, the receiving endpoint observed no Referer header while still receiving packingRef=PK-104 in the body. These observations concern that installed browser and disposable same-origin HTTP fixture, not every browser or production service.
Repeat the check with the actual supported browsers and a harmless endpoint before applying the change to the real workflow. Test both a new session and an already-open named target. In each result, inspect window.opener. For a noreferrer case, inspect the request at the receiving endpoint and confirm that the Referer header is absent.
Those are separate observations. No opener reference does not prove that the source address was withheld, and a successful POST does not prove that the label was generated correctly. Finish the dispatch check by confirming the expected packing reference appears in the received preview and that the original form remains available for the next label.