Delay or disable "sync error" popup

[CaptainFlint]

When I wake up my computer from hibernation or sleep, Pale Moon immediately pops up a sync error message at the bottom:

Sync encountered an error while syncing: Unknown error. Sync will automatically retry this action. [Sync now]

I suspect, this happens because network takes some time to initialize, so Sync simply cannot access the server. After some time (when the network is up and running), the popup disappears, which seems to confirm the hypothesis (PM retries again, and this time connects successfully). So, this behavior is generally understandable, but in this particular situation the popup is completely useless and just annoys me. Is there any way to get rid of it? I tried to search in about:config for something related, but failed.

If there is no such option, I'd like to request this as a feature (in which case it's probably better to move the topic to Suggestions). I have some thoughts on how it might be implemented without compromising the user awareness if the Sync fails:
1) After the first failure, wait for some time without showing the error; then try again. If the error persists this time, then show the error message. The delay time between the retries might be configurable, and by default be something like 1 or 2 minutes.
2) There is the "Sync Now" button that can be put on the toolbar by the user. PM could turn this button red for indication that something went wrong, and tooltip would tell the message (like now it tells the date/time of the latest sync); then an option for complete disabling the popup might be safely introduced, so that users could choose which way of error indication they prefer.

[New Tobin Paradigm]

I don't think either of those things are gonna be changed.

[moonbat]

I've never run into this problem on either Windows or Linux and I go weeks without rebooting, always preferring to hibernate and resume with PM running. Maybe your network interface is taking too long to initialize after bootup.

[CaptainFlint]

Maybe your network interface is taking too long to initialize after bootup.

More like, I log in too quickly,when the login screen becomes available. As far as I understand, the login screen is displayed at the moment the OS state is fully restored. But the saved network connection at this moment is invalid, and it has to be reacquired, which takes time, several seconds at the very least least (I never thought of measuring it, because no other program behaves so nervously due to missing network connectivity). So if I log in before those seconds pass, I inevitably end up with running OS and no network. I only wish, PM understood that it's a normal situation, not an exceptional one…

[moonbat]

But the saved network connection at this moment is invalid, and it has to be reacquired, which takes time, several seconds at the very least least (I never thought of measuring it, because no other program behaves so nervously due to missing network connectivity).

There's 2 steps - first the network adapter has to be re-enabled (perhaps PM detects this and assumes this is the point where network access is available to use) and then an IP address has to be obtained from the router (assuming DHCP). Perhaps the latter step has a delay.

[Moonchild]

I only wish, PM understood that it's a normal situation, not an exceptional one…

There's a technicality you seem to be overlooking: putting a computer in stand-by is very unceremonious from an application perspective. All threads are just suspended suddenly, regardless of timers, control flow, or state the application is in. The O.S. will not provide any hints or provide time for applications to prepare for a stand-by state. To make sure things keep working after coming out of standby, all suspended timers will fire (since their time to fire has almost always lapsed by that time) when the application is woken up after stand-by. That includes the immediate firing of a sync request. For the sync client, it's impossible to distinguish a temporary no-connection state after stand-by from a no-connection state due to other reasons. In the latter case (the more common case of network issues, disconnection, etc.) it's most definitely not desirable to delay the notification to the user or making it in any way less obvious there's an error.

[CaptainFlint]

There's a technicality you seem to be overlooking: putting a computer in stand-by is very unceremonious from an application perspective. All threads are just suspended suddenly, regardless of timers, control flow, or state the application is in. The O.S. will not provide any hints or provide time for applications to prepare for a stand-by state.

That's not true: there it WM_POWERBROADCAST message being broadcasted exactly for this purpose. (At least, that's what MSDN claims, I have not tested it.)

In the latter case (the more common case of network issues, disconnection, etc.) it's most definitely not desirable to delay the notification to the user or making it in any way less obvious there's an error.

To be honest, even in case of a "real" network issue I would prefer not to be disturbed immediately, because in most cases it means just a temporary issue at my ISP's side, and it will be fixed in a few minutes. But I understand it may not be acceptable to everyone, that's why I suggested to have this not as the mandatory behavior change, but as an option, even disabled by default, so that main audience remained unaffected, and at the same time people like me would be able to benefit from it.

