Brave (Chrome/Edge/Chromium?) quirkiness

[vertigo220]

I assume this applies to all Chromium browsers, but in Brave, I've noticed two issues when using the option to hover over the minimize button to show the toolbar:

• It only shows when hovering over the top half of the button
• Often when hovering to show the toolbar then moving the mouse away, the toolbar pops up again briefly shifted a little to the left. It's not 100% repeatable, but probably at least 75% of the time I can get it to do it by hovering to show it, then hovering over one of the options, then moving the mouse away in certain ways. The easiest and most repeatable way I've found is to simply move it up and left out of the toolbar and into the title bar to the left of the new tab (+) button.

[vertigo220]

Turns out the second issue happens on other (all?) windows, though in the ones I've discovered and tested so far, I need to move the mouse over the center of the title bar after moving it out of the toolbar for the second toolbar to appear. It's almost as if, despite the arrow not showing and the toolbar not showing when hovering over its designated position when the option to show it when hovering over the minimize button is enabled, it is still triggered when moving the mouse over the (what appears to be disabled due to that option) activation spot, but only when quickly moving there from the toolbar shown from the minimize button. But no idea why with Brave it shows farther to the right, close to the minimize button (~2" away) and in other windows it only shows centrally.

[gileli121]

Thanks for the report.
I had already noticed this issue before.
This is the first time someone has opened an issue about it here.

I will address it when I focus on bug fixes.

[vertigo220]

Probably related to this, but just found it does a very similar thing sometimes in another circumstance. I had a window (sized to about 1/4 of the screen and sitting in the bottom-right corner, though I doubt any of that matters) in front of (both z-order and set to AOT, but again, that probably doesn't matter) a maximized window (Brave). I hovered over the minimize button of the smaller window long enough for the toolbar to show, then clicked it to minimize, and two things happened. First, the toolbar took a second or two to disappear after the window minimized. Second, a toolbar flashed up at the top of Brave, similar to described in this issue. And as I said, this is repeatable, though not every time.

[gileli121]

@vertigo220
Thank you for the details.
You know what? This bug is annoying, and I've decided to fix it soon after I finish working on issue #317

[vertigo220]

Ha. Well, let me know if you need more info.

[vertigo220]

In case it helps, I've found that if you click and hold on the minimize button and once the toolbar shows move the mouse away while holding the mouse button down, it's >90% repeatable for this.

[gileli121]

Thank you for the information. I wanted to work on it today, but I was too busy. I hope to address it this coming Tuesday.

[gileli121]

@vertigo220
I tried reproducing this, and it’s very difficult to replicate.
In any case, the code responsible for this functionality is written very poorly (it was written a long time ago when I didn’t have enough knowledge and experience).
It seems like it might be related to multiple threads that the code doesn’t account for, which could result in this bug due to thread desynchronization. I’m not sure, but it’s definitely possible.

After reviewing it extensively, I have to decide that this code needs to be rewritten entirely—the entire code responsible for displaying the toolbar and arrow needs to be redone because it’s written very poorly.

Rewriting it could also improve performance and reduce CPU load.

But it will take more time than I thought.
Do you really reproduce this issue frequently?
It’s possible that on one computer, it happens more often than on another...

If it really happens to you frequently, I might invest time in it.
However, it will indeed take more development time since it will need thorough testing.

If you can help test it, it would make the work much easier.

[vertigo220]

It happens constantly. It's not so annoying that I'd insist you shelve other things to work on it immediately, but certainly it should be fixed, especially if the code in general is poorly done. I suspect you're very much like me in wanting to do that regardless just because you want it to be better. It's of course up to you to decide the priority of that, and I don't want you thinking I'm expecting you to make it a top priority.

It is curious that it's happening so frequently for me and so infrequently for you. My computer is no slouch, though Windows itself gets screwy frequently, and I wonder if that has something to do with it. I'm certainly happy to help with testing, just let me know what you need.

[gileli121]

@vertigo220

I will fix this and rewrite the code.
This code isn’t supposed to be so complicated anyway. Once it’s simplified, it will also be easier to ensure it works correctly.

[gileli121]

@vertigo220

Today, I rewrote 50% of this implementation. I completely rewrote the code responsible for displaying the toolbar from the minimize button.
The new code is much simpler and more efficient, potentially consuming significantly fewer CPU resources.

It didn’t take long to rewrite and implement, probably because I had a reference to the previous code and because I’m more experienced now, so it went quickly.

All that’s left is to implement the behavior for displaying the toolbar from the green arrow, and then it will be done.
I’ll probably continue working on it next Sunday (in next week). There’s a good chance it will be ready by then. If not, it will likely be ready for testing by next Tuesday (in next week).

[gileli121]

@vertigo220

Hello, I’ve finished re-implementing this.
I’d appreciate it if you could test it thoroughly and let me know how it works for you.

Here’s a version with the fix:
https://github.com/WindowTop/WindowTop-App/releases/download/5.26/WindowTop.5.26.1.-.setup.exe

Or, if you prefer a portable version:
https://github.com/WindowTop/WindowTop-App/releases/download/5.26/WindowTop.v5.26.1.Portable.zip

The new implementation is much simpler and potentially much more efficient.
It might also consume less CPU. If that’s the case, I’d be very happy to know since I’d like to include this note in the release notes.

[vertigo220]

Just installed it, so testing begins now. I'll likely give it at least a few days to really know if it's any better. If I haven't posted after a week just remind me.

Also, small thing, I'm surprised you haven't made the installer close the app on its own when running rather than requiring the user to do it.

[gileli121]

@vertigo220
Excellent.
I’m not sure I understood what you meant regarding the installer.
It’s also available on the version’s page. I just provided direct download links here in case you missed it. If you go to the download page for version 5.26, you’ll see that I mentioned it there.

[vertigo220]

I was saying that when running the installer, if the app is currently running, it prompts you to exit it and won't let you proceed until you do. Most installers will instead prompt to close the running app automatically.

I don't really want to say much yet regarding the testing as it hasn't been that long, but I haven't yet had this issue occur, even when trying to make it happen. So looking good so far.

[vertigo220]

While I still haven't had it do the other/original issue, it is still doing a different thing that it did before as well, which is that when I hover over the minimize button and the toolbar shows then I minimize the window, the window minimizes and it takes a second for the toolbar to go away, so it's just sitting there in the middle of the screen on its own for a second.

[gileli121]

@vertigo220
I’ve fixed the behavior where the toolbar is displayed half a second to a second after clicking the minimize button. This behavior also existed in the previous implementation, correct? From what I understand, it did.

You can download it here:
https://github.com/WindowTop/WindowTop-App/releases/download/5.26/WindowTop.5.26.2.-.setup.exe

Or the portable version:
https://github.com/WindowTop/WindowTop-App/releases/download/5.26/WindowTop.v5.26.2.Portable.zip

I’d love to hear how it works for you and if you encounter any other issues.

Thank you!

I was saying that when running the installer, if the app is currently running, it prompts you to exit it and won't let you proceed until you do. Most installers will instead prompt to close the running app automatically.

This is intentional as a precaution... If you don’t close the software properly (the installer wouldn’t close it properly), there’s a risk of losing windows if you’ve used the PiP feature.

It can be improved so that the installer closes the software properly, ensuring it restores the original state of the windows before shutting down. However, implementing this would require some work.

That’s why I opted for a compromise where the user is forced to exit the software from within the application itself. This way, the software ensures the windows’ state is restored before it closes.

[vertigo220]

It probably did. I was just coming to give some thoughts on that issue, but even better. I'll download and test the updated version.

This is intentional as a precaution... This way, the software ensures the windows’ state is restored before it closes.

Ok, that makes sense. And it's by no means a big deal, I just know that many programs' installers are able to do this on their own, and therefore that it's possible, and it's a small quality-of-life thing. Maybe something to do down the road, but by no means something I'd consider a priority.

Edit: Although, I just had a thought when shutting it down to install this latest version. Automating it would not only be nice for making the install that much easier/faster by not requiring the user manually shut it down, but it could also provide for WindowTop to remember the settings for the various windows and reapply them automatically once updated. Otherwise, every time I update it I have to go through all the windows I have set to be on top and reapply that setting. And that's just that one setting. Windows that are set to dark mode, anchors, cropped/PiP windows, would all have to be reconfigured. It would be nice to have it remember all that and put everything back automatically. What do you think, is that doable? Should I create an issue for it?

[vertigo220]

The delay is definitely better, but ~20% of the time, the toolbar will go away like it does every other time, then quickly reappear for a split second then disappear again.

[vertigo220]

I've also had a couple weird, random issues. First with the TV Show Import dialog window in Advanced Renamer. The toolbar showed when hovering on the title bar a bit to the left of where the minimize button would be if there was one, but it was just empty space. It was acting like there was a minimize button, not showing the arrow like it does when there's not one. I closed the window and reopened it and then it showed the arrow and didn't show the toolbar in the same spot as before. Very strange. Then, just now, I was on my bank account website, downloading statements, and the toolbar appeared in the middle of the webpage. I was alternating between the date selection dropdown and the download button, and after doing this a handful of times, the toolbar suddenly appeared when I moved the mouse over the date dropdown. It hadn't done it any time before, and it didn't do it again when I tried to replicate it. But clearly there's something strange going on in the logic of when to show it.

[gileli121]

@vertigo220

The delay is definitely better, but ~20% of the time, the toolbar will go away like it does every other time, then quickly reappear for a split second then disappear again.

Are you talking about the original issue or a new one? Did the original issue happen again?

I've also had a couple weird, random issues.

All of these random issues started from 5.26.2, and it was working well on 5.26.1 (except for the issue where the toolbar appeared for a second after minimizing)?

If that's the case, I will revert the last change and implement the small fix differently.

In the meantime, could you please recheck if it works better in 5.26.1?

And just to confirm, you didn’t experience the original issue in 5.26.1, correct?

[vertigo220]

Are you talking about the original issue or a new one? Did the original issue happen again?

New, though I'm not sure if it happened before and I didn't notice or if it's actually new. The original issue, so far, hasn't happened again, but still need at least a few more days of testing to be sure.

All of these random issues started from 5.26.2, and it was working well on 5.26.1

Not necessarily. They're very infrequent, so it's possible they would have happened on the older version(s) but just didn't happen to. It's impossible to say for sure whether they're something related to the code changes or not. I only used 5.26.1 for a couple days, and these random issues are so infrequent I'd have to use a given version for at least 1-2 weeks to say with any confidence it doesn't have those issues. Though given the nature (the showing of the toolbar in odd places that it shouldn't show) it seems to me it would be more likely related to the changes made in 5.26.1, which dealt with the showing of it, than those in 5.26.2, which dealt with the hiding of it, but you would of course know better.

So given all that, do you still want me to revert to 5.26.1?

[gileli121]

If you can confirm that these issues also occurred in 5.26.1, then there’s no need to revert. But if not, I’d appreciate it if you could revert until I have time to revisit this over the weekend or next Sunday.

It doesn’t seem like this will require several weeks. You experienced new issues (which I’ll dive into later) relatively quickly, within a few days. So it’s likely that if there are issues, you’ll notice them quickly in 5.26.1 as well.

It’s interesting because in your first feedback on 5.26.1, you mentioned not seeing any problems except for one minor issue, but since I released 5.26.2, you’ve reported additional issues.

That’s where my suspicion comes from that something might have broken in 5.26.2.
And based on what I can tell, this seems possible given the code changes.

Thank you!

[vertigo220]

It's just that I wasn't using 5.26.1 for very long before updating to 5.26.2, but I'll revert back for now. I also just had a crash, first time that's happened as well, so not sure if it's related to the changes. I'll email the crash log and make a separate issue about it.

[gileli121]

Thank you
Regarding the crash report, I received such a report via email. I will look into it by Sunday.

[gileli121]

@vertigo220
Hello again,

Today, I continued working on this and tried to improve it. I believe I managed to reproduce the issue you described once. I made some changes that I think should resolve the problem.

The bug I believe I’ve fixed is a strange case where the arrow appears in the middle of the screen for no reason, and the toolbar stops working and no longer appears.

Could you please download this version?

https://github.com/WindowTop/WindowTop-App/releases/download/5.26/WindowTop.5.26.3.-.setup.exe
or portable:
https://github.com/WindowTop/WindowTop-App/releases/download/5.26/WindowTop.v5.26.3.Portable.zip

[gileli121]

@vertigo220
About:

It was acting like there was a minimize button, not showing the arrow like it does when there's not one

This sounds like a different bug I wasn’t aware of. I realize this now after rereading your message. A few questions:

1. Is this the first time you’ve seen such behavior, or has it occurred in previous versions (5.26.0 and earlier)?

2. Regarding the window—did it previously have a minimize button? It’s possible. A program can remove the minimize button from a window at some point. In such a case, this could explain it because WindowTop remembers that there was a minimize button but doesn’t recheck the state to see if the minimize button is still present.

3. What is the software where this occurred? If you could send a screenshot of the window and the software where this bug happened, it would help.

In any case, there’s still a chance the issue is fixed in 5.26.3. If the reason this happened was related to the window closing beforehand, it’s very likely resolved. In 5.26.3, I added additional logic to ensure the toolbar/arrow isn’t displayed and is reinitialized when the window is closed or not shown (e.g., minimized or moved to another virtual desktop).

For this reason, I highly recommend trying 5.26.3.

One more thing—it would be easier if we could communicate on Discord. My nickname there is gileli121. It would be more efficient to discuss this way, and in this case, I think it’s a bit more necessary than usual.

Thank you!