Context / scenario

We run a large ASP.NET AJAX application with a fully custom, self-maintained CSS theme — we do not use any of Telerik's built-in skins. For this kind of setup we need complete control over every stylesheet that gets loaded into the page, both for consistency of our design system and to avoid unexpected CSS side effects or class-name collisions with resources we don't manage.

Issue

We found that fonticons.css is automatically and unconditionally injected by the Lightweight rendering path used by the controls (e.g. RadButton, RadTextBox, and other controls using the Lightweight render mode). This injection happens regardless of the EnableEmbeddedSkins and EnableEmbeddedBaseStylesheet settings, which normally let developers opt out of Telerik's embedded/base CSS resources. In other words, even with both of those settings disabled and no skin applied, fonticons.css is still loaded — there is currently no supported way to prevent it.

We raised this with Telerik support and it was confirmed internally: the fonticons.css injection is currently hard-wired into the Lightweight rendering path and is not gated by any existing configuration option.

Why this matters

• It breaks the expectation that EnableEmbeddedSkins / EnableEmbeddedBaseStylesheet = "nothing gets injected automatically" for teams running a fully custom theme.
• It adds an extra, unaccounted-for HTTP resource / set of CSS rules (font-face declarations and generic icon base classes) that our theme did not ask for and cannot easily audit or version alongside the rest of our stylesheet.
• Teams with strict content-security / asset-inventory requirements (e.g. wanting every loaded CSS file to be explicitly declared and controlled) currently have no clean way to achieve that with Telerik controls in Lightweight mode.
• The only current workaround (intercepting or modifying Telerik's internal resource registration) is explicitly discouraged by Telerik support itself, since that internal logic can change between versions and is not a supported extension point.

Feature request

Introduce a supported opt-out for the automatic fonticons.css injection in the Lightweight rendering path — for example, a new setting such as EnableFontIcons (page/control or global web.config level, consistent with how EnableEmbeddedSkins / EnableEmbeddedBaseStylesheet are already exposed) that lets developers explicitly disable this injection when they provide their own icon/font handling.

We understand from Telerik support that this is not a small, isolated change — it requires auditing and refactoring how style resources are declared and loaded across the whole control set (including some legacy resource-registration code) before a dedicated opt-out setting can be safely introduced, and that this carries a real risk of regressions if rushed. We're not expecting a quick fix; we're submitting this as a tracked feature request, as recommended by Telerik support, so it can be prioritized and voted on by other customers with the same fully-custom-theme use case.

Suggested acceptance criteria

• A documented way (config setting and/or API) to disable automatic fonticons.css injection specifically in Lightweight rendering mode.
• Behavior consistent with EnableEmbeddedSkins / EnableEmbeddedBaseStylesheet: when disabled, no font-icon CSS is emitted by the framework, leaving the developer fully responsible for providing equivalent styles if needed.
• No behavior change for existing applications that don't set the new opt-out (backward compatible by default).

After upgrading to 2026.2.708, RadAsyncUpload file uploads fail with HTTP 403 Forbidden originating from the new CSRF validation (AsyncUploadHandler.ValidateCsrfToken). The handler returns an HTML error response.

The failure occurs only in our multi-host (load-balanced) environment. In multihost environment as well Issue is inconsistent. The exact same build works correctly on a single-node local/dev machine.

Refer support ticket raise for the Issue to get more detail.

RadAsyncUpload fails with HTTP 403 (ValidateCsrfToken) in multi-node/web-farm environment after upgrade to 2026.2.708 | View Ticket | Your Account

There is significant latency when a user has many images in a list or dropdown list, particularly those with sub-choices that also have images.  Because of this, we tried implementing design-time templates to allow lazy loading of images for RadComboBox.  While implementing a solution is possible, it was much more complicated than expected.

We have previuisly raised a feature request for simular controls that was fixed (Thanks for that) but our topp prioority component is The combobox. see Allow lazy loading of images with design-time templates for ListBox and ComboBox

During the discussion a few questions was rasied from telerik:

Currently, the ComboBox has the Load on Demand functionality which focuses on loading items as needed, but it does not specifically address lazy loading of images inside the templates. Before proceeding further, I’d like to confirm your current setup to suggest the best approach:

• Are you using server-side or client-side data binding with RadComboBox?
• Are you using design-time templates or injecting templates dynamically?
• How are images currently loaded in your ComboBox items?
• Is your main concern the initial load time, scrolling performance, or something else?

Reasons (Hope it makes sense)

• Only server-side databinding (with both controls).

• We are using both ItemTemplate with custom images (where we then control lazy loading ourselves) and ImageUrl where we lose this possibility and have issues. We also dynamically load custom controls (ITemplate) in a few places.