[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Passwords and input methods (was: Request to add a new layout for Malaya

From: Mike FABIAN
Subject: Passwords and input methods (was: Request to add a new layout for Malayalam)
Date: Tue, 07 Nov 2023 10:37:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Ajith R <ajithramayyan@yahoo.co.in> さんはかきました:

> There is a problem with using the layouts with browsers - they don't
> work sometimes. I am not sure what triggers the non conversions. You
> probably can recreate the problems by using my pn-eqf layout to enter
> the password to the web interface of gitlab. When the passwords are
> invisible, the ibus conversion doesn't happen. If you show the
> password (by pressing the eye button), you can see that ibus
> conversions did not happen. If you type after showing the password,
> the conversion happens as expected. Note that the pn-eqf works as
> expected if I type into a desktop app like a text editor. I have tried
> it in two browsers - firefox and falkon. Both show the same error.
> In addition, in falkon, ibus restart (after modifying the mim file)
> did not show the changes unless it is closed and reopened. Ibus
> conversion didn't also work in yahoo mail web interface for composing
> a mail using falkon. However, it appears that installing m17n-lib-bin
> solved that problem. However, the password problem still persists.

Input methods are usually disabled on purpose for password inputs. If
they are not disabled, it is usually considered a problem.

Some programs disable input methods completely on password inputs and
the input methods do not even receive any key events anymore.

In case of the gitlab password input in firefox, the input method is not
disabled completely and does receive the focus-in and the key events,
**but** on focus-in the input purpose PASSWORD is set. I see that for
example in the debug.log of ibus-typing-booster when the focus enters
the gitlab password input field:

tail -F .local/share/ibus-typing-booster/debug.log
2023-11-07 10:05:36,230 hunspell_table.py line 7070 do_set_content_type DEBUG: 
self._input_purpose = 8 (InputPurpose.PASSWORD)

if InputPurpose.PASSWORD is set, ibus-typing-booster disables all input
processing and just passes the typed keys through directly like this:

        elif (self._input_purpose
              in [itb_util.InputPurpose.PASSWORD.value,
            if DEBUG_LEVEL > 0:
                    'Disable because of input purpose PASSWORD or PIN')
            disabled = True

        if disabled:
            return self._return_false(key)

ibus-m17n does the same, if IBUS_INPUT_PURPOSE_PASSWORD is set, all
typed keys are just passed through as is:


    switch (m17n->purpose) {
        /* For password and PIN input, skip any further step
           processing a key event.  */
        return FALSE;

This is to avoid showing parts or all of the password accidentally. 

There are cases where this cannot work, like for password prompts in
terminals InputPurpose.PASSWORD is not set (maybe it is impossible to to
this because the terminal does not know either that the program running
in the terminal is asking for a password). And then parts or even all of
the input may be visible by accident like this:

Attachment: Screenshot-password-input-shown-in-terminal.png
Description: PNG image

And people complain endlessly about that problem in terminals where it
might be impossible to fix. At least now it is the responsibility of the
user take care at password prompts in terminals to disable any input
methods manually if it would be a problem if the password can be seen.

But except for terminals, other programs usually know when a password is
going to be typed and either disable all input methods completely or set
the InputPurpose.PASSWORD which causes most input methods to
disable itself.

If you click the eye button to show the password input on the gitlab
password input in firefox and type then, input methods work because in
that case the InputPurpose.PASSWORD is **not** set.

Mike FABIAN <mfabian@redhat.com>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]