I think the issue is that the footer is not part of the initial dialog height calculation since it's shown asynchronously (when there's article count). When the dialog is opened before fetchTasksAndUpdateView resolves, the footer is shown afterwards. This is more consistently reproducible with slow connections (or with network throttle).

In the screen recording here, the first time the dialog is shown, the footer is not present so when the footer is shown, it overlaps. In the subsequent showing, the dialog's height takes into account that of the footer.

Additionally when this occurs, the first count is 5 and the subsequent count shown is 0. This is because the dialog state is backed up when it's shown. However, if the API request to fetch tasks responds after the dialog is shown, the state that's backed up is that prior to the tasks are fetched.

I've seen the issue happening couple of times but never had reliable steps to introduce. Checked on testswiki wmf.21 - the vertical scrolling is added if a screen height requires it; the footer is fully displayed all the time.