Photon Engineering Newsletter #15

I’m back from a vacation to see the eclipse , so it’s time for Newsletter #15 ! (It’s taking me some time to get caught up, so this update covers the last 2 or so weeks.) As noted in my previous

Re: Intermittent oranges and when to disable the related test case - a simplified policy

On Tue, Sep 12, 2017 at 11:38 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: > I don't think so, that data already exists and is query-able from > ActiveData: > https://activedata.allizom.org/tools/query.html#query_id=8pDOpeni That query tells you about disabled tests, but doesn't

Re: Intermittent oranges and when to disable the related test case - a simplified policy

On Fri, Sep 8, 2017 at 7:10 PM Gregory Szorc wrote: > I know we've topic in this topic in the past but I can't recall outcomes. > Is it worthwhile to define and use a richer test manifest "schema" that > will facilitate querying and building dashboards so we have better >

Re: Coding style: Placement of binary operators when breaking a long line

Thanks everyone! This got a bit derailed but it's clear that a unified style for binary operators is desired. I received several emails off-list in support of my original proposal, a few people reiterated their preference for operators on the newline and we rehashed that conversation. Overall

Re: Coding style: Argument alignment

>On 8/31/17 6:50 PM, Ehsan Akhgari wrote: >> On 08/30/2017 09:03 PM, Eric Rahm wrote: >>> Okay sounds like there's agreement on a). >> >> Indeed.  I have edited the Style Guide to reflect this. > >Fwiw, I disagree with this decision. > >Here's a more realistic example of *actual use* from our code

Re: disabled non-e10s tests on trunk

>you could edit the taskcluster/ci/test/tests.yml file and add >|linux64/debug: both| in the places we have |windows7-32/debug: both|, as >seen here: >http://searchfox.org/mozilla-central/source/taskcluster/ci/test/tests.yml#138 > >If there are concerns with windows build times, please ask for

Re: Moving from xulrunner to firefox SDK

Manish 2017 September 6 at 05:32 Thanks Myk But I am bit confuse here. If we go by this way /path/to/firefox --app /path/to/application.ini. First there may be a possibility that Firefox is not installed and if it is installed and someone updates the

Re: Re-visiting the DOM tree depth limit in layout

Note also that, post-stylo, there are some very rough plans to investigate rewriting the frame constructor in parallel Rust, which would likely move us to a non-recursive model. But we probably won't start brainstorming the details until the all-hands, have no idea if it will work, and even if it

Re: 57 beta cycle: 57beta/devedition published earlier + soft freeze

In general, I would say your best bet is to have patches landed by mid-day PDT the day before if you want to be reasonably confident that it'll get merged over to Beta in time. Predicting when merges will happen is difficult due circumstances like build/test failures, infra issues, etc. It's

Re: Re-visiting the DOM tree depth limit in layout

On Mon, Sep 11, 2017 at 5:27 PM, wrote: > On Monday, September 11, 2017 at 1:41:43 PM UTC+2, Henri Sivonen wrote: > > Can we ask Windows to give us more stack space? > > -- > Don't know if it's possible to set it dynamically at runtime, but Visual > Studio supports setting

Re: Re-visiting the DOM tree depth limit in layout

On Monday, September 11, 2017 at 1:41:43 PM UTC+2, Henri Sivonen wrote: > Can we ask Windows to give us more stack space? > -- Don't know if it's possible to set it dynamically at runtime, but Visual Studio supports setting it at compile time (in linker options).

Re: Re-visiting the DOM tree depth limit in layout

On Mon, Sep 11, 2017 at 3:08 PM, Henri Sivonen wrote: >> 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

Re: Re-visiting the DOM tree depth limit in layout

On 9/11/17 10:08 AM, Henri Sivonen wrote: What kind of style would have the maximum stack frame size? Is display: table-cell enough to trigger the worst case? I suspect that display:table-cell is the worst case, but at only about 70% confidence. That said, I can't think of a worse case

Re: Re-visiting the DOM tree depth limit in layout

On Mon, Sep 11, 2017 at 3:49 PM, Boris Zbarsky 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

Re: 57 beta cycle: 57beta/devedition published earlier + soft freeze

Is there any guidance on when commits should make it to autoland and inbound for both Merge Days (14th and 21st)? I suppose people should just get things in 24 hours before midnight 00:00 Pacific Time to be "safe" in case there's any bustages (hopefully reduced with the soft freeze). For some

[Firefox Desktop] Issues found: September 4th to September 8st

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA Team last week, *September 4 - September 8* (week 36). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: disabled non-e10s tests on trunk

you could edit the taskcluster/ci/test/tests.yml file and add |linux64/debug: both| in the places we have |windows7-32/debug: both|, as seen here: http://searchfox.org/mozilla-central/source/taskcluster/ci/test/tests.yml#138 If there are concerns with windows build times, please ask for those to

Re: Re-visiting the DOM tree depth limit in layout

On 9/11/17 7:41 AM, Henri Sivonen wrote: Frame construction runs recursive algorithms along the depth of the DOM tree. It's not just frame construction. Recursive algorithms are all over the place in layout and DOM code. Frame construction may be a long pole here in terms of crashes due to

Re: Re-visiting the DOM tree depth limit in layout

On Mon, Sep 11, 2017 at 2:41 PM, Henri Sivonen wrote: > * Firefox opt build on x86_64 Linux crashes when the DOM depth is > between 3000 and 3100. > * Mac: between 3900 and 4000. 32-bit Linux: between 3900 and 4000 -- Henri Sivonen hsivo...@hsivonen.fi

Re-visiting the DOM tree depth limit in layout

Frame construction runs recursive algorithms along the depth of the DOM tree. The depth is currently capped at 200, because deeper trees caused stack overflow crashes on Windows in the Windows 95 era. There is a corresponding limit the HTML parser. The parser limit is there just to avoid showing