Observing that there have been several long-outstanding bugs with Kinetic that have yet to be addressed in 2026.100, I thought a novel approach to the issue might be interesting;
This chrome extension serves as a man-in-the-middle, hijacking Epicor’s main.js mid-stream from the server to you, and making some changes on the fly that are only possible by correcting upstream (Epicor, #pleasefix) - as this performs some sensitive man-in-the-middle behavior, I’ve posted the source / GitHub below.
NOTE: the extension will reload all of your Epicor tabs when you activate it. (In order to hijack main.js)
This extension aims to fix:
Grouping issues - Kinetic’s performance tanks when utilizing grouping above a certain number of rows (varies according to your computer’s hardware, browser, OS settings, etc.) - this mainly appears to be due to memory usage/leak/lack of GC.
Blank grid issues when scrolling
Grid “twitchiness” when scrolling (jumps up/down when clicking things)
Combo-Box popups requiring two clicks to actuate when the viewport width is <480px (combo box switches to use Kendo UI’s adaptive popup mode and fails to trigger actions the first click)
Added Stuff for funsies:
Disable theming
Choose specific colors
Fine-tune control padding / spacing - allow for larger font/text or smaller without scaling the browser zoom
This extension also provides a decent platform for us to do a sort of “Epicor Ideas” thing, where we can fully cook the idea and showcase it, maybe fully baked ideas would get some more traction with Epicor.
Here’s the source code, which is AI written and proof-of-concept status:
Screenshots with spacing/padding set to minimums, from Epicor Education (Left: With extension, Right: Stock)
Nice job Gabe! Great extension! Thanks for sharing.
Been thinking about the same. Would be nice to refine a method that patches using the object model to make ‘fully-baked’ a reality. My fear is that traction, if at all possible, may only be likely if we can show a near-exact diff to the mainjs source code.
In other words, monkey-patch specific methods like your wrapProviderPrototype, but do so by:
push generic patch loader via function to avoid the need for a browser extension.
loader: finds target object constructors at runtime via object model & matching args
caller: loads straight-up js patches from disk via func > IIFE or simple expression eval
patches fire either: before, over, or after targeted proto method via config convention.
So the actual patch (what we want Epicor to see) is distinct from the loader/extension/hack etc and mapping to the actual mainjs fix is direct or at least very straight forward at a glance.
I’ve got a POC for patching event actions and worked on one for components. Happy to share.
Would be great to end up with a couple of top-level patch script loader functions and then let folks go wild with tiny patch scripts experiments (in pilot/edu of course ;-). resulting in a shared library of viable patch scripts. perhaps someday commit to a shared repo w issue log, before n after docs, code diffs, and there you have it, maybe ‘they’ will come.
Keep in mind that the main.js we see is the post-webpack minified build, so if we tried to generate a “diff” style patch against main.js, in the end that likely wouldn’t be any more useful to Epicor than a well-written call out of logic issues against particular methods; Prism should be able to work it’s way back from that to their internal source and apply patches as needed. I ensured to provide that documentation on the github repo.
This extension was born from a discussion at Epicor Insights w/several other EpiUsers/Customers and Epicor, voicing our concerns about grid performance issues (and other issues that seem to not be taking precedence for bugfix over other feature branches/releases). During that discussion I proposed that the grid performance issues were not insurmountable and offered to provide a fix. Ball’s in their court to take the demonstrated correction and upstream it.
Ideally, we push for something like that to be implemented upstream as well (Extend the concept of BPMs into the client - pre/base/post hooks on the various methods - this way we avoid the use of an invasive extension that requires debugger permissions.
It sounds a little far-fetched, but hey, they did it on the server end with the business objects, it makes the same amount of sense here if they want to stick to their niche of being highly-to-extremely extensible.
Fixing grid scrolling is a great improvement! In particular, I’ve mapped scrolling to the keyboard for ergo reasons, and boy howdy do epicor grids lose their freakin minds when they’re spammed with uninterrupted scroll input.
The upper level max-width constraints are another really easy annoyance to fix in the browser. Overriding max-width in .page-content, .ep-view, and .ep-view-fixed-header banishes that problem.
Adjust minimal padding mode to affect more Kinetic Components, adjust sizing/spacing at minimal to allow for more information density by auto-sizing text areas to fit content, making tags smaller, etc.:
Note: Looks like these changes to grid rendering broke the grouping fix (grouping doesn’t render now) - will fix tonight and build in a test script so it doesn’t break again!
