GNOME Bugzilla – Bug 668025
Issues with terminals and passwords
Last modified: 2021-06-10 11:27:04 UTC
At some specific moments, while interacting with a terminal, the terminal will ask you a password, and the ATs should be careful to not present it (like bug 663332). After a brief brainstorming with Joanmarie Digss, we think that we have two options to do the "right thing": 1. With a role Terminals role are ATK_ROLE_TERMINAL. So one option would be add a new role ATK_ROLE_TERMINAL_PASSWORD. So the specific terminal should require to change the role. This is the same case that current ATK_ROLE_TEXT and ATK_ROLE_TEXT_PASSWORD. On the case of GTK, when the gtkentry changes his visibility, it also changes the role. So this option has the advantage that is coherent with the stuff that we already have. 2. With a state The problem with option 1. is that someone can argue if semantically the object has changed the role. In either case it is still a terminal. In the same way, having two roles that are the same that other existing role, but in a specific use case, can mean that a role is not the way to solve that. So other option would be add a state that expose that the user is writing something that shouldn't be exposed, something like ATK_STATE_SECRET (I don't like this name). In relation with the coherence, if we implement that solution, I also think that we should deprecate ATK_ROLE_TEXT_PASSWORD.
After a little research, in the case of MSAA/IA2 it is implemented with a state: http://msdn.microsoft.com/en-us/library/dd373609%28VS.85%29.aspx STATE_SYSTEM_PROTECTED : The object is a password-protected edit control. Although the description is misleading, this is the way this feature is implemented. In fact, on mozilla code, you can find this comment at the file nsStateMap.h: "The following nsIAccessible states aren't translated, just ignored: <skip> STATE_PROTECTED: The object is a password-protected edit control. Supported via ATK_ROLE_PASSWORD_TEXT <skip> " In the case of MacOSX I didn't found any role or subrole, so I suppose that this is also managed as a attribute/state. Taking that into account, I think that the proper solution could be add a new state. It seems that ATK_STATE_SECRET is not a proper name, so for coherence perhaps ATK_STATE_PROTECTED would be better.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of atk, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.