Allow users to suppress ctfmon service notification (perhaps store in app state?) #11955

@levicki commented on GitHub (Jan 4, 2021):

@DHowett Are you sure that those users who were complaining about lack of keyboard input actually have physical, USB or PS/2 attached, keyboards?

Perhaps all of them were using a Surface tablet with on-screen keyboard or even worse, handwriting using a pen, to enter text?

Do you have any other data point about their hardware except that the service was not running?

I consider keyboard input a hardware event at the core and I think submitting a bug report for it merits asking them for hardware configuration.

@levicki commented on GitHub (Jan 4, 2021): @DHowett Are you sure that those users who were complaining about lack of keyboard input actually have physical, USB or PS/2 attached, keyboards? Perhaps all of them were using a Surface tablet with on-screen keyboard or even worse, handwriting using a pen, to enter text? Do you have any other data point about their hardware except that the service was not running? I consider keyboard input a hardware event at the core and I think submitting a bug report for it merits asking them for hardware configuration.

claunia commented

@zadjii-msft commented on GitHub (Jan 4, 2021):

I have a laptop with a physical keyboard. If I disable that service, then the input doesn't work. So my rudimentary due-diligence of the input team's assertion confirmed their theory.

I'm okay with storing this in app state, but only if we bump that feature's priority. Otherwise I'm gonna just throw experimental.iSolemnlySwearThatIAmUpToNoGood in later today.

@zadjii-msft commented on GitHub (Jan 4, 2021): I have a laptop with a physical keyboard. If I disable that service, then the input doesn't work. So my rudimentary due-diligence of the input team's assertion confirmed their theory. I'm okay with storing this in app state, but only if we bump that feature's priority. Otherwise I'm gonna just throw `experimental.iSolemnlySwearThatIAmUpToNoGood` in later today.

claunia commented

@levicki commented on GitHub (Jan 4, 2021):

@zadjii-msft I am not trying to be argumentative, I just want to figure out what is the real problem and solve that if possible. With that in mind, I really don't understand your hostility and snarkiness towards users who don't share your problem and who were all affected with a half-assed permanent warning "solution" that was implemented initially.

Can you please share more details? For example:

Does your input stop working in all applications or just modern ones when you disable the service?
Did you try restarting Windows with the service disabled to see if there is any change afterwards?
Do you have any upper or lower filter drivers for keyboard devices (apart from default kbdclass) installed (look in Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e96b-e325-11ce-bfc1-08002be10318})?
What happens if you attach external keyboard over USB while service is disabled?
What happens if you manually launch ctfmon.exe instead of enabling and starting the service?
What are your BIOS settings for legacy USB emulation?
What is your input language?

Finally, what are your tablet-related settings?

IMO, answering those questions should be the minimum required due-diligence before even trying to fix the problem.

