I will wait a bit. The issue may be wide spread enough that a new update will be issued that fixes the problem. It is a btrowser issue as far as we can see. And it seems to be an issue with Chromium, not specifically Edge or Windows. Next step is to fire a Linux laptop that I am using as a desktop testbed in my Linux ramp-up project.
1 Like
%22 means "
So the url string becomes inbetween two double quotes
I hope you all know that this does not prevent running the debug app. You just need to fix the URL in the browser.
1 Like
This topic was about the same but he did a fresh install on itâs windows pcâŠ
I am the one who created that case. In the past I had other issues using Xojo to create apps, back in 2018. I had to use a different computer to finish developing a Web App. Both computers were initially running Win 7 Pro and were upgraded to Win 10 Pro.
Steps to reproduce the issue ? Just run the project from the IDE, as simple as that.
So I wiped out the disk and reinstalled Windows 10. At this time I donât have this issue anymore.
But since someone else is having the same issue, I wonder if my Windows 10 was really haunted. Having to reinstall Win 10 from scratch is such a pain. If the issue can be sorted out, I will be happy.
It would appear that the Chromium engine update being rolled out causes problems with various applications. For example, this link.
It is not unique to Xojo. Despite the link stating that .Net applications are affected, the symptoms that are reported are identical to my issue. The version of Chrome that I have today is the same that is mentioned in the link. At this point, I can confirm that all my chromium-based browsers have the same issue: Edge Chromium, Chrome, Vivaldi, Brave. Firefox is not showing the issue. This is a strong indication that the problem is directly related to the Chromium engine on Windows. There is apparently a way to fix that in affected applications, but I wonder if it is worth creating a feedback request for that: by the time the fix gets into a future release, the chromium engine will be updated several times over.
Yes, as @Wayne_Golding indicated, it is just a simple matter of cleaning-up the URL to run the application. I would prefer not having to do that, but for now the workaround works well enough.
Chrome 86 received lots of security patches denying suspicious behaviors, not sure if this is a bug or a planned denial. Google is continuously enforcing https instead of http. Maybe if the url was https instead of http would it work?
Here is one side effect of this new release:
After a bit of research, it looks like the patch needs to be done in Windows anyway, not Xojo. If it were happening in our non-native HTMLViewer on Windows, it would be ours to fix.
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_Araujo 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!
5 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.