Also, if you take my second idea, it won't even have to be "no notification" case at all, the notification will be there, just look different, without affecting the browser window layout. And, again, it might be optional.

[New Tobin Paradigm]

How about this: You come up with a solution either preference based or full on detection from that system call and propose the actual code change and it will be considered.

Changing the notification type is out of the question however. There is no precident in Pale Moon specifically for this to follow and the Sync Button is not required to be on a toolbar for sync to function.. So it is a bad design choice from any angle.

[Moonchild]

That's not true

It is true in the default state.

Unless you explicitly register a callback in the system (which depends on a window handle, not an application ID, making this problematic for a multi-windowed application like Pale Moon) you're not given any notification by the system.

Even if registered, the system will likely not provide ample time (since it's a broadcast only with no feedback) to prepare for the low power state (because this event will have to bubble up from C++ to JS for the Sync client to even take notice, which isn't trivial) resulting in at the very least a race between showing and suppressing the notification when resuming from standby and event timers fire. It's something that might work for pure C++ applications that can simply set a global flag on the one application window they have, but won't work that easily in our case. It's going to at least be a very complex undertaking with lots of pitfalls.

[moonbat]

Or it could be something else entirely unrelated to having to code a fix, since no one else seems to have encountered this problem.

[CaptainFlint]

How about this: You come up with a solution either preference based or full on detection from that system call and propose the actual code change and it will be considered.

Pale Moon is not a project that could be examined in a few minutes. Preparing a patch for something as big as that requires several orders of magnitude more time than I can spare, unfortunately.

Changing the notification type is out of the question however. There is no precident in Pale Moon specifically for this to follow and the Sync Button is not required to be on a toolbar for sync to function.. So it is a bad design choice from any angle.

That's why I don't ask to delete it completely, but just give an option to do this.

Unless you explicitly register a callback in the system (which depends on a window handle, not an application ID, making this problematic for a multi-windowed application like Pale Moon) you're not given any notification by the system.

Registration is only needed for the PBT_POWERSETTINGCHANGE event type (changing of the power settings, not the machine power state), which are not needed here. The power state event types are received without any prior registration. I've created a simple program (VS 2017) which logs the WM_POWERBROADCAST messages without any additional registration, started it, put the computer to sleep, the next day woke it up. I've got this:

Code: Select all

[23.08.2019 22:58:44.696] PBT_APMSUSPEND => System is suspending operation.
[24.08.2019 09:11:04.456] PBT_APMRESUMEAUTOMATIC => System resumed from low-power state.
[24.08.2019 09:11:04.760] PBT_APMRESUMESUSPEND => System resume was triggered by user input.

So any application will get these notifications. The message is window-based, of course, but I don't see what is the problem with that. If the Sync error is displayed in only one particular window, only that window can be made to process the notification. If it's in all windows, then all windows can do the same independently. There are lots of other possibilities, I just cannot say which ones would work better, without knowing the PM code architecture.

Even if registered, the system will likely not provide ample time (since it's a broadcast only with no feedback) to prepare for the low power state (because this event will have to bubble up from C++ to JS for the Sync client to even take notice, which isn't trivial) resulting in at the very least a race between showing and suppressing the notification when resuming from standby and event timers fire. It's something that might work for pure C++ applications that can simply set a global flag on the one application window they have, but won't work that easily in our case. It's going to at least be a very complex undertaking with lots of pitfalls.

Again, it's hard to comment without knowing the codebase. If the sync is working fully in JS, and the power state flag has to be propagated there, that might be a problem… Of course, Sync could be modified to explicitly check "backwards" for that C++ variable before it decides to show the error (if the engine allows such things, that is), but I cannot tell how hard it is to implement under the circumstances.

Or it could be something else entirely unrelated to having to code a fix, since no one else seems to have encountered this problem.

It's possible, but I doubt it. Not that many users stick to sleep/hibernation instead of turning off the computer. And not everyone is using Sync in PM. And not everyone logs in immediately when the computer woke up. Just to have the issue, you have to intersect those sets of people, which might not result in a very big number. And how many of this number would even notice the error? And of those who do notice, how many will find it irrelevant and be annoyed by it to the degree that will make them go and ask to do something about it?

[Moonchild]

Sync is pure JS. See /services/sync/ in our tree. It cannot monitor these things directly.