Update setWindowOpenHandler "features" docs

[Prinzhorn]

Description of Change

Since the introduction of setWindowOpenHandler features is no longer parsed but passed as a raw string (see #28518 (comment)). I've switched to JSON to pass data through window.open for my multi-window application. The docs should reflect that this can be an arbitrary string.

Checklist

• PR description included and stakeholders cc'd
• relevant documentation is changed or added

Release Notes

None

[pushkin-]

Huh, do you think it's safe to rely on passing invalid window features (like JSON) into window.open? I'm experimenting with a similar thing where I'm passing custom window features into window.open and intercepting them in the handler in Electron, but I worry that Chrome could make a change to start stripping out invalid features. Not sure if it's safe to rely on those always being filled out - unless the specs guarantee that invalid window features will be kept in the final string.

Though I guess now that I think about it, I'm guessing the features string is exactly what was supplied to window.open with no modifications, in which case this is a non-issue.

[Prinzhorn]

@pushkin- I hope someone from the Electron team can clarify. But I think the point of setWindowOpenHandler is to give us control over window.open. I assume the features string is not even parsed at all, because Electron catches it before Chromium gets a chance to do its thing (that's the whole point of setWindowOpenHandler). So I'd be surprised if the string was manipulated in any way. If Chromium would break this then Electron will unbreak it for us with a patch.

[zcbenz]

/cc people who had worked on the setWindowOpenHandler API @loc @nornagon @VerteDinde

[nornagon]

We currently patch in the raw_features property:

electron/patches/chromium/can_create_window.patch

Lines 64 to 66 in f17e6ae

	+ // Extra fields added by Electron.
	+ string raw_features;
	+ network.mojom.URLRequestBody? body;

I would recommend against passing arbitrary JSON in the features string as the string is parsed by Chromium to determine other features: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/page/create_window.cc;l=69;drc=ce29454af324a1f7b72af4eeed3145c63f9405a9

an arbitrary JSON string may accidentally trigger some of these features unintentionally.

I don't think we should indicate that this can be an arbitrary string.

[Prinzhorn]

Thanks for clarifying!