New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Aero Peek Window Preview gets shifted to the top & left #12
Comments
Just adding, Aero Snap has been malfunctioning on maximized windows since some unknown build (it will set incorrect bounds on snapped windows and the snapped windows will not be recognized as snapped, unless you snap them a second time). But this is likely out of scope for this repo. |
Thanks for filing. This isn't really a developer-related issue per se, but I'll allow it in this case 😉 I've sent email and will reply when I've heard back. |
@GeeLaw: Good news! Heard back from the DWM team responsible for window placement:
So, over to you 😉 |
Not sure if it has been fixed in a later version. https://aka.ms/AA700qh is marked as "we got it" (I don't recall whether it's marked as such the last time I saw it). It's also not clear whether the team was able to reproduce the problem, or that only indicates someone in the team has read it. A more specific reproduction (in 1909):
Expected: In 2, the two windows are snapped. In 3, Snap Assist shows up. In 3, 4, each window is snapped. Actual: In 2, it's what's expected. In 3, Snap Assist does not show up. In 3, 4, the previously maximized window is not snapped (a few pixels pushed upwards). In 4, the instance snapped for a second time is properly snapped. Notes: This does not happen with Office (Desktop) apps. Perhaps that's because Office apps have custom non-client area and the bug does not show up in such cases (or it could be a coincidence). Not sure if it has anything to do with scaling, but mine is 200%. |
it seems that it only happens in apps that have a thinner title bar while maximized |
It's great that this is being taken care of, but did it really need this out-of-scope GitHub issue to finally have someone look at the problem after two and a half years? This started with 1803! I can't believe nobody noticed this very obvious bug and decided to act on it before. |
Since version 1903. Not sure of the build of v1903 or of the very first build that that issue starting occurring. |
I had this issue for ages. Now I can't repro this on 20277.1 |
It would be amazing if they had finally fixed this. Keep in mind this bug does not occur when hovering over taskbar previews while one window is maximized. So even taking this in mind, you don't get this bug anymore? |
Now I can repro this 😞 |
Too bad. :/ The wait continues. But anyway, I would have been very surprised if they fixed that before the end of the year. |
FWIW, I'm just getting this issue after switching to a 4K monitor. I never noticed it before when I was using a 1440p monitor. Idk how relevant that is to you guys, but maybe it means something. Hope this gets cleared up soon. |
I'm seeing this on a 1440p monitor as well. |
I could see this on non High DPI displays |
This is still present in the very latest preview builds 21277.1 |
For me, I've noticed that the bug only occurs when there are no maximized windows. It's really bad when all windows are in bounds and are normal, and it's slightly bad when all windows are normal but one is out of bounds. 2021-01-08.13-36-49.mp4In the three examples I show, notice how the first one has pretty bad shadow movement, the second one has no movement, and the third one has slight movement. |
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. |
hum, sorry? |
got to be kidding lol. pretty sure this requires microsoft feedback, not author feedback |
Hang fire team: This may be a tooling error at our end. Please ignore for now. Just to re-iterate, the task switcher team are tracking this issue and do plan on fixing. We appreciate your continued patience. |
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. |
C'mon now... |
Yeah let me give some author feedback... come on. |
the windows division must be run by msftbot. it'd explain a lot of things. 🤣 |
Please ignore the previous bot notifications - we're configuring a tool to help us triage and drive a more systematic process resulting in more predictable and higher quality engagements in the future. |
Any news on this issue? |
no recent activity by microsoft |
Hopefully we can see a fix by the time 21H2 rolls out, along with Sun Valley or something. |
lmfao good one. |
Update: Can no longer repro this issue on the current in-market version of Windows 20H1. Also note that this is not an issue specifically impacting developers' productivity on Windows, and so am closing the issue. If you can still repro this issue on the current version of Windows, please report via Feedback Hub (inc. repro recording) so that the owners of this feature can receive your feedback (and repro steps etc.) directly. Thanks. |
I can also not reproduce this anymore. This is very surprising, I would have expected this to remain broken until Windows 11. Glad to finally see this fixed. :) |
Still happens for me, just guess I'll have to wait for Windows 11 |
Are you on the latest cumulative update of 20H1/20H2/21H1? |
My fault, I still have KB5003690 installing on my 21H1 -- I'll strikethrough that comment if it works after the update. Edit: Nope, still broken. |
21H1, Version 10.0.19043 Build 19043 8K1CU6skfs_Trim.mp4 |
Correction: It still happens, but only when at least one UWP app is open and not always. So better than before, but still not quite fixed. Correction 2: I just got it to happen even without a UWP app open.😑 I don't think I'm going to bother with Feedback Hub at this point. I hope it's fixed in Windows 11. |
From what I've heard it is fixed in Windows 11 Edit: Nvmd with the latest technical preview build of W11 it's still broken (it's way worse than it is on W10 actually) |
Looks like it is fixed on Windows 11 (the glass frames are all gone in Aero Peek now, but still light years better than things randomly shift around). |
Why closing this issue? It is still not fixed on Windows 10, which will be active until 2025. |
I think "active" may turn out to be an overstatement there. In any case, I think we know this won't ever see a fix in Windows 10, all things considered - they never bothered to do so after several years, they certainly won't do it when there is a shiny new replacement to focus on and even less when that replacement already fixes this bug. Might as well get it over with and close this issue + move on. |
On Win11 they killed aero peek, if you try to invoke aero peek by hovering over a taskbar preview (like here: #12 (comment)) you will see that they just hide all the other windows, no silhouettes at all. |
Well, that doesn't change my point at all. |
They maybe never see this as an issue. Otherwise, it would not exist as early as v1803... |
The window previews (Aero Peek) get shifted to the left & top when hovering on taskbar previews.
Note: This is an ancient bug (starts from RS4 I believe) and have been in Feedback Hub for so many times by half a dozen people, but still not fixed as of the latest Dev channel build.
Feedback Hub links just to name a few
https://aka.ms/AA20rko
https://aka.ms/AA93yus
https://aka.ms/AA93yut
Please come up with a fix since this is getting very annoying.
The text was updated successfully, but these errors were encountered: