Shortcut for launching the modal can trigger shortcuts inside the modal, to override default settings

swoh816 commented 11 months ago

Please check that this issue hasn't been reported before.

[X] I searched previous Bug Reports didn't find any similar reports.

Expected Behavior

'Create or edit Task' Modal shows Normal priority by default.

Current behaviour

If you set the shortcut for "Create or edit task" to Alt + l, the 'Create or edit Task' Modal pops up with the priority set to Low (which is set to Normal by default).

This is generally applicable: If you set the shortcut for "Create or edit task" the same as the shortcut for any of the items inside the 'Create or edit Task' Modal, the modal opens with the item being affected. For example, if you set the shortcut for "Create or edit task" to Alt + f, which is a shortcut for "Only future dates" inside 'Create or edit Task' Modal, using the shortcut in the document opens the modal with "Only future dates" disabled. ("Only future dates" is enabled by default.)

Thank you very much for the amazing plugin!

Steps to reproduce

Change shortcut for "Create or edit task" to Alt + l
Press Alt + l to open 'Create or edit Task' Modal
You can find the priority is set to Low (the default behaviour is to have Normal priority)

Which Operating Systems are you using?

[ ] Android
[ ] iPhone/iPad
[X] Linux
[ ] macOS
[ ] Windows

Obsidian Version

1.4.16

Tasks Plugin Version

5.2.0

Checks

[X] I have tried it with all other plugins disabled and the error still occurs

Possible solution

Make shortcuts in the 'Create or edit Task' Modal active after the modal is loaded completely so that the modal's default behaviour is not affected by whatever shortcut was used for opening the modal.

claremacrae commented 11 months ago

Hi @swoh816, thank you for logging this. It's a new report, I've not seen it before.

I've edited the issue title to make it more specific.

claremacrae commented 11 months ago

I can confirm that this is reproducible on Mac.

Set the hotkey for Tasks: Create or edit task to Ctrl + Opt + O
Put the cursor on a blank line in Source or Live Preview Mode
Type Ctrl + Opt + O

Expected: Priority is Normal Actual: Priority is Lowest

claremacrae commented 11 months ago

I've no experience to know how to fix this, and because Obsidian allows user control of the shortcuts for commands like opening the Tasks modal, I'm afraid it's not a priority for me personally to fix it. There are other more widely applicable ways I can spend my time on Tasks.

I can think of the following workarounds:

Change the hotkey for Tasks: Create or edit task to a key that is not used in this modal.
Turn off shortcuts in the modal.

claremacrae commented 11 months ago

I've added the 'help-wanted' label to this.

In case anyone with Svelte experience is interested in fixing this:

The source file is src/ui/EditTask.svelte
There is quite a comprehensive guide on Contributing to tasks.
I would be available to pair with anyone with Svelte experience, to pool knowledge... Please use the email address in my GitHub profile to set up a session to work together.

claremacrae commented 10 months ago

I've noted this limitation in the docs - see https://github.com/obsidian-tasks-group/obsidian-tasks/commit/698565706f8f90ee3f3f73235c2f3010cc0b393a.

This will be published as part of the next Tasks release.

claremacrae commented 10 months ago

I wonder whether the following code is anything to do with the problem:

https://github.com/obsidian-tasks-group/obsidian-tasks/blob/7e9f420c448ee290071679c93af6b02e4290e616/src/ui/EditTask.svelte#L278-L286

And it's referenced on line 397 here:

https://github.com/obsidian-tasks-group/obsidian-tasks/blob/7e9f420c448ee290071679c93af6b02e4290e616/src/ui/EditTask.svelte#L394-L401

I expect that:

the keyDown event is coming from typing the shortcut/hotkey outside of the modal, and then the modal is opened
and then the keyUp happens once the modal is opened, triggering the selection of the priority corresponding to the shortcut/hotkey

Maybe there's a fix around having the modal keep track of key-down events as well as key-up ones - and only acting on the key-up if it had previously seen the key-down.

I can imagine that will lead to corner cases with issues of timing of typing, and will be rather hard to test reliably.

obsidian-tasks-group / obsidian-tasks