-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
desktop telegram (windows) not opening web-app #27886
Comments
+1 |
I found a solution purely by accident. To display the contents of the web-app. It doesn't matter if you have it enabled in the experimental settings: or not, it doesn't matter. It also looks like telegram desktop is passing data to Edge, I wonder what their user agreement says about this? |
@killershotpy thx, you are right! Problem was with EdgeWebView |
@killershotpy TDesktop tries to use WebView2 component to show the web-apps. "webview-debug-enabled" enables the Inspector working in the webview when it runs, but in your case the webview simply can't load for some reason. I don't use any hardcoded paths to search for the webview, I use WebView2 SDK through the Microsoft.Web.WebView2 NuGet package. |
As I wrote earlier, telegram desktop uses the default WebView from microsoft edge for some reason, this was diagnosed after explicitly disabling access to the microsoft edge folder. |
Well, if the WebView2 could not be initialized, fallback to WebView Legacy is made. Telegram bot web apps on all platforms work in system webview components, I see no difference in TDesktop case here. |
Maybe you should specify somewhere to users that if their default webview is not available, then you will not have web applications opening which are initialized through telegram? |
Well, there are some checks in code about the availability of WebView, two backends are checked on Windows. Maybe the checks aren't enough, then I'm all ears how to make them better. WebView2 checks the version of the browser used for the webview: Legacy WebView tries to create a control process: If none of those worked you should see a message like that one: |
@john-preston Is it possible to integrate webview to package instead of referrence? In my case I had corrupted folder on windows C:\Program Files (x86)\Microsoft\EdgeWebView\ |
tdesktop uses Webview2 exactly because the intention is to not to provide a huge web browser bundle. Otherwise tdesktop would just use Qt WebEngine (which is much simpler to integrate). |
as I suggested above - the user should definitely be able to see the explicit behavior of their application. thus it is necessary to add a system or (and) client alert that will show the absence of default webview. as well as a link to the documentation or at least this (or/and) ishy, so that you can immediately understand what the reason is. By default, the application is not run as administrator, and for this reason, system alerts (alerts) are not shown. Again, I discovered the problem purely by accident, because I was running the application "as administrator". Also, there are some related ish I have listed above, which most likely also depend on the system pre-installed webview. and also there is another solution that I would suggest: This would solve several problems at once:
Unfortunately, I realize that this will introduce a number of inconveniences and reduced functionality, such as:
However, the same web.telegram, explicitly passes the URL address with arguments and authorization or other actions embedded in this or that web application. I've been working with web apps and mobile apps for a long time, but I have no idea how arguments are passed in desktop apps. |
I apologize for the long time reply, above see my comment about the proposed solution. about your screenshot, I'm not quite sure if I "should have seen it by now" or if you will update the release and users will "further see" the lack of webviews? |
I'm not sure what would that give. As you can see, there's already a text for such situation, the problem is system APIs are misbehaving and saying the webview is successfully initialized despite it's not. Whatever you would like to show, you just can't detect whether it's found or not in first place with this exact breakage of system files. |
@killershotpy The problem is that in case of some system configuration the code that I use to detect if the webview is available isn't working correctly -- it should show the "install webview2 runtime" with a link, but it doesn't show anything, as if webview was successfully initialized. If you can provide a step-by-step way to bringing the system to the state where this happens I can try to make it myself and try to fix the detection. |
of course, here's the step-by-step detailed instructions:
AND
|
so, you basicaly say to reproduce this bug you must break windows. |
I haven't tested the behavior on other systems, but I've attached similar problems above in the comments, I assume they occur for the same reason - lack of a basic webview |
they all are closed as solved |
@killershotpy Your instructions apparently break the new one, WebView2 runtime. Because I've broken it that way (I can't even open that folder from my or administrative account) and now the modern WebView2 runtime can't initialize, but the fallback to the legacy WebView based on the legacy Edge browser still works fine. In your case it looks like you had broken by permissions issue the new WebView2 runtime + somehow broken the legacy Edge as well. Idk 🤷 |
Logically, I've banned webviewer access. Another person above said the same thing - he had a non-standard path to the webviewer. There is no return to the outdated version, because access is denied at the level of the webwiev folder itself, and outdated versions lie deeper: |
@killershotpy what @john-preston points out is your steps wasn't enough for him to reproduce the issue, web bots still work but with older system API. You're missing something in those steps. |
John writes that "but the fallback to the legacy WebView based on the legacy Edge browser still works fine". but doesn't say where it is? |
Personally I don't know. Not sure @john-preston knows. That might be something you have to find and tell us. |
How can I find a default webview with an older API? If you could point out the path where it should be I could take a look, as I don't know what paths or path variables in tdesktop you are using. Also, you might be trying to pull variables from env system, which could also be where the error lies The error could also be in the registry, which I also modified by removing all the microsoft edge junk. |
It should then show the text as @john-preston shown earlier. But I don't think that's possible as it should be integrated in Windows 11. The only supported system not having it out of the box is Windows 7. And, well, it's explicitly blacklisted as tdesktop fails to initialize webview on it even after manual installation of the component.
Well, tdesktop doesn't use paths, it uses system APIs, you can see how the code looks like: https://github.com/desktop-app/lib_webview/blob/master/webview/platform/win/webview_windows_edge_html.cpp#L171-L205 (this is the legacy API while the edge_chromium file implements webview2) That's why no one knows the paths. Unless you can remember what you have broken in the system, it might be impossible to repair it. In which case it might be better to re-install your system and close the issue. |
Steps to reproduce
1. update telegram to 5.0.1 version2. open any bot where opening by button web-app window
3. window IE not load web-app content
upd.
Expected behaviour
content is loaded in an IE window
Actual behaviour
The application hangs without loading the frontend.
At the same time any application opened with any bot does not work at all.
in log file, i have this:
...
[2024.05.07 02:25:13] Skipping message, because it is already in blocks!
...
with that option enabled:
I can't even open devtools to debug the problem.
Operating system
windows 10 home edition (desktop)
Version of Telegram Desktop
5.0.1 (latest)
Installation source
Static binary from official website
Crash ID
No response
Logs
The text was updated successfully, but these errors were encountered: