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
1 Like
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 036150cfca14e4f91b7f06855b19462575aed37f - chromium/src - Git at Google 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
I have unmarked the solution. Pending a fix from Xojo, the following workaround may be used with some associated risk:
2 Likes
I have added a link to your post to the FB case.
From what I see, a bunch of other devs have already been posting about this issue with the Chromium team on their tracker.
1 Like
si funciona
it works perfect, but now the question that raises is, why does the register changes in the browser call?
regards
As Julian said:
please don’t change your registry to “fix” this problem.
Feedback case: 61634 already marked as fixed. It looks like the next version of Xojo will have this.
1 Like
If they released the fix, would that have been one of the fixes released in 2002r2?
I filed a Feedback case today not knowing the issue was already raised.
<https://xojo.com/issue/63366>
Choosing my default app as FireFox fixed the issue for me.
LOL That is still a problem. Many users are left with an old version to use web 1.0.
There are many work arounds, but that is not the same as a “Fix”
In my case, I have a button in the favorites bar of chrome with the correct URL, so, when Xojo displays the wrong one I just simply click the button.
1 Like
Awesome, I am porting over all of my apps to 2002r2.
Some other, really important, code is broken in production apps published with prev versions so am having to apply fixes.
Email code took me literally all day yesterday and darn near all of today to fix.
http://%22http//127.0.0.1:8080/%22"
This issue started happening to me this week running 2020R3.2 on Windows 10 and Windows Server 2019 Datacenter, but I can work around it by editing the URL and hitting return. I insert the cursor between / and 1 and then backspace to remove %22http// then I insert the cursor after the quote and backspace to remove %22" and then press enter and my app will launch.
If this was supposed to be fixed in 2020R2 then I’m not sure why I’m having this issue with 3.2
1 Like
Because there is no 2020r3.2
2019r3.2 is older than the fix.
1 Like
Doh! Well it’s late in the day for me and I think my brain gave up after scrolling trough this thread, especially since we are now in 2021 and I can’t convert my Web apps to Web 2.0 because reasons. I’ll go crawl back into my hole now.
drags knuckles as he slowly slinks off into the shadows
1 Like
It’s okay, numbers are hard!
2 Likes