[
https://issues.apache.org/jira/browse/MYFACES-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18088523#comment-18088523
]
Werner Punz edited comment on MYFACES-4754 at 6/12/26 7:31 PM:
---------------------------------------------------------------
It was a valid request, and frankly I am glad you reported it, I really did not
have this on my radar, my last guess on this is that Chromium goes into some
Lisp style loop recursion on operations which spread big arrays instead of just
processing internal loop or jump statements.
I just wonder what prevents the Chromium guys to fix it on their end.
Nevertheless whether they will fix it one day or not, the code will work.
I wonder if Mojarra does have the same problem somewhere in their codebase and
Primefaces which also has its own internal implementation also (PF uses JQuery
internally, so they depend on jquery having fixed that or not)
Re performance I today ran a performance analysis on the code and found 1-2
additional hotspots, but in reality with a 200k div example they did not make a
huge difference, I could not see any measurable effect in a browser. I ran
another profiling session which gave me following results:
!image-2026-06-12-21-26-47-054.png|width=1348,height=298!
So the biggest load goes on the rendering, there is not that much potential
left on the js side, the scripts and dom replacement code are actually pretty
fast! The hotspot fixes will go into a future release given, they did not
produce any significant for your usecase, no need to push them into a new
ticket they will go in with the next fixes!
was (Author: werpu):
It was a valid request, and frankly I am glad you reported it, I really did not
have this on my radar, my last guess on this is that Chromium goes into some
Lisp style loop recursion on operations which spread big arrays instead of just
processing internal loop or jump statements.
I just wonder what prevents the Chromium guys to fix it on their end.
Nevertheless whether they will fix it one day or not, the code will work.
I wonder if Mojarra does have the same problem somewhere in their codebase and
Primefaces which also has its own internal implementation also (PF uses JQuery
internally, so they depend on jquery having fixed that or not)
> "Maximum call stack size exceeded" when AJAX updating large DOM in Chromium
> based browsers
> ------------------------------------------------------------------------------------------
>
> Key: MYFACES-4754
> URL: https://issues.apache.org/jira/browse/MYFACES-4754
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 4.1.3
> Reporter: Ben Chester
> Assignee: Werner Punz
> Priority: Major
> Fix For: 5.0.0, 4.0.4, 4.1.4
>
> Attachments: image-2026-06-11-19-42-58-778.png,
> image-2026-06-12-21-26-47-054.png
>
>
> We chased this down to the spread operator used in the bottom of
> `querySelectAllDeep` in DomQuery.ts. Changing those spread operators that
> just copy to `.slice()` appears to rectify the issue.
> This is caused by an issue that Chromium (or more specifically V8) is aware
> of but don't care to fix, the earliest report I could find is from 2022:
> [https://issues.chromium.org/issues/41467953] .
> The issue is reproducible with the following xhtml, which creates 100,000
> empty divs (it breaks somewhere between 60k and 70k). I believe the only
> thing that matters is the total number of elements in the DOM.
> {noformat}
> <!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml";
> xmlns:ui="jakarta.faces.facelets"
> xmlns:f="jakarta.faces.core"
> xmlns:h="jakarta.faces.html"
> ><h:body>
> <h:form>
> <ui:repeat begin="0" end="100000">
> <div/>
> </ui:repeat>
> <h:outputText value="Test Text"/>
> <br/>
> <h:commandLink
> id="testButton"
> value="Test"
> >
> <f:ajax
> execute="@this"
> render="testButton"
> />
> </h:commandLink>
> </h:form>
> </h:body></html>{noformat}
> I'm happy to prepare a PR for this if that'd help
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