@levicki commented on GitHub (Jan 4, 2021): @zadjii-msft I am not trying to be argumentative, I just want to figure out what is the real problem and solve that if possible. With that in mind, I really don't understand your hostility and snarkiness towards users who don't share your problem and who were all affected with a half-assed permanent warning "solution" that was implemented initially. Can you please share more details? For example: - Does your input stop working in all applications or just modern ones when you disable the service? - Did you try restarting Windows with the service disabled to see if there is any change afterwards? - Do you have any upper or lower filter drivers for keyboard devices (apart from default `kbdclass`) installed (look in `Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e96b-e325-11ce-bfc1-08002be10318}`)? - What happens if you attach external keyboard over USB while service is disabled? - What happens if you manually launch ctfmon.exe instead of enabling and starting the service? - What are your BIOS settings for legacy USB emulation? - What is your input language? Finally, what are your tablet-related settings? ![image](https://user-images.githubusercontent.com/16415478/103542197-dfb55600-4e9c-11eb-87c1-6ad888a4276b.png) IMO, answering those questions should be the minimum required due-diligence before even trying to fix the problem.

claunia commented

@zadjii-msft commented on GitHub (Jan 4, 2021):

My apologies. I'm not trying to be snarky with you either - maybe my snark is best intended for our own internal input team who's led us off on this snipe hunt in the first place. First we're told on no uncertain terms that disabling that service will break keyboard input to the Terminal. Great - if that's true, then the warning is perfectly reasonable. However, in the month since shipping that warning, we've found out that there are users who disable the service for perfectly reasonable reasons. We've also learned from the input team that the real purpose of that service is to keep ctfmon.exe alive, and that process is the real thing that needs to be running for the Terminal to receive KB input. That's their latest stance on the issue. However, we've also clearly learned from community feedback that even that assumption is wrong, and somehow the Terminal can receive KB input even without ctfmon running.

So my real goal is twofold:

Accurately warn users when the keyboard won't work for them. For 99% of users who have the aforementioned service disabled, the KB won't work in the Terminal, and the dialog is useful. It prevents an absolute flood of issues that we have regarding "keyboard no worky".
Try and push on the input team to determine why they believe that ctfmon is absolutely necessary for the modern input stack (to XAML islands, and thus the Terminal). If this is their assumption, and that assumption is incorrect, then there's clearly some missing information in the equation. Figuring out what that is might lead both teams to a better understanding of different scenarios where the keyboard will or will not work. Unfortunately, there's a small minority of users that fall into this category, so finding repros is tricky - though the absolute vitriol to this warning has helped assemble good number of users who are reproing this case and willing to get to the root of the issue.

They're the real folks that will be able to better investigate this issue. Anyone here on the Terminal team, or even externally, is just going to be guessing. I'd really rather get the experts to help us with this investigation. Hopefully with people returning back after the long vacation, we'll get some traction. Should we find the real root cause of the issue here, then maybe we can fix it at an OS level, so users won't have broken KB input at all. Either that, or we can try and get a more accurate heuristic for what the root cause is.

@zadjii-msft commented on GitHub (Jan 4, 2021): My apologies. I'm not trying to be snarky with you either - maybe my snark is best intended for our own internal input team who's led us off on this snipe hunt in the first place. First we're told on no uncertain terms that disabling that service will break keyboard input to the Terminal. Great - if that's true, then the warning is perfectly reasonable. However, in the month since shipping that warning, we've found out that there are users who disable the service for perfectly reasonable reasons. We've also learned from the input team that the real purpose of that service is to keep `ctfmon.exe` alive, and _that process_ is the real thing that needs to be running for the Terminal to receive KB input. That's their latest stance on the issue. However, we've also clearly learned from community feedback that even that assumption is wrong, and somehow the Terminal can receive KB input even without `ctfmon` running. So my real goal is twofold: 1. Accurately warn users when the keyboard won't work for them. For 99% of users who have the aforementioned service disabled, the KB won't work in the Terminal, and the dialog is useful. It prevents an absolute _flood_ of issues that we have regarding "keyboard no worky". 2. Try and push on the input team to determine why they believe that ctfmon is absolutely necessary for the modern input stack (to XAML islands, and thus the Terminal). If this is their assumption, and that assumption is incorrect, then there's clearly some missing information in the equation. Figuring out what that is might lead _both teams_ to a better understanding of different scenarios where the keyboard will or will not work. Unfortunately, there's a small minority of users that fall into this category, so finding repros is tricky - though the absolute vitriol to this warning has helped assemble good number of users who are reproing this case and willing to get to the root of the issue. They're the real folks that will be able to better investigate this issue. Anyone here on the Terminal team, or even externally, is just going to be guessing. I'd really rather get the experts to help us with this investigation. Hopefully with people returning back after the long vacation, we'll get some traction. Should we find the real root cause of the issue here, then maybe we can fix it at an OS level, so users won't have broken KB input _at all_. Either that, or we can try and get a more accurate heuristic for what the root cause is.

claunia commented

@levicki commented on GitHub (Jan 4, 2021):

Should we find the real root cause of the issue here, then maybe we can fix it at an OS level, so users won't have broken KB input at all.

Hopefully that won't be "fixed" by enforcing service to enabled and removing the ability to disable it in the future without resorting to hacks such as RunAsTI.

Either that, or we can try and get a more accurate heuristic for what the root cause is.

That is what I wanted to help with, and why I asked all the questions above.

In any case, I believe that non-working keyboard input is not your team's responsibility to fix, especially not by showing permanent warnings.

If you as an application developer have to check whether a system service is running where does your responsibility end? Will you next have to check if DNS client service is running and show a warning because some users reported that ping cannot resolve DNS names in Windows Terminal?

though the absolute vitriol to this warning has helped assemble good number of users who are reproing this case and willing to get to the root of the issue.

You could have totally avoided the vitriol part.

Windows Terminal is an application often used by developers, system administrators and power users. Those three user classes are crucial for survival of any OS -- developers produce software for it which keeps it alive for end users, administrators maintain it for those end users, and power users evangelize its cool features to end users, bringing more of them to the OS.

By antagonizing those user classes you are hurting your own OS -- I sincerely hope more Microsoft developers and product managers would realize that before deciding to remove choices, gut existing settings or functionality, add non-dismissable warnings, and otherwise remove control from (and exert control upon) the users.

@levicki commented on GitHub (Jan 4, 2021): > Should we find the real root cause of the issue here, then maybe we can fix it at an OS level, so users won't have broken KB input at all. Hopefully that won't be "fixed" by enforcing service to enabled and removing the ability to disable it in the future without resorting to hacks such as RunAsTI. > Either that, or we can try and get a more accurate heuristic for what the root cause is. That is what I wanted to help with, and why I asked all the questions above. In any case, I believe that non-working keyboard input is not your team's responsibility to fix, especially not by showing permanent warnings. If you as an application developer have to check whether a system service is running where does your responsibility end? Will you next have to check if DNS client service is running and show a warning because some users reported that ping cannot resolve DNS names in Windows Terminal? > though the absolute vitriol to this warning has helped assemble good number of users who are reproing this case and willing to get to the root of the issue. You could have totally avoided the vitriol part. Windows Terminal is an application often used by developers, system administrators and power users. Those three user classes are crucial for survival of any OS -- developers produce software for it which keeps it alive for end users, administrators maintain it for those end users, and power users evangelize its cool features to end users, bringing more of them to the OS. By antagonizing those user classes you are hurting your own OS -- I sincerely hope more Microsoft developers and product managers would realize that before deciding to remove choices, gut existing settings or functionality, add non-dismissable warnings, and otherwise remove control from (and exert control upon) the users.

claunia commented

@zadjii-msft commented on GitHub (Jan 4, 2021):

As an application developer, it is my responsibility to ensure the best possible experience for our users. We got TONS of reports that the keyboard doesn't work, which is something that would silently break in the Terminal and seemingly no where else. We were told on no uncertain terms that disabling that service would break keyboard input. So that seemed like a good path to pursue. We're trying to provide info to users who have a broken experience for seemingly no reason.

Now clearly, that base assumption is wrong, and we're trying to get to the root cause here. We're Terminal developers first, but we're also Windows developers. Right now, we've found something mysterious about the OS, and we're using our experience with the Terminal to try and drive a more holistic solution to the problem.

You don't have to lecture us about developers being the lifeblood of the OS. Who do you think we are? We're developers too, who are pushing even harder than you to make Windows the best place for developers. We're not trying to antagonize our users, we're trying to get to the root cause of an issue and fix it for everyone. But you gotta be patient with us, there's like 5 of us on the Terminal team, and it's been a long holiday weekend.

We've made a call based on the best info we had at the time. It's turned out to be bad info. Hopefully, we can get to the root of all this.

@zadjii-msft commented on GitHub (Jan 4, 2021): As an application developer, it is my responsibility to ensure the best possible experience for our users. We got TONS of reports that the keyboard doesn't work, which is something that would silently break in the Terminal and _seemingly no where else_. We were told on no uncertain terms that disabling that service would break keyboard input. So that seemed like a good path to pursue. We're trying to provide info to users who have a broken experience for seemingly no reason. Now clearly, that base assumption is wrong, and we're trying to get to the root cause here. We're Terminal developers first, but we're also Windows developers. Right now, we've found something mysterious about the OS, and we're using our experience with the Terminal to try and drive a more holistic solution to the problem. You don't have to lecture us about developers being the lifeblood of the OS. Who do you think we are? We're developers too, who are pushing _even harder than you_ to make Windows the best place for developers. We're not trying to antagonize our users, we're trying to get to the root cause of an issue and fix it for _everyone_. But you gotta be patient with us, there's like 5 of us on the Terminal team, and it's been a long holiday weekend. We've made a call based on the best info we had at the time. It's turned out to be bad info. Hopefully, we can get to the root of all this.

claunia commented

@levicki commented on GitHub (Jan 4, 2021):

As an application developer, it is my responsibility to ensure the best possible experience for our users.

I agree, but you can't fix everything.

You don't have to lecture us about developers being the lifeblood of the OS.

That was not my intention -- I was just trying to remind you that sometimes on the other side of the issue report is not a clueless end user who disabled stuff because they used "free windows optimizer 13.0", but a fellow developer, system admin, or a power user who knows quite a bit about the OS, and definitely more than you about their own working environment.

We're not trying to antagonize our users, we're trying to get to the root cause of an issue and fix it for everyone.

Sorry, but it didn't look like that when you guys were talking about naming the setting iSolemnlySwearThatIAmUpToNoGood and iAmTheKindOfPersonWhoDisablesRandomSystemServicesAndAcceptThatThisIsNotASupportedConfigurationSoStopTellingMeAboutIt.

We've made a call based on the best info we had at the time.

Bad decision based on bad data wasn't the issue -- your and Dustin's overall attitude when people confronted you was, hence my response which you perceived, made hidden, and labeled as "rant" and "shit" then gone back and edited "shit" out.

I want to be perfectly clear -- I am here because I want to help.

@levicki commented on GitHub (Jan 4, 2021): > As an application developer, it is my responsibility to ensure the best possible experience for our users. I agree, but you can't fix everything. > You don't have to lecture us about developers being the lifeblood of the OS. That was not my intention -- I was just trying to remind you that sometimes on the other side of the issue report is not a clueless end user who disabled stuff because they used "free windows optimizer 13.0", but a fellow developer, system admin, or a power user who knows quite a bit about the OS, and definitely more than you about their own working environment. > We're not trying to antagonize our users, we're trying to get to the root cause of an issue and fix it for everyone. Sorry, but it didn't look like that when you guys were talking about naming the setting `iSolemnlySwearThatIAmUpToNoGood` and `iAmTheKindOfPersonWhoDisablesRandomSystemServicesAndAcceptThatThisIsNotASupportedConfigurationSoStopTellingMeAboutIt`. > We've made a call based on the best info we had at the time. Bad decision based on bad data wasn't the issue -- your and Dustin's overall attitude when people confronted you was, hence my response which you perceived, made hidden, and labeled as "rant" and "shit" then gone back and edited "shit" out. I want to be perfectly clear -- I am here because I want to help.

claunia commented

@Don-Vito commented on GitHub (Jan 5, 2021):

@levicki - as an external contributor to this project, I just want to pay your attention that addition of every setting not only requires development, but also introduces code paths that require maintenance and increase time to market. So keeping the logic as simple as possible by always finding the root-cause (that Dustin and Mike mentioned above) is crucial, especially for a small team that builds a product with such levels of complexity and adoption.

Regarding the recent threads at this matter, I sometimes really hate the written communication - obviously everyone here is trying to help and I am sure that if this dialog was happening face to face it would look differently. Not that I ever talked with Dustin or Mike beyond GitHub 😊 But after 3 months of intensive collaboration, I am convinced that their only attitude is to make sure that the users are getting the best value the team can provide.. and that they are from the same breed as Raymond Chen or even Mark Russinovich (I guess this makes them divine creatures) 😊

@zadjii-msft - can I help somehow?

with pushing the app state effort (not sure what is the approach / status there)
to implement the short-term solution

@Don-Vito commented on GitHub (Jan 5, 2021): @levicki - as an external contributor to this project, I just want to pay your attention that addition of every setting not only requires development, but also introduces code paths that require maintenance and increase time to market. So keeping the logic as simple as possible by always finding the root-cause (that Dustin and Mike mentioned above) is crucial, especially for a small team that builds a product with such levels of complexity and adoption. Regarding the recent threads at this matter, I sometimes really hate the written communication - obviously everyone here is trying to help and I am sure that if this dialog was happening face to face it would look differently. Not that I ever talked with Dustin or Mike beyond GitHub :blush: But after 3 months of intensive collaboration, I am convinced that their only attitude is to make sure that the users are getting the best value the team can provide.. and that they are from the same breed as Raymond Chen or even Mark Russinovich (I guess this makes them divine creatures) :blush: @zadjii-msft - can I help somehow? - with pushing the app state effort (not sure what is the approach / status there) - to implement the short-term solution

claunia commented

@DHowett commented on GitHub (Jan 5, 2021):

@Don-Vito I appreciate you saying that, but I will totally admit that I was brusque and dismissive, and that I dug my heels in instead of working towards a solution. 😄

@DHowett commented on GitHub (Jan 5, 2021): @Don-Vito I appreciate you saying that, but I will totally admit that I was brusque and dismissive, and that I dug my heels in instead of working towards a solution. :smile:

claunia commented

@Don-Vito commented on GitHub (Jan 5, 2021):

@Don-Vito I appreciate you saying that, but I will totally admit that I was brusque and dismissive, and that I dug my heels in instead of working towards a solution. 😄

OK.. then ignore my comment regarding Mark Russinovich - he is flawless 😄

In any case, let me know if I can assist somehow.

@Don-Vito commented on GitHub (Jan 5, 2021): > > > @Don-Vito I appreciate you saying that, but I will totally admit that I was brusque and dismissive, and that I dug my heels in instead of working towards a solution. 😄 OK.. then ignore my comment regarding Mark Russinovich - he is flawless :smile: In any case, let me know if I can assist somehow.

claunia commented

@zadjii-msft commented on GitHub (Jan 5, 2021):

As far as the app state thing goes, I think @DHowett already has a branch with that in progress. It's a bit of a slog, refactoring some of the setting model stuff to be reusable for that purpose.

From a strategic standpoint, @DHowett let's make sure to hold the warning & infobar back from the 1.5 release channel, and keep it in preview for now. That's what Preview is for, right 😝?

@zadjii-msft commented on GitHub (Jan 5, 2021): As far as the app state thing goes, I think @DHowett already has a branch with that in progress. It's a bit of a slog, refactoring some of the setting model stuff to be reusable for that purpose. From a strategic standpoint, @DHowett let's make sure to hold the warning & infobar back from the 1.5 release channel, and keep it in preview for now. That's what Preview is for, right 😝?

claunia commented