Closed akorn closed 3 weeks ago
I suspect this is related to your network configuration. Can you check the onlineCheckMethodType config option?
Default is https, but you can try with dns, native or none
Yes, it indeed works when I set that to dns
. Too bad it doesn't tell me what's wrong with the https
check.
We can maybe try to be much cleaver and try another methods maybe after 5 tries (or something). Maybe a feature we can add
On Fri, 13 Sept 2024, 19:43 Dr. András Korn, @.***> wrote:
Yes, it indeed works when I set that to dns. Too bad it doesn't tell me what's wrong with the https check.
— Reply to this email directly, view it on GitHub https://github.com/IsmaelMartinez/teams-for-linux/issues/1405#issuecomment-2349859853, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADJHECZ23XF7NSDAOJLLETZWMW35AVCNFSM6AAAAABOFE6TWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBZHA2TSOBVGM . You are receiving this because you commented.Message ID: @.***>
I'm not sure I understand what the purpose of the online check is. Why can't you just try to access the Teams service, and print a meaningful error message when that fails? Any synthetic check is going to have false negatives (as seen here) as well as false positives -- where the check succeeds, but the service doesn't work, so you have to deal with that anyway.
it is a bit complicated but we need to ensure we are online for some features. We handle the auto refresh in some cases, when jumping from network to network, and we need to wait to be online to load parts of the pre-load script.
For example, if we don't handle the check of the network connection with the refresh (or even initial load) you end up with white screens (specially when the connection is a bit choppy).
As I say, we might be able to be a bit more cleaver on that connection test. Like check n times per type, but maybe changing the final message to indicate that config option is available is good enough. Unfortunately there isn't an easy way to check what type of check we need to perform (as far as I know) otherwise we could do that.
I'm probably being naïve. :) Still, in my fantasy world a network request either succeeds within a timeout, or not. If it doesn't, then we're "not online", but can retry with some back-off (up to some maximum time between retries).
I don't see why/how successful requests can lead to white screens, and why they can't just be retried if they aren't successful.
I'm not trying to argue, I'll take your word for it, it just seems counter-intuitive.
The way I would approach this (again, probably naïvely) would be to have heuristic acceptance criteria for network requests; e.g. https://teams.microsoft.com/ should redirect at least once, the final content-type should be such-and-such and the file size should be at least X kB. If the actual result doesn't match, try to use it regardless but log a warning and retry with back-off.
Then again, you're building on Electron, so maybe this isn't a viable approach anyway, in which case sorry about the noise.
no worries and thanks for the suggestions, they are always welcome.
I was more thinking that the backoff logic just tries another network request. It is a pain that electron don't have a 'isOnline' method that does that for us. But I might add something to this retries as it keeps popping up every now and then.
I was thinking something simpler like checking 1st with https (as it seems to work most times), then dns (my repeater needs that for example) and then native. And just go around them 5 times. If that doesnt' work, then fail and put a log message
this network issue is related to https://github.com/IsmaelMartinez/teams-for-linux/issues/1381 (both are the same issue, I think)
Can you check https://github.com/IsmaelMartinez/teams-for-linux/releases/tag/v1.11.1 and see if this solves your issue? Now it goes around https (10 times), dns (10 times), electron (5 times, as it is extremely optimistic) and finally just assumes you are online.
I might need to tweak timings and others but I think is simpler and can support better when changing from networks. Thanks!
closing as 1381 was fixed by the mentioned fixes. Do reach out if this isn't working for you and I can reopen
Describe the bug For the last few days, I've been unable to use the application. On startup, it pops up an empty window with the title "No internet connection", and logs this to the console:
To Reproduce Steps to reproduce the behavior:
teams-for-linux
Expected behavior Normal startup.
Screenshots Not useful (the log messages say it all).
Desktop (please complete the following information):
Debug
From
main.log
:However, https://teams.microsoft.com/ is accessible:
Additional context
Up to about a week ago I had no problem.
Teams still works from Ferdium on the same computer, in the same network.