misplaced date picker control when creating or editing tasks from within board view

[imfx77]

Checklist

• I verified that Kanboard is correctly installed
• I verified that the problem does not come from a plugin
• I verified that the problem is not already reported
• I understand that Kanboard is in maintenance mode. It doesn't mean it's abandoned, but there is no significant feature development

Actual behaviour

When creating or editing a task the date picker control (3) is way down the page and sometimes even outside the page which makes it unreachable and unusable. Please, refer the screenshot attached and pay attention to the labeled parts:

1. date edit control
2. the position of the date picker control
3. the date picker control itself
4. the scrollbar of the underlying page (in my case this is the board view)

Expected behaviour

I would expect the date picker control (3) to be positioned right under the date edit control (1), pls refer the screenshot.

Steps to reproduce

I would be guessing but I think the behavior is somehow related to the height of the underlying page and the scroll position. Probably the incorrect behavior could be reproduced on any page under certain conditions, but it is easier to do so in board view.

1. switch to board view
2. make sure the page is long enough and the scrollbar is at most 1/3 of it (e.g. I have multiple lanes all expanded, but you can just put many task in a column to make the page height large enough)
3. click on create task or edit an existing one
4. PAY ATTENTION that while in the modal overlay of editing a task the scrollbar of the underlying page (4) is still active and scrollable (not aware if this is an intended behavior)
5. NOW click start or due date (1) to show the date picker (3)
6. NOTE that when the scrollbar is at the top then the position of the date picker is correct
7. BUT the more close to the bottom is the scrollbar position the more displaced down appears the date picker

So, if you picked or created some task at the bottom of the board view then the scrollbar will be initially at the bottom. Then while in the edit overlay and the date picker would appear way too down or outside the page. Current workarounds I've found are:

1. scroll up, then hide the date picker and show it again (yet the scroll behavior is probably a bug itself)
2. zoom out the page in the browser so to see the date picker that is out of view (yet this makes it highly inconvenient to use)

Screenshots

]

Logs

Configuration

• Kanboard version: 1.2.32
• Database type and version: sqlite 3.41.2
• PHP version: 8.2.8
• OS: Linux 4.4.302+ x86_64 (docker image on Synology)
• Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0

[fguillot]

Can you confirm that you don't have any plugin or theme that would affect Kanboard's default behavior?

I was not able to reproduce this issue (see attached screen recording below). I tested with Chrome and Firefox. Am I missing anything?

Screen.Recording.2023-10-09.at.9.21.01.PM.mov

[imfx77]

I have removed ALL plugins and disabled ALL browser extensions.
I don't use Chrome, but I reproduce the problem in both FF and Edge.

You don't seem to be missing anything from my repro. But might also try scrolling the underlying page while editing the task in the modal overlay and see if moves the page beneath or not (as I think this is the initial weirdness).

Here is what I do:
https://github.com/kanboard/kanboard/assets/76657062/e6cc1796-9c7c-4a91-a949-b859f3f3bf65

I can't imagine if it could have smth to do with dockerizing, I am using latest image from here:
https://registry.hub.docker.com/r/kanboard/kanboard/
I would appreciate any hints to further pinpoint the issue locally at my side, and then would report more details.

[imfx77]

If you check the impl of JQuery DatePicker Widget and specifically the call chain of
_dialogDatepicker(...) > _showDatepicker(...) > _checkOffset(...)
methods, it can be seen that the position of the widget depends on multiple parameters that are taken into account in various scenarios, and those include the width and the height of the entire browser client as well as the scrollLeft and scrollTop atttributes/methods for the whole document ( not just for the overlay element ! ).

Hence, I still believe that showing a modal overlay for creating/editing a task on top of the current page (e.g. Board View), with its content scrolled, is the cause for the incorrect widget offset. I just cannot say what exact border case I am hitting in order to produce it, or what subtle browser functionality suppresses it in order for you to not produce it.