Can MAX_REFLOW_DEPTH be increased?

In the days of Windows 95, recursive algorithms in layout used to overrun the call stack on Windows unless the depth of the DOM tree was limited. The HTML parser still enforces the limit, and people complain about it from time to time. (Most of the time, the Web pages that hit the limit are doing s

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 10:22 AM, Henri Sivonen wrote: > If the depth limit is still needed, can now be increased? What do other UAs do? This seems like it may as well be standardized, just so the odd corner-case page breaks the same in all UAs. ___ dev

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 2:01 PM, Aryeh Gregor wrote: > On Mon, May 2, 2016 at 10:22 AM, Henri Sivonen wrote: >> If the depth limit is still needed, can now be increased? > > What do other UAs do? This seems like it may as well be standardized, > just so the odd corner-case page breaks the same in

Re: Can MAX_REFLOW_DEPTH be increased?

Test-case: var cur = document.querySelector("script"); var depth = -1; while (cur) { cur = cur.parentNode; depth++; } document.body.textContent = depth; Outputs 513 in Chrome. It looks like any further s are inserted as siblings instead of children. The is processed correctly. IE11

Re: Can MAX_REFLOW_DEPTH be increased?

On Monday 2016-05-02 10:22 +0300, Henri Sivonen wrote: > In the days of Windows 95, recursive algorithms in layout used to > overrun the call stack on Windows unless the depth of the DOM tree was > limited. The HTML parser still enforces the limit, and people complain > about it from time to time.

Re: Can MAX_REFLOW_DEPTH be increased?

This might be helpful: http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#3440 I can't vouch 100% for its accuracy, but it's probably pretty close. In general, dynamic stack checks (measuring the top of the stack at XPCOM startup, and comparing it with the stack at th

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 8:07 PM, Bobby Holley wrote: > In general, dynamic stack checks (measuring the top of the stack at XPCOM > startup, and comparing it with the stack at the point of interest) seem > preferable to hard-coding number-of-recursive-calls, since it doesn't > depend on the size of

Re: Can MAX_REFLOW_DEPTH be increased?

On Monday 2016-05-02 10:07 -0700, Bobby Holley wrote: > This might be helpful: > http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#3440 > > I can't vouch 100% for its accuracy, but it's probably pretty close. > > In general, dynamic stack checks (measuring the top of

Re: Can MAX_REFLOW_DEPTH be increased?

On Monday 2016-05-02 20:31 +0300, Aryeh Gregor wrote: > On Mon, May 2, 2016 at 8:07 PM, Bobby Holley wrote: > > In general, dynamic stack checks (measuring the top of the stack at XPCOM > > startup, and comparing it with the stack at the point of interest) seem > > preferable to hard-coding number

Re: Can MAX_REFLOW_DEPTH be increased?

Would it be feasible to rewrite the recursive code to be iterative, and keep state in an explicit data structure? That would make it much easier to keep the behavior predictable and consistent across platforms. On Mon, May 2, 2016 at 10:34 AM, L. David Baron wrote: > On Monday 2016-05-02 10:07

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 8:51 PM, L. David Baron wrote: > So, at the very > least, limiting in the parser isn't effective anymore and we need > checks at later stages, which hopefully could be done in a > standardizable way. Having dynamic fallback checks for anything not currently standardized is

Re: Can MAX_REFLOW_DEPTH be increased?

It makes me nervous to try to make the overflow behavior the same across engines, because it could end up restricting implementation choices. But making things roughly the same without trying to make them too much the same seems reasonable. And it does sound like there are situations where we j

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 9:19 PM, Steve Fink wrote: > It makes me nervous to try to make the overflow behavior the same across > engines, because it could end up restricting implementation choices. But > making things roughly the same without trying to make them too much the same > seems reasonable.

Re: Can MAX_REFLOW_DEPTH be increased?

On 5/2/16 2:15 PM, Aryeh Gregor wrote: If the idea is to stop stack overflow, it doesn't make sense to me to have the check in the parser at all. It should be on the DOM level. Otherwise, scripts could make an arbitrarily deep stack, like this: Now we enter the discussion of threat models. Sc

Re: Can MAX_REFLOW_DEPTH be increased?

On 5/2/16 2:30 PM, Aryeh Gregor wrote: What's the problem with standardizing completely if we pick the limit to be low enough that we have plenty of room? Please define "Plenty of room"? For a 900KB stack (what we have on Windows, per

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016, at 12:51 PM, L. David Baron wrote: > Do you happen to know what the main thread stack size is on the > platforms that we run on? On Windows/x86 it's 1MB, Windows/x86-64 it's 2MB, on Linux and OS X it's 8MB (all reserved, not committed, AIUI). > One risk of such a change: I'm

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 9:58 PM, Boris Zbarsky wrote: > For a 900KB stack (what we have on Windows, per > ) > 512 DOM nodes deep corresponds to ~2KB per DOM node. 200 deep corresponds > to 5KB. > > Now quick, tel

Re: Can MAX_REFLOW_DEPTH be increased?

On 5/3/16 6:59 AM, Aryeh Gregor wrote: Sure. The same is potentially true if the stack depth limit is 200. Did anyone do all these calculations to determine that was safe, or did they just pick a number and see what worked? I don't know, honestly. This code is pretty old. By your logic, ma