[
https://issues.apache.org/jira/browse/MYFACES-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18088330#comment-18088330
]
Werner Punz edited comment on MYFACES-4754 at 6/11/26 5:35 PM:
---------------------------------------------------------------
Ok after reading the bugreport it seems to me that there is a hard limit on
Chromium processing array sizes on certain operations probably an internal data
structure which has not enough bits to provide a bigger counter maybe an
accidental internal 16 bit limit. And yes the solution probably really is to
slice the array apart if it does not fail there and then process the subarrays
part by part. I need to test that, if the slicing works (Math.max on a spreaded
array fails) then we will have won. The issue is definitely not on the number
of dom nodes, but as the example suggests simply on the fact that certain
operations fail on big arrays (maybe just the max) either I I need to run tests
on that before fixing it, but slicing it if it works seems like a viable
strategy without a big performance impact!
was (Author: werpu):
Ok after reading the bugreport it seems to me that there is a hard limit on
chrome processing array sizes on certain operations probably an internal data
structure which has not enough bits to provide a bigger counter maybe an
accidental internal 16 bit limit. And yes the solution probably really is to
slice the array apart if it does not fail there and then process the subarrays
part by part. I need to test that, if the slicing works (Math.max on a spreaded
array fails) then we will have won. The issue is definitely not on the number
of dom nodes, but as the example suggests simply on the fact that certain
operations fail on big arrays (maybe just the max) either I I need to run tests
on that before fixing it, but slicing it if it works seems like a viable
strategy without a big performance impact!
> "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
>
> 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)
