You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IframeLinker (deprecated) and CrossSiteIframeLinker (the current default) have a feature to split up strings passed to script blocks. There are roughly two considerations that have historically mattered here:
If chunks are too small, there are too many <script> blocks, which breaks IE (see defunct class JsIEBlockSizeVisitor, removed in github.com/gwtproject/gwt/commit/11bcab6517cb27940bb00df26f2be2310c73150b)
If chunks are too big, performance is bad in loading large <script> blocks in Firefox
The firefox performance issue was noted in 2009, and may no longer apply. Additionally, only the initial fragment has this applied anyway - all split points appear to have their output un-chunked (suggesting that these fragments loaded "slowly" in firefox at the time).
The impact of this feature is low - it helped contribute to #9931, and will require 2-3x the memory of the primary fragment in order to copy it. No user code can depend on this as a feature - it if there is no performance benefit to keep it, it seems easily worth removing/disabling.
It seems likely that this feature no longer matters, If so, we should consider one or more of the following:
Set the iframe.linker.script.chunk.size configuration property to -1 to disable the feature - this is a supported value, but the default is presently 30000.
Detect non--1 values when sourcemaps are enabled, optionally with a warning if another value is set.
IframeLinker (deprecated) and CrossSiteIframeLinker (the current default) have a feature to split up strings passed to script blocks. There are roughly two considerations that have historically mattered here:
<script>
blocks, which breaks IE (see defunct class JsIEBlockSizeVisitor, removed in github.com/gwtproject/gwt/commit/11bcab6517cb27940bb00df26f2be2310c73150b)<script>
blocks in FirefoxThe firefox performance issue was noted in 2009, and may no longer apply. Additionally, only the initial fragment has this applied anyway - all split points appear to have their output un-chunked (suggesting that these fragments loaded "slowly" in firefox at the time).
The impact of this feature is low - it helped contribute to #9931, and will require 2-3x the memory of the primary fragment in order to copy it. No user code can depend on this as a feature - it if there is no performance benefit to keep it, it seems easily worth removing/disabling.
It seems likely that this feature no longer matters, If so, we should consider one or more of the following:
iframe.linker.script.chunk.size
configuration property to-1
to disable the feature - this is a supported value, but the default is presently 30000.-1
values when sourcemaps are enabled, optionally with a warning if another value is set.See also:
The text was updated successfully, but these errors were encountered: