Closed tresf closed 9 years ago
It seems to when trying to open a WebSocket.
Error 12029 A connection to server could not be established
@klabarge this could be the intranet zone thing we discussed. Can we verify it works after disabling the checkbox in #67? (Do you have this disabled currently?)
I tested with this setting disabled. I also verified that this setting was changed in internet options, and not just the IE settings.
I tested with this setting disabled. I also verified that this setting was changed in internet options, and not just the IE settings.
I assume your testing still failed? We'll have to do some websocket tests with Edge and find out how to allow this stuff. @klabarge , are you comfortable with researching this, since it is so closely related to the IE11 issue?
@tresf Sorry I was not 100% clear, but yes, the testing still failed. I will dive into this one as well.
In about:flags "Allow localhost loopback" must be checked in order for the websocket to be opened. When this setting is checked, the websocket is opened up properly and QZ Tray seems to function as normal.
Note: the websockets will still be blocked when using the local file system.
Great, thanks!
Next is finding where this is set in the registry, etc so we can flag it with the software.
Edit: The way that I did this with IE was I had to export the HKCU (HKEY_CURRENT_USERS) key for HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\
before and after and then did a diff against these files.
I don't know where Edge stores its registry settings, but if it is in a dedicated area of the registry, we should be able to pull a diff and figure out exactly where this flag resides.
Note, HKLM (HKEY_LOCAL_MACHINE) may have Edge's keys too, but these types of preferences are usually stored in HKCU, or in a preferences file somewhere in %APPDATA%.
Registry setting to allow localhost loopback:
[HKEY_CURRENT_USER\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\ExperimentalFeatures]
"AllowLocalhostLoopback"=dword:00000001
Registry setting to deny localhost loopback:
[HKEY_CURRENT_USER\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\ExperimentalFeatures]
"AllowLocalhostLoopback"=dword:00000000
Thanks, although this scares me: microsoftedge_8wekyb3d8bbwe
.
Can you see if microsoftedge_8wekyb3d8bbwe
or even just 8wekyb3d8bbwe
appears somewhere else in the registry? That looks like a unique identifier, so our script would fail on anyone's PC except yours. :)
Initial support added via https://github.com/qzind/qz-print/commit/b54e9611de45210df43d4106dcec05bdd62926ae.
Kyle, can you try this out? It will require you to check out the 1.9 branch and ant nsis
.
-Tres
Yes, I will test this out and get back to you with the results.
I compiled the latest version and every time QZ Tray is launched, the Allow Localhost Loopback
setting is unchecked.
According to your comments this is the intended behavior:
However, this setting must be checked in order for the websocket to be opened.
Thanks @klabarge. Can you try git pull
and see if this patch https://github.com/qzind/qz-print/commit/706409f08c3e6e77aab25e6101af835f652e21b7 fixes it?
The Allow Localhost Loopback
is now being checked when QZ Tray is launched, which means the websocket connection can be established. :+1:
Thanks for the help :+1:
Closed via b54e961, 706409f
@klabarge FYI, I've tested this fully and Edge 25.10 defaults to allowing loopback connections by default (contrary to the default behavior in Edge 20).
The good news is that this flag is still in the exact same location when set (it is no longer existent by default).
If for some reason a user changes this flag, it will show up and QZ Tray will change it right back using the same logic as above. Fortunately when the registry key is missing the new behavior is to allow loopback connections, so Edge should still be fully supported at the time of writing this. This explains why we haven't had any complains with the recent Windows 10 updates.
@klabarge we should get on this bandwagon soon to see why it won't work.
We've had one client so far with an issue and we're likely to hear from more as Windows 10 auto-updates on more PCs around the globe. :+1:
-Tres