kewisch/gdata-provider

Sporadic high CPU-load when network connection is unstable

Opened this issue · 0 comments

Hi,
I ended up here as a follow-up on this bug-report which I recommend to read, as it explains, how we found out, that this appears to be indeed a google-calendar bug. In brief:

The google-calendar periodically performs it's synchronization, which is visible for the user in form of the top spinning wheel.
However, when the network connection is unstable, sporadically, this sync action never completes. As the spinning wheel animation, for whatever reason, is quite cpu-intensive, the resulting battery drain is a major problem for me when doing a journey.
In this bug-report I also described steps to reproduce in TB v102.11.0:

  • setup a google calendar account in TB
  • switch to the calendar tab and make sure, that all notifications are dismissed
  • configure your network so that it points to an invalid gateway and DNS address. For instance, my normal router address is
    192.168.178.1, I changed gateway and DNS both to 192.168.178.189
  • rightclick on your google cal and hit "Synchronize Calendars"
  • switch to main (inbox) tab and see the wheel spinning. Eventually it is necessary to hit "Synchronize Calendars" multiple times, but I
    never had to do it more than four times.
  • verify that the spinning wheel never stops. Eventually, on re-establishing the internet connection "fast enough", the spinning stops,
    but in my experiments, after spinning for longer than 10 minutes, it never stopped again until closing TB.

Further, after having enabled calendar.debug.log, the console contained the following line:

Calendar: [calGoogleCalendar] Error syncing:
2152398878:[Exception... "The lookup of the hostname failed"  nsresult: "0x804b001e (NS_ERROR_UNKNOWN_HOST)"  location: "JS frame :: resource://gdata-provider/legacy/modules/gdataRequest.jsm :: fail :: line 239"  data: no]

So, while I'm not definitely sure whom to blame, it seems likely that this plugin plays a role and I would kindly ask to investigate this issue which has been around for years.

Thanks
Tycho