New Tobin Paradigm wrote: ↑
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.
Moonchild wrote: ↑
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.
moonbat wrote: ↑
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?