The F12 tools should improve how the user-agent override is exposed in two ways.

For Custom, the edit control is too tiny. It should be a large, even multi-line control with wrap. The existing control is too small to see any reasonable user-agent.

For all other selections, F12 doesn't display the value used. My suggestion is to all use the same multi-line control suggested above but that the control is read-only when any value other than custom is selected. Make sure that it is read-only but not disabled so that users can select and copy the value that will be used.

We have a classic desktop application on Windows which needs to communicate with the web browsers. Therefore we created web browser extensions and use the native messaging technology to pass messages between the JavaScript on a web page and the native desktop application. This way of communication is currently supported in Google Chrome, Mozilla Firefox and Opera. Now we want to perform the same task in Microsoft Edge. But unfortunately Microsoft Edge supports native messaging in a different way the other browsers do. In Chrome/Firefox/Opera simply a serialized JSON string can be passed to a native messaging host application via stdin/stdout.

As Microsoft Edge is a Universal Windows Platform Application it only supports communicating with another UWP App via AppService (and further communicating with our classic desktop application via FullTrustProcess). Our classic desktop app cannot be converted to an UWP app for many reasons. Basically this is no problem, but there are some issues I currently don't know how to solve:

UWP Apps seem to require a user interface. But the extension's purpose is only the communication, there is no UI intended.

So I could display some information about the UWP App / Edge Extension when the user opens the UWP app, but if the user closes the App (e.g. by clicking the (X) button), the UWP app process is killed by the system. If this happens during a communication process, the native messaging communication is interrupted and the user will receive an error. So far I have not found a way to avoid this. When Microsoft Edge launches the UWP App (initiated by "runtime.connectNative" in the extension's background JavaScript code) it runs in background mode and will be terminated if Microsoft Edge exits which is OK. But if the user opens the App (e.g. via start menu), the process for the App is reused and it is now running in foreground mode. And then if the App UI is closed by the user, the process which initially was started by Microsoft Edge will be terminated. I have looked at the official "ExtendedExecution" example from Microsoft, but this behaves the same way.

Is there any way to send the UWP App to background mode execution instead of termination if the user closes the UI of the App? So that the App can continue running in background mode as it did before?
Or is there any way to hide the UI in the OnLaunched event (e.g. then our classic desktop app will be opened, and the user will now not be able to manually close the UWP app any more)?
Probably I can find the HWND of the UWP app from our native desktop app and perform some ugly hacks with it, but I definitely want to avoid this.

I have found out, that there is a way to narrow the user's possibility to launch the application by setting AppListEntry="none" in the manifest. So the user cannot start the application from menu anymore.
But the user still can launch the application e.g. by klicking the "Launch" button after installing the app (e.g. side loaded from the appx package).

Any suggestions?

Regards, Dominik

Currently, there is a GPO that would allow admin to set a homepage for MS EDGE, this however locks down the users ability to change the homepage.
When you zoom in to the registry where the homepage is set, it has a warning: It is a violation of Windows Policy to modify. See aka.ms/browserpolicy

Example:

Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\Protected - It is a violation of Windows Policy to modify. See aka.ms/browserpolicy]
"ProtectedHomepages"=hex:01,00,00,00,06,ba,76,4e,b0,08,3e,cc,e2,88,ce,2f,b3,c4,\
19,e7,ae,dc,31,71,c4,30,2c,81,75,60,e5,cb,63,4d,71,ab,8f,12,97,fe,1b,1f,f9,\
5c,4a,e5,c8,72,33,ce,53,b5,c6,5f,e0,de,97,c7,d9,dc,93,3b,24,4d,f8,db,49,e7,\
38,08,06,8f,f5,5e,34,50,27,c7,bb,4f,6c,49,03,ff,ca,8f,1f,48,f6,57,82,00,69,\
2c,4e,0f,b7,2a,c2,25,9e,ba,6d,1a,e9,66,33,24,30,1d,6c,fc,f9,95,c5,f7,b5,a9,\
f5,b2

So, many control environments may want to set a different URL to be the default homepage but want to allow users to change it later on and right now, there is an out of the box way.

You can hack the registry and push and export of what you want from a preset client machine, but there are concerns the way we label the registry with that warning "It is a violation of Windows Policy to modify."

please consider adding ability to add custom headers for handshake. In RFC6455 there one interesting point:

The request MAY include any other header fields, for example, cookies [RFC6265] and/or authentication-related header fields such as the |Authorization| header field [RFC2616], which are processed according to documents that define them. I've found an example how to add custom header to handshake: https://blog.heckel.xyz/2014/10/30/http-basic-auth-for-websocket-connections-with-undertow/ but this is for Java and unfortunately isn't possible in HTML5.

When searching over the net I found many places question about this option, for example: sta/websocket-sharp#22 https://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api/4361358#4361358 aspnet/SignalR#888

For example in Python this is possible https://stackoverflow.com/questions/15381414/sending-custom-headers-in-websocket-handshake. Other languages also support this. Last place missing is the browser.

Currently setting custom headers isn't supported in any browser, as it isn't part of any standard (it is part of RFC 6455 but not part of WHATWG). I've filled feature request in WHATWG (https://github.com/whatwg/html/issues/3062) but I was asked to create feature requests for each main browser. Having Your interest this feature could be added to standard.