Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
* Joerg Dorchain [200303 05:15]:
> On Tue, Mar 03, 2020 at 10:57:41AM +0100, Andras Korn wrote:
> > I filed https://github.com/neomutt/neomutt/issues/2161.
>
> Thanks for the effort, but:
>
> Duplicate #2002 and there's already pull request for it #2160.
> @gahr gahr closed this 6 minutes ago
>
> Looks like cherry-pikcing that patch and thinking about the default setting.
No, #2002 is _not_ the same. See my previous message.
Neomutt bug #2002 is about editing headers. This Debian bug and Neomutt
#2161 are about commands in the message index. The behaviors are
different in the two situations.
There are three behaviors being discussed:
1. old behavior: backspace stays on the command line
2. new behavior: backspace aborts the command
3. wrong behavior: backspace invokes command with default argument
In #2002, while editing headers, you currently get "new behavior". The
bug reporter wants "old behavior" (what the previous version of Neomutt
did in this situation). The patch adds a config option to select which
you want.
In #2161, while in the message index, the previous version of Neomutt
gave "old behavior". The current Neomutt gives "wrong behavior", _not_
"new behavior".
For example, type s and (assuming a save-hook matches for the message)
the command line shows:
Save to mailbox ('?' for list): +some_folder
Now keep backspacing until +some_folder is gone and backspace one more
time. Instead of aborting the save, the message is actually saved to
+some_folder! This is really, _really_ wrong!
First, #2161 must be fixed so it doesn't give "wrong behavior". Then,
the patch needs to be tested to see if it affects both editing message
headers (#2002) and commands in the message index (#2161). If it does,
great! If it doesn't, the patch should be updated so that it does.
Then, the default needs to be decided.
Holding the backspace key down is common practice for some people as a
way of erasing the default prompt in preparation for typing a different
value.
Both for this reason and to reduce surprise and change, I feel that the
default should be "old behavior", but I can live with setting the option
myself if other people would rather have "new behavior" as the default.
There is one more reason that having backspace remain on the command
line instead of aborting is a better default. If someone has bound the
backspace key to some action in the message index (or in the message
editing screen), holding down the backspace key could invoke the bound
action on one (or several) messages in the index, depending on how
quickly the user releases the key.
...Marvin
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Tue, Mar 03, 2020 at 10:57:41AM +0100, Andras Korn wrote: > I filed https://github.com/neomutt/neomutt/issues/2161. Thanks for the effort, but: Duplicate #2002 and there's already pull request for it #2160. @gahr gahr closed this 6 minutes ago Looks like cherry-pikcing that patch and thinking about the default setting. Bye, Joerg signature.asc Description: PGP signature
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 01:45:26PM -0500, Marvin Renich wrote: Hi, > I don't have a github account, and do not wish to get one for this. > Will someone (Debian maintainer for neomutt, or someone else interested > in this bug) please file this with upstream as a separate bug, pointing > out that the other github issue is not the same as this bug, even though > some of the same code may be involved. I filed https://github.com/neomutt/neomutt/issues/2161. Best regards, András -- Microsoft follows standards the same way fish follow migrating caribou.
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
[P.S. I'm subscribed to the bug; you may drop me from explicit To or CC.] * Joerg Dorchain [200302 12:18]: > Then please include > https://github.com/neomutt/neomutt/commit/f197ab93c8436a39fc511f396acde24f90389f20?diff=unified > > in a new package, maybe with a Debian-specific change of the abort_backspace > default to false. I'm not a DD or DM and have no upload rights, and don't have the time at the moment to prepare and test an upload properly (which is more than just applying the patch and building a package). I do appreciate the people who have in the past and are currently working on the Debian packaging of neomutt. Looking at the github issue, it looks like backspace is supposed to cancel the command, and the behavior that the bug reporter wants is to remain on the empty command line and ignore the backspace. But neither is the behavior I am seeing. First, the behavior in the github issue is specific to editing email headers while composing a message. For me, that specific case seems to abort the edit, and it seems to be an intentional change. I don't have a strong opinion about the github issue, but it is definitely not the issue in this Debian bug, although the code that implemented the intentional change may be the cause of this Debian bug. The situation that I feel is a grave bug is when in the message index, using certain commands that require more information (save-message is one such command), pressing backspace when the prompt is empty (only the ":" showing) causes the _default action_ to occur (e.g. save to the folder specified by the save-hook for that message) rather than aborting the command. As long as backspace does not have a binding after the prompt is aborted (e.g. in the index), I can probably live with either the abort or ignore behavior, but activating the default action is highly broken. I cannot tell whether the patch referenced in the previous message will fix this Debian bug. If the cause of the Debian bug has to do with mutt_enter_string_full being called for both completing a command in the index and for editing message headers, but the result of the function is being handled differently in the two cases, then perhaps the patch will allow the bug to be masked by unsetting the option, but with the option set the bug will still be present. I can't tell without looking at the rest of the code. I don't have a github account, and do not wish to get one for this. Will someone (Debian maintainer for neomutt, or someone else interested in this bug) please file this with upstream as a separate bug, pointing out that the other github issue is not the same as this bug, even though some of the same code may be involved. Thanks...Marvin
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 11:40:47AM -0500, Marvin Renich wrote: [...] > > Here is my rationale for severity grave: [...] Then please include https://github.com/neomutt/neomutt/commit/f197ab93c8436a39fc511f396acde24f90389f20?diff=unified in a new package, maybe with a Debian-specific change of the abort_backspace default to false. Bye, Joe "ceterum censeo" rg signature.asc Description: PGP signature
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
* Andreas Henriksson [200302 08:27]: > On Fri, Feb 14, 2020 at 11:31:53AM -0500, Marvin Renich wrote: > > Control: -1 severity grave > > > > I'm increasing the severity of this bug, as it can cause unintended > [...] > > I just NMUed a new upstream version of neomutt, 20191207+dfsg.1-1, > which fixes the two other outstanding RC bugs. > It seems I can still reproduce this issue however (with the first prompt > I get which is the imap password prompt for me). Thanks for this! > This seems somewhat like a possible UX design fail. Possibly, but I suspect not. This is a regression from previous versions, and it would not make sense at all as an intentional design change. > This is done > upstream and not in debian. Do you know if there's already been any > discussion regarding this upstream? If not could you please file an > upstream bug report about this? Unfortunately, I don't have time to do this at the moment. I have no clue where upstream's bug system (or mailing list) is, and can't spend the time to do this right away. If you (or the maintainer; I assume you are not the maintainer since you did an NMU) would be so kind as to point upstream to this bug, I would appreciate it. > The behaviour hasn't really bothered me and I probably wouldn't even > have noticed it if it wasn't for this bug showing up on the RC bug radar > while doing my NMU, so I'm quite tempted to downgrade severity again. > Please work this out with upstream if this issue is important to you. > Please give feedback on this bug report about upstream discussions or > relevant commits and I'm happy to look into cherry-picking and NMUing > those as needed. Please don't downgrade this bug. Here is a very plausible expanded example based on my original scenario: The user is unaware of this bug, so is not being careful to watch out when backspacing (I am now aware of this bug, and still find myself accidentally backspacing too far). The user has tagged a large number of messages, intending to save them all to a different folder. The user types «;s=soon-but-not-immediate» out of habit, without watching the command line, and doesn't notice what folder was originally placed on the command line based on the save-hook for the first tagged message. The first message happens to match the save-hook for "=spam" (it received a marginally-positive spam score from spamassassin, but was a false positive). Before hitting enter on the ;s=soon-but-not-immediate command, the user changes his mind and decides to save them to the =handle-now folder, so he presses and holds the backspace key. Oops! Now all those messages are moved to the spam folder, which triggers a daemon on the IMAP server to tell spamassassin to learn all those messages as spam and moves the messages into a quarantine folder (inaccessible to the user). Meanwhile, the poor user, who has never seen this neomutt bug before, has no clue where his messages went, and all those messages have been learned as spam without the user's knowledge. Here is my rationale for severity grave: * This is a regression from a previous version. * The behavior makes no sense as an intentional UI change. * The bug can cause behaviour of which the user is unaware. * The unintended behavior caused by this bug can have significantly detrimental effects that are difficult discover and difficult to undo. Users of neomutt (and mutt) are typically a different kind of user than those who stick with Thunderbird or the Gmail web interface. They are likely to take full advantage of save-hooks and other advanced neomutt features. They are also more likely to type sequences of commands quickly and by habit, only looking at the command line at certain pauses. The above scenario is not based on a hypothetical setup. I run the renich.org mail server, which uses spamassassin to score incoming messages. Messages with scores above a certain threshold are rejected during the SMTP dialog, but messages with low-positive scores are accepted. I have a save-hook that uses =spam as the default folder for messages that spamassassin marks with a low-but-positive spam score. I do have a spam folder, with behavior similar to what is stated above, except that the auto-learning happens from a cron job overnight. While I have not had the above happen to me where the messages were saved to the spam folder and learned as spam before I caught it, it could have happened. The way I discovered this bug was, however, very similar. The actual (but unintended) save target was a different folder. It took several hours of investigation to determine what the bug was, where the messages actually went (which was not at all obvious even after I understood the bug), and to restore the messages to the intended destination. Debian Policy does not mention "severity" or "grave" anywhere. The Developers Reference lists the severities that are considered RC, but does not define them. The only definitions I can find are at [1]
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, 2 Mar 2020 15:18:54 +0100 Andreas Henriksson wrote: > On Mon, Mar 02, 2020 at 02:57:02PM +0100, Andras Korn wrote: > > > > https://github.com/neomutt/neomutt/issues/2002 > > Thanks for the feedback. > There is meanwhile a fix in the github issue; Would it be possible add that patch to the debian package even before a new upstream version is released? Thanks for considering. Bye, Joerg
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 03:18:54PM +0100, Andreas Henriksson wrote: > > Your rationale for downgrading the severity of an issue like this is that it > > doesn't bother you personally? > > My rationale, if you must know, is that if this is an important issue, > then the people who consider it an important issue will ofcourse work on > getting it fixed. I'm curious -- what exactly do you have in mind? How should the users bothered by this bug "work on it"? What would you consider a reasonable, acceptable level of effort? > There's nothing in debian policy (the document who defines the severity > levels for the bug tracking system) that says 'If you raise the severity > of a bug report then "someone else" has to do the work for you'. Nobody "has" to "do the work". It's just that if the work is not done, the issue stays open. If it meets the definition of a "grave" bug, then it stays grave. You're right in that if it's important enough for *the right people*, then it'll get fixed eventually. It's entirely possible that the the users affected by a bug are not the right ones to effect a fix. You can argue with the severity, but I don't think you should downgrade it for frivolous reasons like "I'm not interested in fixing it", or "I don't like the attitude of a commenter; I think they're being lazy." > Scratch your own itch. Sorry, no, that's not how this works. I'll scratch my own itch if/when I can, and also the itches of others if/when I can. This is not a bug I can realistically fix, but that doesn't affect either its severity or its existence. You don't get to downgrade a bug that meets the criteria for being "grave" just because you aren't personally affected by it, or because the user who reported it (or someone who commented on it) is unable or unwilling to fix it himself/herself. I'm sure you don't need me to tell you that. > The previously provided suggestion that this might lead to data loss is > a bit far fetched if you ask me. That's a valid argument. FWIW, I have no opinion. I filed the bug with a normal priority and won't insist on it being grave. If you think you can downgrade it for the right reasons, go ahead (as far as I'm concerned). Best regards, András -- Get married and share the problems you didn't know you had.
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 02:57:02PM +0100, Andras Korn wrote: > > https://github.com/neomutt/neomutt/issues/2002 Thanks for the feedback. [...] > Your rationale for downgrading the severity of an issue like this is that it > doesn't bother you personally? My rationale, if you must know, is that if this is an important issue, then the people who consider it an important issue will ofcourse work on getting it fixed. There's nothing in debian policy (the document who defines the severity levels for the bug tracking system) that says 'If you raise the severity of a bug report then "someone else" has to do the work for you'. Scratch your own itch. The previously provided suggestion that this might lead to data loss is a bit far fetched if you ask me. Let a monkey hammer on your keyboard long enough and he'll eventually manage to do 'rm -rf ~' which doesn't necessarily imply that all terminal emulators must be removed from Debian. In other words, anything can be described as 'data loss' if your imagination is good enough. Regards, Andreas Henriksson
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
On Mon, Mar 02, 2020 at 02:22:44PM +0100, Andreas Henriksson wrote: Hi, > > when mutt prompts for something (e.g. To: address, Subject etc.) it > > previously was possible to just keep pressing backspace until whatever > > default text was there disappeared. > > > > As of this version, it's possible to keep erasing back beyond the first > > character of the string; > [...] > > On Fri, Feb 14, 2020 at 11:31:53AM -0500, Marvin Renich wrote: > > Control: -1 severity grave > > > > I'm increasing the severity of this bug, as it can cause unintended > [...] > > I just NMUed a new upstream version of neomutt, 20191207+dfsg.1-1, > which fixes the two other outstanding RC bugs. > It seems I can still reproduce this issue however (with the first prompt > I get which is the imap password prompt for me). > > This seems somewhat like a possible UX design fail. This is done > upstream and not in debian. Do you know if there's already been any > discussion regarding this upstream? If not could you please file an > upstream bug report about this? https://github.com/neomutt/neomutt/issues/2002 > The behaviour hasn't really bothered me and I probably wouldn't even > have noticed it if it wasn't for this bug showing up on the RC bug radar > while doing my NMU, so I'm quite tempted to downgrade severity again. Your rationale for downgrading the severity of an issue like this is that it doesn't bother you personally? Best regards, András -- My wife said I needed to grow up. I was speechless. It's hard to say anything when you have 45 gummy bears in your mouth.
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
Control: found -1 20191207+dfsg.1-1 Hello, On Sun, Nov 24, 2019 at 11:10:33PM +0100, Andras Korn wrote: > Package: neomutt > Version: 2019+dfsg.1-1 > Severity: normal > > Hi, > > when mutt prompts for something (e.g. To: address, Subject etc.) it > previously was possibly to just keep pressing backspace until whatever > default text was there disappeared. > > As of this version, it's possible to keep erasing back beyond the first > character of the string; [...] On Fri, Feb 14, 2020 at 11:31:53AM -0500, Marvin Renich wrote: > Control: -1 severity grave > > I'm increasing the severity of this bug, as it can cause unintended [...] I just NMUed a new upstream version of neomutt, 20191207+dfsg.1-1, which fixes the two other outstanding RC bugs. It seems I can still reproduce this issue however (with the first prompt I get which is the imap password prompt for me). This seems somewhat like a possible UX design fail. This is done upstream and not in debian. Do you know if there's already been any discussion regarding this upstream? If not could you please file an upstream bug report about this? The behaviour hasn't really bothered me and I probably wouldn't even have noticed it if it wasn't for this bug showing up on the RC bug radar while doing my NMU, so I'm quite tempted to downgrade severity again. Please work this out with upstream if this issue is important to you. Please give feedback on this bug report about upstream discussions or relevant commits and I'm happy to look into cherry-picking and NMUing those as needed. Regards, Andreas Henriksson
Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace
Package: neomutt
Version: 2019+dfsg.1-1
Severity: normal
Hi,
when mutt prompts for something (e.g. To: address, Subject etc.) it
previously was possibly to just keep pressing backspace until whatever
default text was there disappeared.
As of this version, it's possible to keep erasing back beyond the first
character of the string; for example, when composing mail, backspacing
beyond the beginning of the offered Subject brings up the editor
with the message being composed; saving and exiting shows that the Subject
is in fact not empty but the default (e.g. "Re: original subject").
Backspacing beyond the beginning of the To: prompt likewise confirms the
default To: address and goes to the Subject prompt.
This behaviour is completely counter-intuitive and hopefully not
intentional.
I can reproduce it with mutt -F /dev/null, leading me to beleive it's not a
problem with my configuration.
Andras
-- Package-specific info:
NeoMutt 2019
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.
System: Linux 4.4.185-vs2.3.9.8+uksm (x86_64)
ncurses: ncurses 6.1.20191019 (compiled with 6.1.20191019)
libidn: 1.33 (compiled with 1.33)
GPGme: 1.13.1-unknown
hcache backends: tokyocabinet
Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-19'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191109 (Debian 9.2.1-19)
Configure options: --build=x86_64-linux-gnu --prefix=/usr
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man}
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu}
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss
--idn --mixmaster --sasl --tokyocabinet
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/neomutt-jdVSn8/neomutt-2019+dfsg.1=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include
-I/usr/include/lua5.3 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5
Default options:
+attach_headers_color +compose_to_sender +compress +cond_date +debug
+encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color
+initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop
+progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar
+skip_quoted +smtp +status_color +timeout +tls_sni +trash
Compile options:
-autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens
+getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify
-locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +sasl +smime
-sqlite +start_color +sun_attachment +typeahead
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"
To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to:
-- System Information:
Debian Release: 10.0
APT prefers unstable
APT policy: (350, 'unstable'), (350, 'stable'), (98, 'eoan-updates'), (98,
'eoan-security'), (98, 'eoan-proposed'), (98, 'eoan-backports'), (98, 'eoan'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.185-vs2.3.9.8+uksm (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
