Are query string parameters passed as IWA URL expected to throw?

[guest271314]

isolated-app://...?key=value

Uncaught DOMException: Failed to construct 'TCPSocket': Frame is not sufficiently isolated to use Direct Sockets.

[reillyeon]

Make sure you've updated to the latest version of this demo as of #17 because we fixed a bug in Chromium and now correctly require an additional permissions_policy declaration. Forcing the manifest to update requires uninstalling and reinstalling the app.

[guest271314]

I don't think that was/is the issue. Though it may have been. I think the issue was loading an inline script in the HTML.

I successfully launched the Isolated Web App (IWA) from an arbitrary Web page using open('isolated-app://<ID>?sdp=<atob((SDP)>') where "SDP" is Session Description Protocol from a WebRTC RTCPeerConnection which creates a WebRTC Data Channel to the IWA (by using WICG File System Access API to read the SDP the WebRTC PeerConnection generates and writes to a local file) wherein I used "externally_connectable" to connect to a local browser extension to launch a local txiki.js TCP server with Native Messaging, whereafter I send messages from the arbitrary Web page to the WebRTC Data Channel in the IWA which writes the message to the writable side of the TCPSocket and sends the result from the TCP socket to the arbitrary Web page.

I was just re-reading this repository and am going to re-read the glitch.me example to implement the glitch.me UDPSocket example from an arbitrary Web page.

Technically I could eliminate the "externally_connectable" and Native Messaging parts if I pre-launched the local TCP server, then use only Web API's without browser extension code to achieve the use case. Right now the local TCP server is dynamically launched and controlled from the IPC messaging between the Web page, IWA, and MV3 extension ServiceWorker, so I can close the TCP connection and close the IWA window I opened entirely from an arbitrary Web page.

[guest271314]

Pardon, I use btoa(<SDP>) from the arbitrary Web page.

[guest271314]

@reillyeon

Make sure you've updated to the latest version of this demo as of https://github.com/GoogleChromeLabs/telnet-client/pull/17 because we fixed a bug in Chromium and now correctly require an additional permissions_policy declaration. Forcing the manifest to update requires uninstalling and reinstalling the app.

Sure would be less tedious to hack together chains of workarounds if "we" (developers; users in the field) could write in that same manifest the origins we want opener to be set in the IWA when we call open(), so we can make use of transferable streams between the IWA and the origins we declare in that manifest which will eliminate multiple steps of workarounds to test and use Direct Sockets (locally and remotely).

[guest271314]

@reillyeon

Keep in mind, what I describe above is only one (1) way I achieved launching and controlling the IWA and Direct Sockets from an arbotrary Web page.

I deliberately wanted to use more Web API's than extension code to achieve the requirement. To demonstrate it's not really possible to completely isolate a window in a browser - not even when using only Web API's to launch, control, and close the IWA. Using navigator.clipboard I can read and write to both contexts. Still more tedious because the document needs to be focused, though possible.

Using only extension code I can achieve the same requirement using a variety of means, as again, the IWA is a window, which I can get the id and windowId of using chrome.tabs.query() or chrome.windows.get(), and other means. With chrome.scripting I can execute scripts in both browsing contexts.

Direct Sockets is supposedly replacing chrome.sockets.tcp. Though should be given to developers and users in the field that want to use Direct Sockets and by virtue how you have decided to marry IWA and Direct Sockets, IWA is a means to an end; to controlled from outside of the IWA when the user is not necessary out to use IWA, rather just Direct Sockets, so your API might suffer for trying to prevent certain use cases when said prevention is essentially impossible - particular where multiple Web API's and extension code can make any claims of true isolation null and void upon testing by parties outside of your system or control.

I would urge you to carefully reconsider including directives and/or flags which provide users a way to define which origins the user decides they want to allow to message the IWA via iframe or open() with postMessage().