On Mon, Sep 11, 2017 at 3:49 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: >> I'd expect text node recovery (flattening out elements and just >> considering text nodes) in the frame constructor to be a more robust >> solution than trying to address the problem in the HTML parser. What's >> the feasibility of such a frame constructor change? > > > Just doing that for initial construction is probably not too terrible. > > Making it behave correctly (read: not crash exploitably) in the face of > dynamic mutations is pretty hard, because it would violate various layout > and frame constructor invariants.
I see. :-( >> My findings from testing with a very high limit so far are as follows: > > > What testcases were used? The actual stack depth needed for frame > construction and layout is highly styling-dependent, because it affects what > codepaths are taken. For example, I would expect something like this: > > <!DOCTYPE html> > <div><div>.... It was <div>s without any custom styling: https://hsivonen.com/test/moz/deeptree/ > To need less stack than something like this: > > <!DOCTYPE html> > <style>div { display: table-cell }</style> > <div><div>.... What kind of style would have the maximum stack frame size? Is display: table-cell enough to trigger the worst case? Also, now that a stack overflow crashes the content process but not the whole browser, a limit that's small enough never to overflow the stack even with worst-case styling probably leads to worse user experience than a higher limit that could crash the content process with worst-case styling but that causes emails to render in the common case. >> * Windows 64-bit: between 740 and 750. >> * 32-bit Firefox on 64-bit Windows 10: between 500 and 510. >> * 32-bit Firefox on 64-bit Windows 7: between 510 and 520. > > > Were those measurements done with PGO builds? We need to make sure we do > that, because PGO builds have quite different (and larger) stack frame > sizes. For platforms that offer a PGO option on try, yes: https://treeherder.mozilla.org/#/jobs?repo=try&revision=43cfdbbb164b0638d21fca054d5facc894633deb&selectedJob=130001915 https://treeherder.mozilla.org/#/jobs?repo=try&revision=40d92f2beae262ce502d9c57a0e5666157c584f9&selectedJob=130032494 >> As for other browsers: >> I didn't find a depth limit for Chrome. (Tried up to 16000.) > > > Which version of Chrome? 64-bit Ubuntu-shipped Chromium 60 and 64-bit Google-shipped Chrome 60 on Windows 10. > Per comments in > https://bugzilla.mozilla.org/show_bug.cgi?id=485941 at least in their XML > parser they do have a depth limit of about 5000, but that was apparently > removed and then readded recently. Of course they may have different > behavior for XML and HTML. Maybe they have a limit that preserves text node visibility (as our HTML parser does when the workaround works as designed). I guess I should add some JS that computes the DOM depth. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
