Unplanned
Last Updated: 09 Jun 2026 07:33 by Yuriy Rogach
Yuriy Rogach
Created on: 09 Jun 2026 07:33
Category: Calendar
Type: Bug Report
0
RadCalendar view goes permanently blank when navigating forward with browser zoom ≠ 100%

verified still present in 2026.2.519 — RadCalendarScript.js

When `EnableNavigationAnimation` is enabled (the default) and the browser zoom is not 100% (and Windows uses fractional display scaling such as 125%/150%),
navigating the RadCalendar to the NEXT month removes the day grid and never renders the new one. The calendar title updates, but the view area stays empty permanently. 
Because `_enableNavigation(false)` and `EnableDateSelect = false` are set before the animation and only restored when it completes, the calendar is also left with navigation 
and date selection disabled — the control is dead until the page is reloaded.

Navigating BACKWARD works correctly (see root cause below for why), which is a useful way to confirm this specific bug.

End users hit this routinely because Chrome persists per-site zoom and many laptops default to 125%/150% display scaling.

 Steps to reproduce:
 1. Page with a default RadCalendar:

<telerik:RadCalendar ID="RadCalendar1" runat="server" EnableNavigationAnimation="true" />

  2. Open in Chrome, set zoom to 110% (Ctrl and +), reload.
  3. Click the "next month" arrow (repeat at a couple of zoom levels, e.g. 110%,
     125%, 150% — whether a given level triggers it depends on rounding of the
     calendar's rendered width).

Root cause (from RadCalendarScript.js, CalendarView.ApplyViewTable)
The navigation animation detaches the current day-grid table, parks the old and new tables inside a temporary scroll container, and animates `scrollLeft`. Thenew table is re-attached to the DOM only when the animation loop finishes:

c = function () {
          o > 0 && r.scrollLeft + r.offsetWidth < r.scrollWidth ||
          o < 0 && r.scrollLeft > 0
              ? (r.scrollLeft += 10 * o, window.setTimeout(c, 10))
              : d();   // d() re-attaches the new table and re-enables the control
      };

`Element.scrollLeft` is a fractional double, while `offsetWidth`/`scrollWidth` are rounded integers. At zoom levels other than 100%, `scrollLeft` clamps at a fractional maximum (e.g. 219.4545) while the rounded widths suggest an integer maximum (e.g. 220 with scrollWidth 440). The forward-direction termination
 check `scrollLeft + offsetWidth < scrollWidth` (439.45 < 440) then remains true forever: `scrollLeft += 10` is clamped and makes no further progress, so the loop reschedules itself indefinitely and `d()` is never called. The new view table is never appended, and navigation/date selection are never re-enabled.

The backward direction terminates on `scrollLeft > 0`, and `scrollLeft` clamps to exactly 0 — which is why only forward navigation is affected.


Workaround

Setting `EnableNavigationAnimation="false"` avoids the animation code path entirely and fully resolves the issue.

 

0 comments