On Fri, Sep 15, 2017 at 12:26 PM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > From black-box testing, it seems that some part of layout has gotten a > new << 200 depth limit for nested display:table-cell some time between > September 11 and September 14. > > To save myself the trouble of bisecting this, does anyone know which > patch did this and why?
The above was based on running the wrong apk. Please disregard. However, investigating further showed that with display: table-cell the depth limit takes effect at a DOM depth that's about 1/5 of the stated limit. I'm assuming that anonymous frames count towards the limit and a display: table-cell that doesn't belong to a table ends up creating 5 frames. Correct? I guess this means that empirically finding the crash threshold for display: table-cell is more complicated than I thought and the numbers probably end up being such that the HTML parser won't be able to protect against nested table-cells hitting the frame construction limit without setting the HTML parser limit to something unreasonably low. Since we run unrelated sites in the same content process, we should avoid content process crashes more carefully than Chromium. Still, in some ways, crashing the content process indeed can be less confusing UX than parts of the page going silently missing. If we are going to keep *some* depth limit at which the frame constructor makes content not show up, it seems to me that it would be appropriate to make the frame constructor signal to the browser UI that it hit the limit so that the browser UI could show an infobar about parts of the page being omitted. I was investigating this very area and *still* I got confused by content disappearing and started to doubt my test case. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
