Two geometry defects were observed in passing while fixing the off-screen quick-create popover (#971). Neither was in that PR's scope, and neither has been verified end-to-end — stage 1 of any work here is to confirm each claim at the source before writing a fix.
1. Week view computes column width from a container width that may already exclude the gutter
apps/desktop/src/renderer/src/components/calendar/use-week-infinite-scroll.ts:45-46
if (containerWidth <= gutterWidth) return MIN_COLUMN_WIDTH
return Math.max(MIN_COLUMN_WIDTH, (containerWidth - gutterWidth) / COLUMNS_PER_PAGE)
The reported symptom is that gutterWidth is subtracted from a containerWidth that has already had the gutter removed, so each column comes out narrower than a seventh of the available strip and a stray partial 8th column is left visible at the edge.
To verify: trace what containerWidth actually measures at the call site (calendar-week-view.tsx:109 passes gutterWidth: GUTTER_WIDTH) — specifically whether the measured element includes the time gutter or starts after it. If it already excludes the gutter, the subtraction is a double-count; if it includes it, the current code is correct and this item is invalid.
2. Marquee auto-scroll writes scrollTop on an element that may not be the scroll container
apps/desktop/src/renderer/src/components/calendar/use-time-grid-marquee.ts:196 and :205
el.scrollTop -= speed // and += speed in the opposite branch
The reported symptom is that el here is the grid content div rather than the scrollable ancestor, making drag auto-scroll a silent no-op in both day and week views: dragging a marquee selection to the top or bottom edge does not scroll the grid, so a selection cannot be extended past the visible hours.
To verify: confirm which element carries the scroll (overflow-y) in day and week view, and whether el resolves to it. Note the same el.scrollTop is read at :93 and :111 for coordinate math — if el is the wrong element, those reads are consistently 0 and the reads are self-consistent with the writes, which is why nothing looks broken in the code.
Why this is filed rather than fixed
Both are user-visible but neither is a data-loss or sync defect, and both need their own reproduction. The popover fix in #971 is independent of them and is already on main.
Two geometry defects were observed in passing while fixing the off-screen quick-create popover (#971). Neither was in that PR's scope, and neither has been verified end-to-end — stage 1 of any work here is to confirm each claim at the source before writing a fix.
1. Week view computes column width from a container width that may already exclude the gutter
apps/desktop/src/renderer/src/components/calendar/use-week-infinite-scroll.ts:45-46The reported symptom is that
gutterWidthis subtracted from acontainerWidththat has already had the gutter removed, so each column comes out narrower than a seventh of the available strip and a stray partial 8th column is left visible at the edge.To verify: trace what
containerWidthactually measures at the call site (calendar-week-view.tsx:109passesgutterWidth: GUTTER_WIDTH) — specifically whether the measured element includes the time gutter or starts after it. If it already excludes the gutter, the subtraction is a double-count; if it includes it, the current code is correct and this item is invalid.2. Marquee auto-scroll writes
scrollTopon an element that may not be the scroll containerapps/desktop/src/renderer/src/components/calendar/use-time-grid-marquee.ts:196and:205The reported symptom is that
elhere is the grid content div rather than the scrollable ancestor, making drag auto-scroll a silent no-op in both day and week views: dragging a marquee selection to the top or bottom edge does not scroll the grid, so a selection cannot be extended past the visible hours.To verify: confirm which element carries the scroll (
overflow-y) in day and week view, and whetherelresolves to it. Note the sameel.scrollTopis read at:93and:111for coordinate math — ifelis the wrong element, those reads are consistently 0 and the reads are self-consistent with the writes, which is why nothing looks broken in the code.Why this is filed rather than fixed
Both are user-visible but neither is a data-loss or sync defect, and both need their own reproduction. The popover fix in #971 is independent of them and is already on main.