Seem MS did something bad trying to comply POSIX, and it affected Chrome, and people are updating the way they invoke browsers to work around this change. http://www.byond.com/forum/post/2624266
Then how come reinstalling Windows 10 (2004) from scratch on my computer and the applied patches solved the issue ?
Tuesday patch day is tomorrow, hope they will not break it back or worse ?!?
your’s may have been the same symptom but a different root cause. Let’s hope chromium or Windows, whichever, get a fix. Otherwise, it may fall on Xojo to do it differently. TheBrain created a fix for their application. So it is not necessarily just an OS/browser issue, perhaps a coding workaround can be done also as @Rick_A is suggesting.
Both BYOND and Brain had written workarounds for the problem. Byond said there were shell execution registry entries that needed adjustments or the surrounding quotes would be sent as part of the URL. Maybe starting fresh as you did removed such keys and they were set to the proper values the current behavior MS expects? Seems they needed to remove “–single-argument” from some key(s) affecting Computer\HKEY_CLASSES_ROOT shell entries for Chrome? Someone affected could research a bit about it and bring us details.
I’m running 2019r3 and I went into Regedit and changed these settings:
Computer\HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command
“C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” --single-argument %1
Computer\HKEY_CLASSES_ROOT\MSEdgeHTM\shell\open\command
“C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe” --single-argument %1
I removed the “–single-argument” parameters so they looked like this:
Computer\HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command
“C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” %1
Computer\HKEY_CLASSES_ROOT\MSEdgeHTM\shell\open\command
“C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe” %1
That has fixed it for me!
4 Likes
I confirm, that the fix works.
Vivaldi is a bit different. the key on my computer is: Computer\HKEY_CLASSES_ROOT\VivaldiHTM.OWYRV4DYW5ULUCXVFI6KVCVRTA
and the key to change is:
“C:\Users\Louis\AppData\Local\Vivaldi\Application\vivaldi.exe” – “%1” (your’s will be different). I changed it to
“C:\Users\Louis\AppData\Local\Vivaldi\Application\vivaldi.exe” %1.
All three browsers now behave as expected.
Thank you @Jim_Brock!
1 Like
I also experienced the problem this morning. The quick workaround was to add a new link on my bookmark bar which quickly launched the app in the debugger. Came back from lunch, and the app no longer launched Chrome. Started Chrome manually and clicked my bookmark. Got “This site can’t be reached. 127.0.0.1 refused to connect.” Found this thread and made the registry changes suggested, but got no improvement.
I did make the changes to an old laptop and it appears to be working properly now after suffering the same problem when I first started it up this afternoon.
127.0.0.1 refuses to connect: The web application is not running, so you cannot connect to it. This could be that you already had an IDE session active. Now since Web 2.0, when I exit one session - the only one running of course, I always have to stop the IDE manually or litterally wait for several hours before it closes on its own. While it seems to be running, you cannot connect to it. Once you stop it and then restart it, it is OK.
I can’t even connect immediately after a reboot. If I open an API 1.0 app with Xojo 1019r1.1, it will run in the debugger. If I create a new API 2.0 app with one control on a page and run it, it works. None of my other new apps work though. If I compile the app and run it, I still can’t connect.
Then I would suggest to put “system.debuglog” lines at the beginning and end of each event handler and method, especially those that are executed early on in the launch of the program. You will at least be able to figure out in what part of the program resides the problem. My first guesses would be a closed loop or the notorious slowness of Web 2.0 with more complex pages. I am redesigning a page that includes several webcontainers, each with several controls. In 2019 R3.1, that page loads in the blink of an eye. The same page takes almost 45 seconds to load in 2020 R1.2 and even so, only partially. It takes another 15 or so before it is completely rendered. Popupmenus are especially slow as are webcontainers with anything meaningful included. Add even more if you need to spawn a webdialog (a search help for example).
I think my problem is a Windows problem. I copied the program to an old laptop that has not updated to rev 2004 yet and the program works there. On the other hand, when I run an old web app under Xojo 2019r1.1, it runs correctly. I restored a backup copy of my new program from 6 days ago that ran fine at the time and it won’t launch the browser. After compiling and running the program, the browser still does not see it. Interesting that in TaskMaster, both Xojo and the running app use the same percentage of CPU (about 18%) and the two fluctuate together.
then perhaps just a reinstall of Xojo 2020R1.2?
It started doing this under 2020R1.1 so I updated and got the result. I just ran same program under 2020R1 and it has same problem.
Problem was me and not Windows. There was an endless loop in the app.Opening. Thanks to Louis D. for pointing me in the right direction.
Same issues with me. Tried disabling everything. Running on 3 Pc’s all with the same issue
worked!
thanks!
what confuses me is, why not yesterday and yes today? what changes this settings?
regards
You simply received an update to the Chromium engine (either with Chrome, Edge Chromium, Brave, Vivaldi or another browser using the Chromium engine). This is what caused the issue.
It works for me too but by editing the value for the entries, I can no more open pdf directly from my emails. It seems that chrome can’t recognize spaces in the link (spaces in my PC user Name, or the document name). If I change back to the original Registry Entries, pdf works fine again but Xojo IDE fails to load the running page.
Anyway that document opening from email and Xojo IDE loads can work at the same time?
Alas not.
This is a change implemented in 86. to patch a security risk, changing registry entries is not the way around this issue as it will just re-expose you to those risks, the marked solution should be unmarked as it will lead to a compromised system.
The change is documented here https://chromium.googlesource.com/chromium/src/+/036150cfca14e4f91b7f06855b19462575aed37f and was a correction of an attempted earlier fix.
I’ve done a quick check all the way back to 2016r4.1 and they all now fail when running a web project. This is the way things will be going forward and it’s an issue that Xojo needs to now address. I’m not sure how you’re going to address the legacy issues with this one.
The issue is as follows:
Xojo has been surrounding its shell open url with quotes e.g.
"http://127.0.0.1:8080/"
this is then passed to Computer\HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command on a shell open request which used to be:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -- "%1"
so the file being run with command line params was:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -- ""http://127.0.0.1:8080/""
note the double quotes, this just happened to not matter and everything worked ok.
The error here was that the quotes are not required around the url as they will be quoted anyway when the %1 is replaced with the url.
The problem now occurs because you’re adding quotes which are no longer required and probably shouldn’t have been added in the first place (unable to confirm with 100% certainty as I don’t know when or if %1 was ever changed to “%1”, I’ve checked a really old VM and its quoted there so who knows, maybe it wasn’t in the dark ages, but I digress).
So now you’re sending a quoted url to a system that isn’t expecting quotes and its instantly encoding those to ensure that nothing nefarious is taking place which causes the whole problem.
You can test this by throwing the following into a command line and watching the reproduction of the problem:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --single-argument "http://127.0.0.1:8080/a b/"
where as the following works:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --single-argument http://127.0.0.1:8080/a b/
I’ll let someone else put the ticket in as I’m no longer reporting bugs.
Also, someone at Xojo might want to raise a ticket with chromium mentioning that previously (erroneously?) quoted urls are failing after the change which could stealth break a load of legacy apps so they might want to check that out.
4 Likes