Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-30 Thread Robert O'Callahan
On Tue, Dec 1, 2015 at 4:26 AM, Ehsan Akhgari wrote: Should we finally bite the bullet and force a flush in reftests/crashtests? You mean force a flush in the load event handler in the test harness, before the test's load event handler runs? > After thinking about

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-30 Thread Ehsan Akhgari
On 2015-11-28 1:00 AM, Boris Zbarsky wrote: On 11/27/15 2:15 AM, Axel Hecht wrote: I wonder, how much of the web could rely on this, given our tests do? Our test failures were mostly along the lines of "we expected an assertion here and now we don't get one". I doubt that would much affect

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-30 Thread Boris Zbarsky
On 11/30/15 4:09 PM, Robert O'Callahan wrote: I think we should just grind through reftest/crashtests and add an explicit flush to every onload/load event handler. There may be mochitests affected too. At least the ones using window screenshots, but possibly some other ones that aim to not

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-29 Thread Vivien Nicolas
Thanks for the information. On Sat, Nov 28, 2015 at 7:02 AM, Boris Zbarsky wrote: > On 11/27/15 5:33 AM, Vivien Nicolas wrote: > >> But don't we need at least a Flush_Style to make sure the CSS that tries >> to >> use background-image will start triggering images decoding and

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-27 Thread Boris Zbarsky
On 11/27/15 3:16 AM, L. David Baron wrote: (If that is a problem, we could still flush style instead of layout.) We always flush style before onload, because otherwise we wouldn't block onload on things like background images specified in CSS. -Boris

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-27 Thread Boris Zbarsky
On 11/27/15 2:15 AM, Axel Hecht wrote: I wonder, how much of the web could rely on this, given our tests do? Our test failures were mostly along the lines of "we expected an assertion here and now we don't get one". I doubt that would much affect the web. -Boris

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-27 Thread Boris Zbarsky
On 11/27/15 5:33 AM, Vivien Nicolas wrote: But don't we need at least a Flush_Style to make sure the CSS that tries to use background-image will start triggering images decoding and block the onload event ? Yes, we do. That's handled in nsDocLoader::DocLoaderIsEmpty. -Borsi

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-27 Thread L. David Baron
On Friday 2015-11-27 08:15 +0100, Axel Hecht wrote: > I wonder, how much of the web could rely on this, given our tests do? What about starting of CSS transitions? Could pages be relying on making a style change in onload starting a transition? Or do other browsers not guarantee that? (If that

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-27 Thread Vivien Nicolas
It may be a stupid question as my understanding of this part of the code is flaky. But don't we need at least a Flush_Style to make sure the CSS that tries to use background-image will start triggering images decoding and block the onload event ? I just want to make sure it won't create

Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-26 Thread Robert O'Callahan
We've always done it, but I can't think of any good reasons. I seem to recall that one reason was we want onload to be usable to measure page-load-and-layout time, but that would be a bad reason. If we didn't do that, we could run onload scripts earlier and maybe do less layout if they update the

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-26 Thread Boris Zbarsky
On 11/26/15 9:24 PM, Robert O'Callahan wrote: We've always done it, but I can't think of any good reasons. I've tried to fix this in the past and ran into two problems. The first problem was that some tests failed as a result. This is somewhat minor, really. The second problem, pointed

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-26 Thread Robert O'Callahan
On Fri, Nov 27, 2015 at 3:59 PM, Boris Zbarsky wrote: > On 11/26/15 9:24 PM, Robert O'Callahan wrote: > >> We've always done it, but I can't think of any good reasons. >> > > I've tried to fix this in the past and ran into two problems. > > The first problem was that some tests

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-26 Thread Xidorn Quan
On Fri, Nov 27, 2015 at 6:15 PM, Axel Hecht wrote: > On 11/27/15 4:09 AM, Robert O'Callahan wrote: >> >> On Fri, Nov 27, 2015 at 3:59 PM, Boris Zbarsky wrote: >> >>> On 11/26/15 9:24 PM, Robert O'Callahan wrote: >>> We've always done it, but I can't think

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-26 Thread Axel Hecht
On 11/27/15 4:09 AM, Robert O'Callahan wrote: On Fri, Nov 27, 2015 at 3:59 PM, Boris Zbarsky wrote: On 11/26/15 9:24 PM, Robert O'Callahan wrote: We've always done it, but I can't think of any good reasons. I've tried to fix this in the past and ran into two problems.

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

2015-11-26 Thread Robert O'Callahan
On Fri, Nov 27, 2015 at 8:29 PM, Xidorn Quan wrote: > Our tests relying on this is probably because certain bugs are only > detectable when we apply content/style change after a layout flush. > That's right. This change is likely to hide more bugs than it causes. Rob --