Skip to content

[MEGATHREAD] Quake Mode & Global Summon #8888

Open

Description

[Original thread: #653] [Spec: #9274, doc] [Project]

See also Quake Mode FAQ

1.9 tasks

2.0 tasks

{ "name": "Promote to quake window", "command": { "action": "renameWindow", "name": "_quake" } }

Backlog

Activity

  1. ghost added
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Jan 26, 2021
  2. ghost added
    Needs-Tag-FixDoesn't match tag requirements
    on Jan 26, 2021
  3. added and removed
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Jan 26, 2021
  4. changed the title [-]<camper>[/-] [+][MEGATHREAD] Quake Mode & Global Summon[/+] on Apr 8, 2021
  5. ghost added a commit that references this issue on Apr 15, 2021
  6. ghost added a commit that references this issue on Apr 26, 2021
  7. 52 remaining items

  8. added
    Area-WindowingWindow frame, quake mode, tearout
    and removed
    Area-UserInterfaceIssues pertaining to the user interface of the Console or Terminal
    on Aug 4, 2021
  9. ghost added
    Needs-Tag-FixDoesn't match tag requirements
    on Aug 4, 2021
  10. ghost added a commit that references this issue on Aug 11, 2021
  11. kulkalkul commented on Aug 18, 2021

    @kulkalkul

    Couldn't find the issue about task manager focus, so posting it here. It also happens with IntelliJ IDEs.

  12. ghost removed
    Needs-Tag-FixDoesn't match tag requirements
    on Feb 28, 2022
  13. Nacimota commented on Sep 15, 2022

    @Nacimota
    Contributor

    KNOWN ISSUE: If you try to summon the window while task manager is focused, the window will not get activated. Presumably this can happen with other apps as well. UWP OneNote seems affected as well.

    Apologies if this has been discussed elsewhere (I did do a quick search), but I imagine this is UIPI related? If so, my understanding is that you would normally solve that by requesting UIAccess=true, though I wouldn't be able to test that because it needs to be signed and so on to work. I'm not sure how applicable that approach is to this project, so maybe someone who knows more can chime in?

    Curiously enough, when I have Task Manager (or any other high integrity/UWP app) in focus, I can summon the quake window if it is not currently shown, but once it is visible on the desktop I cannot dismiss/focus the quake window using the hotkey (if taskmgr/whatever is in focus). I'm not entirely sure why that is, but (assuming my experience isn't unique) I suspect what's actually happening when a user says they can't summon the window is that is was already present on the desktop, but perhaps out of focus and hidden by other windows (like a maximized browser or something) and it's not capturing the hotkey so it doesn't take focus again.

    If so that raises a couple of questions in my mind:

    1. Should the quake window be always-on-top?
      I feel like it's kind of transient UI in much the same way that (for example) the start menu is, in the sense that it floats on top of everything else while you're using it and disappears when you're done. But if you don't manually dismiss it with the hotkey and get distracted with other windows, you might mistakenly think you've dismissed it when it's actually still there.
    2. Should the quake window automatically dismiss itself when it loses focus?
      Following on from above, I think this makes a fair bit of sense. I don't think the expectations for how a quake-style window would behave are exactly the same as a regular window (or at least, I don't think they are for me). This also has the added benefit of potentially solving the Task Manager problem, assuming the hotkey does consistently work to summon the window when it isn't currently shown.

    The problem also appears to go away for programs like Task Manager if you run the terminal as admin, though that doesn't seem like much of a solution. This doesn't appear to work for UWP apps, though, presumably because of AppContainers and various other things that they do which might as well be magic as far as I know.

  14. zadjii-msft commented on Sep 15, 2022

    @zadjii-msft
    Member

    this is UIPI related? If so, my understanding is that you would normally solve that by requesting UIAccess=true,

    I honestly don't know. The way we make this work is admittedly pretty hacky:

    const auto windowThreadProcessId = GetWindowThreadProcessId(oldForegroundWindow, nullptr);
    const auto currentThreadId = GetCurrentThreadId();
    LOG_IF_WIN32_BOOL_FALSE(AttachThreadInput(windowThreadProcessId, currentThreadId, true));
    // Just in case, add the thread detach as a scope_exit, to make _sure_ we do it.
    auto detachThread = wil::scope_exit([windowThreadProcessId, currentThreadId]() {
    LOG_IF_WIN32_BOOL_FALSE(AttachThreadInput(windowThreadProcessId, currentThreadId, false));
    });
    LOG_IF_WIN32_BOOL_FALSE(BringWindowToTop(_window.get()));
    ShowWindow(_window.get(), SW_SHOW);
    // Activate the window too. This will force us to the virtual desktop this
    // window is on, if it's on another virtual desktop.
    LOG_LAST_ERROR_IF_NULL(SetActiveWindow(_window.get()));
    // Throw us on the active monitor.
    _moveToMonitor(oldForegroundWindow, toMonitor);

    I never dug to far into it, but I just assumed that Task Manager was protected s.t. I couldn't AttachThreadInput to it.

    Whatever the solution to this is, utimately, it should work for non-quake windows as well. Quake mode is the most visible implementation here, but whatever we come up with should work for any old window.

  15. Nacimota commented on Sep 15, 2022

    @Nacimota
    Contributor

    I never dug to far into it, but I just assumed that Task Manager was protected s.t. I couldn't AttachThreadInput to it.

    Yeah, I am fairly confident UIPI is the mechanism at play there. My understanding is that you're not allowed to AttachThreadInput (among several other things) to a process running at a higher integrity level than you, which in practice applies not just to Task Manager but presumably any app running as administrator. It's the same reason that PowerToys needs to run as admin for shortcuts to work when elevated windows (like taskmgr) are in focus. PowerToys doesn't seem to have problems with UWP apps though... but UWP is a bit of a mystery to me.

    Anyway, requesting UIAccess is basically a way of bypassing UIPI without running as admin, but I don't see it used very often. I suppose because it involves a bunch of extra hurdles (process must be in a trusted location [system32/program files], authenticode signed, etc.) that are less convenient than requiring admin, especially for portable installations. I'm not sure that UIAccess is the right solution here either, I'm just saying I do suspect UIPI is the cause.

    Whatever the solution to this is, utimately, it should work for non-quake windows as well. Quake mode is the most visible implementation here, but whatever we come up with should work for any old window.

    Yep, that seems reasonable. Though it may not be the best solution for the problem at hand, I'd still propose always-on-top/auto-dismiss behaviours for quake mode have merit regardless, but that is a separate discussion I guess.

  16. chylex commented on Jul 28, 2025

    @chylex

    This feature has been driving me crazy. I've been triggering it by accident for years and it's way too hard to figure out how to disable it. Finally figured out I have to go to Actions and remove the "Show/Hide Quake window" win+sc(41) binding to stop it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions