Photon Engineering Newsletter #15

[Justin Dolske]

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

update, Mike and Jared took over Newsletter duties while I was out. If you
somehow missed their excellent updates – Newsletter #13

and Newsletter #14
 –
please check them out. (Go ahead, I’ll wait.)

We’re getting very close to Firefox 57 entering Beta! Code merges to the
Beta on September 20th, and the first Beta release should come on the 26th.
The Photon project is targeting the 15th to be ready for Beta, just to make
sure there’s a bit of time to spare. We’ll be continuing to fix bugs and
improve polish during the Beta, but the type of fixes we make will begin to
scale back, as we focus on making sure 57 is a rock-solid release. This
means becoming increasingly risk-adverse – there will always be bugs (and
more releases to fix them in), so we very much want to avoid causing new
regressions shortly before 57 ships to everybody. Last-minute firedrills
are no fun for anyone. But we’re in really great shape right now – we’re
done with feature development, are already shifting to more minor fixes,
and there isn’t anything really scary waiting to be fixed.
Recent Changes

Menus/structure:

   - The order of the icons
    in the URL bar
   was updated.
   - When navigating Photon-style panels with the keyboard, the previously
   selected item 
   will remain hilighted when going back.
   - Library  and page
   action 
   integration for screenshots finally made it to Nightly.
   
   - The URL bar dropmarker will now disappear when typing
   .
   - Fixed some more
 ordering
   issues  in the
   page actions in the url bar.
   - Fixed an issue with send to device where the popup would stay open
   after sending a tab
   .
   - Made the page action buttons announce themselves correctly to
   screenreaders .
   - The bookmarks menu and the sidebar header menu look more Photon-y
   .
   - The “Restore Previous Session” item is now a toplevel item in the
   hamburger panel .
   It (and its toplevel menubar cousin) also gets hidden (instead of disabled)
   if you’ve set Firefox to automatically restore your session.

Animation:

   - The “burst” across the tab
    when the page
   load is complete has landed.
   [image: tabload]
   - Added a “Copy URL” and “Send to Device” popup
    so that there’s
   clearer feedback when performing these actions.
   [image: copyinfo]
   - Various fixes to animations of the library button
   , tab loading
   indicator in RTL
, pocket
   icon corruption .
   - Fixed various follow-ups with the burst animation
   , tab loading
   indicator , and
   and copy link confirmation
   .
   - Fixed the animation of panels  when they are anchored at the bottom
   .

Preferences:

   - Once last P1 bug 
   to feature complete!
   - Team to move to help out Onboarding once all P1 and important P3s are
   fixed.

Visual redesign:

   - (A couple of slow weeks due to multiple people being sick and/or on
   PTO)
   - Minor update to sidebar styling on Linux
   .
   - The URL bar icon has been changed from an ⓘ to an  when on
   about:newtab , to
   better indicate that it can be used as a search field too.
   - Superstar contributor Tim Nguyen landed a patch to update notification
   icons 

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

[Robert O'Callahan]

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 know about *why* a
test was disabled. E.g. you can't distinguish tests disabled because
they're not expected to work on some (or all) platforms from tests that
were disabled for intermittent failures that should, in principle, be fixed.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Andrew Halberstadt]

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
> visibility into disabled tests?
>

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

We just need to build a dashboard around something like that query. I had
previously written a pure JS tool that did this [1], but it was clunky and
poorly written. But someone with some actual frontend experience could
probably whip something up pretty fast.

Another thing we can (and should) do is write a mach command to trigger the
build system manifest parsing and return the results. This could possibly
be a mode on |mach test|.

[1] https://github.com/ahal/test-informant
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Eric Rahm]

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 given the back and forth it seems like
we're leaning towards going with unifying the style for splitting binary
operators by leaving them on the original line.

At this point I'll leave it to Ehsan, the code-style module owner, to make
the final decision.

-e

On Wed, Sep 6, 2017 at 12:30 PM, Eric Rahm  wrote:

> Hi folks-
>
> *Note: Previously we've discussed the placement of logical operators &&
> and ||; a decision was made and I do not wish to re-litigate that here*.
>
> Currently we have a somewhat convoluted set of rules about where to place
> boolean operators when breaking long lines [1]. Essentially we say that
> logical operators such as `&&` stay at the end, but boolean opertators
> such as `>` move to the new line. It's possible I'm misreading that
> (others certainly have [2]).
>
> This is incompatible with tools like clang-format [3] which support either
> leaving the operator at the end of the line or moving it to the new line,
> but not a half and half approach. It is very unlikely we could convince
> them to upstream such a change given we are the only organization that has
> requested it.
>
> I would like to propose that we adjust our style guide to remove the
> distinction between logical operators and boolean operators for the purpose
> of line breaking and use a unified style.
>
> *Examples*
>
> Current rules:
>
> if ((aArgument == 100) &&
> (anotherReallyLongArgument
>  > 2000)) {
>
> Proposed change if we unify the rules, favoring the logical operator
> placement:
>
> if ((aArgument == 100) &&
> (anotherReallyLongArgument >
>  2000)) {
>
> I want to emphasize this is a *pragmatic* change, our style guide is out
> of the norm, and the ability of our developers being able to use tools like
> clang-format is a big win.
>
> Please let me know what you think.
>
> -e
>
> [1] https://developer.mozilla.org/en-US/docs/Mozilla/Developer_
> guide/Coding_Style#Operators
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1396515
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1338105#c16
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Randell Jesup]

>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 base:
>http://searchfox.org/mozilla-central/rev/d29c832536839b60a9ee5b512eeb934274b879b0/layout/forms/nsFormControlFrame.h#57-64
>
>This example shows that it's easier to read arguments at a glance
>when they are aligned, IMO.

I agree with Mats here - it's easier to read, specifically in the case
where you have a large number of args, especially of widely varying
type-lengths.  Obviously, one could disagree, but that's a good example.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: disabled non-e10s tests on trunk

[Randell Jesup]

>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 be
>faster- it will make it better for all of us :)

Where's my magic wand...? if it was easy to make them faster I presume
that would have been done long ago.

I frequently do (only) linux Trys unless I suspect platform-specific
issues.  Saves resources...  Can't "mochitest-media" (and other non-e10s
versions) be not-run by default, unless you specify it explicitly in -u ?

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving from xulrunner to firefox SDK

[Myk Melez]

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 firefox to latest version and 
the max ver. defined under application.ini is the older one, then the 
application won't start and will through the version mismatch alert.
Yes, these are all drawbacks to reusing an existing installation of 
Firefox. In order to do so successfully, you would need to ensure that 
your users install (and retain) Firefox and keep your application 
up-to-date with new versions of the browser.


Isn't there any method or terms defined where I can ship the firefox 
directory in the application folder rather than re-brading it or 
should we by default set the max version in application.ini to a 
higher value i.e 99 or if you can suggest any other way.
If you set the maxVersion value in application.ini to an unreleased 
version of Firefox, such as 99, then you face the risk that your 
application will break with a new version of Firefox that isn't 
backward-compatible. A better option would be to test your application 
with each new version of Firefox and then update its maxVersion value 
accordingly.


However, the best option is perhaps to ship your application with its 
own copy of Firefox, as you've suggested. Technically, it's possible to 
do so. That's the idea behind the qbrt experiment 
 that I previously mentioned. I'm 
unfamiliar with the legal requirements for doing so, however.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Bobby Holley]

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
does, it would be many months until we implemented and shipped it.

On Mon, Sep 11, 2017 at 5:49 AM, Boris Zbarsky  wrote:

> 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 a
> combination of several things:
>
> 1) Largish stack frames (not least because it stores a bunch of state in
> RAII things).
>
> 2) Frame construction itself having a depth check in ProcessChildren that
> prevents the frame tree from getting too deep (though it really only limits
> the depth the frame constructor itself is willing to go to).
>
> 3) Layout having a separate IsFrameTreeTooDeep check that makes it stop
> reflowing descendants at some point.
>
>
> There are three areas where changes could be made:
>>   1) We could re-calibrate the depth limit.
>>   2) The HTML parser could try harder to make the DOM rewrites keep
>> text nodes visible.
>>   3) The frame constructor could switch from a full-features recursive
>> algorithm to an iterative text node-only traversal near the depth
>> limit.
>>
>
> Option #3 won't really help with the third check I list above.  Maybe
> we'll construct frames for all the content, but we still won't lay it out,
> hence it won't be visible.
>
> 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.  It might be more tractable than it used
> to be because maybe we can pretend like things are display:contents or
> something, but that means still doing stuff for all the ancestors of the
> textnodes, and in a non-recursive way.  It might be doable, though.
>
> 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:
>
>   
>   
>
> To need less stack than something like this:
>
>   
>   div { display: table-cell }
>   
>
>   * 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.
>
> As for other browsers:
>> I didn't find a depth limit for Chrome. (Tried up to 16000.)
>>
>
> Which version of Chrome?  Per comments in https://bugzilla.mozilla.org/s
> how_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.
>
> OK if I change the limit on a per-OS basis according to these numbers?
>>
>
> I'd really like to see testcases with: 1) Lots of nested inlines instead
> of lots of nested blocks and 2) my display:table-cell stress test to see
> what the numbers look like then.
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ryan VanderMeulen]

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 possible that there will be a final set of autoland/inbound merges to
m-c on those days ahead of the merge to Beta, but I wouldn't assume they'll
happen either.

-Ryan

On Sat, Sep 9, 2017 at 6:39 PM, Ed Lee  wrote:

> 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 context from 56 Merge Day (August 2nd), the last autoland commit
> that made it to Beta 56 was from August 1st 06:49 Pacific, and the last
> inbound commit was from 14:12. mozilla-central was tagged at August 2nd
> 00:35. In this case, autoland had an ~18 hour earlier cutoff and inbound
> had a ~10 hour earlier cutoff to "make it" without needing
> approval-beta-56. There were 176 bugs that landed on autoland [1] or
> inbound [2] while it was still "August 2nd Pacific", and 44 (25%) of those
> were uplifted. (I suppose not auto-uplifting the other 75% might be worth
> the overhead of additionally requesting+approving 10% of the 445 bugs
> uplifted to 56.)
>
> Ed Lee
>
> [1] https://hg.mozilla.org/integration/autoland/
> pushloghtml?startdate=2017-08-01+13%3A50=2017-08-03+07
> [2] https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?startdate=2017-08-01+21%3A13=2017-08-03+07
>
> On Thu, Sep 7, 2017 at 6:07 AM, Sylvestre Ledru  wrote:
>
>> Hello,
>>
>> tldr: we are going to do a first merge of m-c => m-b and use the
>> devedition population one week earlier to push 57.0b1 & 57.0b2.
>>
>> In order to maximize beta testing, we are going to take advantage of the
>> fact that we have a different set of users with the developer edition
>> (which is, since the completion of the dawn project, based on
>> mozilla-beta).
>> September 14th, we will merge mozilla-central => mozilla-beta and
>> mozilla-beta => mozilla-release. September 19th, we will push to the
>> devedition population the first beta of 57. Later, we will be pushing a
>> second beta to this channel.
>> In parallel, to minimize the impact on the developer, mozilla-central
>> will remain 57.0a1 and will be merged to mozilla-beta transparently.
>> Nightly will become 58.0a1 on September 21th.
>> The regular beta population will remain on 56 and will be provided
>> updates to the RC builds.
>>
>> The milestones are detailed in this Google doc:
>> https://docs.google.com/document/d/1jeypuqBqEyIh-4qxXT0UnE2a
>> VjetN7uVD8W7L7TbWKg/edit
>>
>> In parallel, as the soft freeze demonstrated its value during previous
>> cycles, we are going to use this again during the 57 nightly cycle. From
>> September 18th, we will ask you to land only bug fixes, stability or
>> important performance fixes. New development not planned for 57 should
>> land once mozilla-central will become 58 (September 21th).
>>
>> Thanks,
>> Sylvestre
>>
>>
>
>
> --
> Ed Lee
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jan de Mooij]

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 it at compile time (in linker options).
>

Yes, we already set the stack size to 2 MB on Win64 [0]. In case it helps,
in bug 1257234 I added some code to detect the main thread stack size on
Windows (for JS recursion limits).

Jan

[0]
http://searchfox.org/mozilla-central/rev/00fa5dacedb925022f53d025121f1a919508e7ce/config/config.mk#422



> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[khagaroth]

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).

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Geoffrey Sneddon]

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 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.

I wrote a test for this years ago; I've thrown it up at
.

Chrome limits the DOM at 513 deep (where the root element is one
deep), Safari likewise but doesn't paint anything. Edge appears to
have no limit, so that TC simply hangs in an infinite loop (presumably
it will eventually go OOM and crash, though I wonder if its
performance isn't linear?).

/g
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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 offhand.


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.


That's possible, yes.


64-bit Ubuntu-shipped Chromium 60 and 64-bit Google-shipped Chrome 60
on Windows 10.


OK. I think the XML parser stack depth limit is back in 61...


I guess I should add some JS that computes the DOM depth.


That would certainly be useful data, if you are willing to do it.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Henri Sivonen]

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 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:
>
>   
>   

It was s without any custom styling:
https://hsivonen.com/test/moz/deeptree/

> To need less stack than something like this:
>
>   
>   div { display: table-cell }
>   

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=43cfdbbb164b0638d21fca054d5facc894633deb=130001915
https://treeherder.mozilla.org/#/jobs?repo=try=40d92f2beae262ce502d9c57a0e5666157c584f9=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

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

[Ed Lee]

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 context from 56 Merge Day (August 2nd), the last autoland commit
that made it to Beta 56 was from August 1st 06:49 Pacific, and the last
inbound commit was from 14:12. mozilla-central was tagged at August 2nd
00:35. In this case, autoland had an ~18 hour earlier cutoff and inbound
had a ~10 hour earlier cutoff to "make it" without needing
approval-beta-56. There were 176 bugs that landed on autoland [1] or
inbound [2] while it was still "August 2nd Pacific", and 44 (25%) of those
were uplifted. (I suppose not auto-uplifting the other 75% might be worth
the overhead of additionally requesting+approving 10% of the 445 bugs
uplifted to 56.)

Ed Lee

[1]
https://hg.mozilla.org/integration/autoland/pushloghtml?startdate=2017-08-01+13%3A50=2017-08-03+07
[2]
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?startdate=2017-08-01+21%3A13=2017-08-03+07

On Thu, Sep 7, 2017 at 6:07 AM, Sylvestre Ledru  wrote:

> Hello,
>
> tldr: we are going to do a first merge of m-c => m-b and use the
> devedition population one week earlier to push 57.0b1 & 57.0b2.
>
> In order to maximize beta testing, we are going to take advantage of the
> fact that we have a different set of users with the developer edition
> (which is, since the completion of the dawn project, based on
> mozilla-beta).
> September 14th, we will merge mozilla-central => mozilla-beta and
> mozilla-beta => mozilla-release. September 19th, we will push to the
> devedition population the first beta of 57. Later, we will be pushing a
> second beta to this channel.
> In parallel, to minimize the impact on the developer, mozilla-central
> will remain 57.0a1 and will be merged to mozilla-beta transparently.
> Nightly will become 58.0a1 on September 21th.
> The regular beta population will remain on 56 and will be provided
> updates to the RC builds.
>
> The milestones are detailed in this Google doc:
> https://docs.google.com/document/d/1jeypuqBqEyIh-
> 4qxXT0UnE2aVjetN7uVD8W7L7TbWKg/edit
>
> In parallel, as the soft freeze demonstrated its value during previous
> cycles, we are going to use this again during the 57 nightly cycle. From
> September 18th, we will ask you to land only bug fixes, stability or
> important performance fixes. New development not planned for 57 should
> land once mozilla-central will become 58 (September 21th).
>
> Thanks,
> Sylvestre
>
>


-- 
Ed Lee
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Cornel Ionce]

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:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL
*
ID  Summary Product Component   Is a regression 
Assigned to
1396523 
	Source file doesn't gain focus after being selected from the list view 
dropdown

Firefox
Developer Tools: Debugger
NO  NOBODY
1396583 
Wrong Tooltip position after searching for "firefox"/"nightly"
Firefox Preferences
NO  Ricky Chien 
1396585 
Glitch on Default Search Engine drop-down each time you search an engine
Firefox Preferences
NO  NOBODY
1396592 
Selected area restricted due to search tooltip
Firefox Preferences
NO  NOBODY
1396593 
Unusual design for Tooltip when using High Contrast theme
Firefox Preferences
NO  NOBODY
1396841 
	Some breakpoints remain disabled after choosing the "Enable 
Breakpoints" option from the breakpoints pane

Firefox Developer Tools: Debugger   NO  NOBODY
1397179 
	Area information is not displayed for boxes that don't have the space 
to show it above it or on left/right extremities

Firefox Developer Tools: Inspector
NO  NOBODY
1397185 
	Area information is displayed way higher than the box is placed when 
tilting the grid at different angles

Firefox Developer Tools: Inspector  NO  NOBODY
1397669 
NVDA is able to read the password while typing it
Core
Disability Access APIs
YES NOBODY
1397678 
Horizontal scrollbar is not displayed at all times in the Scopes panel
Firefox Developer Tools: Debugger   NO  NOBODY
1397697 
Methods tooltip panel is dismissed while scrolling inside of it
Firefox Developer Tools: Debugger   NO  NOBODY
1397723 
Some strings show up as a tooltip even though the string was not found
Firefox Preferences NO  NOBODY
1397729 
Strings inside cookies dialog are not found when searched
Firefox Preferences NO  Ricky Chien 

1397731 
	Highlight is not removed from dialogs after searching for something and 
picking a category from Preferences

Firefox Preferences NO  Ricky Chien 

1397737 
	Entering very long strings in the search field will result in cutting 
the top of the tooltip

Firefox Preferences NO  NOBODY
1398064 
	Toolbar buttons are not visible while using High Contrast #1 and High 
Contrast Black themes

Firefox Developer Tools: Debugger   NO  NOBODY


*NIGHTLY CHANNEL**
*
ID  Summary Product Component   Is a regression 
Assigned to
1396615 
[e10s] Slices in the Chart pie are being cut off
Firefox
Developer Tools: Netmonitor
	YES 
 
	NOBODY

1396747 
	The request's method cannot be deleted in the panel, but it appears 
deleted in the request lists
	Firefox 	Developer Tools: Netmonitor 	YES 
 
	NOBODY

1396807 
	Dialog boxes are not scaled if Firefox is dragged from a low dpi 
display to another one with a high dpi

Core
Widget: Win32
YES NOBODY
1396816 
  

Re: disabled non-e10s tests on trunk

[Joel Maher]

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 be
faster- it will make it better for all of us :)



On Fri, Sep 8, 2017 at 5:40 PM, Ben Kelly  wrote:

> Joel,
>
> Is there an easy way for me to run non-e10s tests on linux?  We often use
> "t-style" try pushes where we only run tests on one platform.  Restricting
> non-e10s to win7-debug means I either need to run tests on multiple
> platforms or use windows for the "t-style".  I don't want to use windows
> because it builds/runs much slower than linux.
>
> Thanks.
>
> Ben
>
> On Fri, Aug 18, 2017 at 4:15 PM,  wrote:
>
>> Yesterday I landed bug 1391371 which enabled non-e10s unittests on
>> windows 7 debug.  A few tests had to be disabled in order to do this.  To
>> keep track of what we did and each of the test suites to evaluate, I have
>> filed bug 1391350.
>>
>> As a note we now have the following non-e10s tests running:
>> windows7-debug: all trunk branches
>> android opt/debug: all trunk branches (existing media, plain, reftest)
>> linux64-jsdcov: mozilla-central (mochitest-plain/browser-chrome/devtools)
>> ** this is a linux64 opt build and we use the jsdebugger to collect code
>> coverage metrics- but we specifically run this in non-e10s mode.
>>
>> Please let me know if there are large areas that we have overlooked.
>>
>> Thanks!
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Boris Zbarsky]

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 a 
combination of several things:


1) Largish stack frames (not least because it stores a bunch of state in 
RAII things).


2) Frame construction itself having a depth check in ProcessChildren 
that prevents the frame tree from getting too deep (though it really 
only limits the depth the frame constructor itself is willing to go to).


3) Layout having a separate IsFrameTreeTooDeep check that makes it stop 
reflowing descendants at some point.




There are three areas where changes could be made:
  1) We could re-calibrate the depth limit.
  2) The HTML parser could try harder to make the DOM rewrites keep
text nodes visible.
  3) The frame constructor could switch from a full-features recursive
algorithm to an iterative text node-only traversal near the depth
limit.


Option #3 won't really help with the third check I list above.  Maybe 
we'll construct frames for all the content, but we still won't lay it 
out, hence it won't be visible.



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.  It might be more tractable 
than it used to be because maybe we can pretend like things are 
display:contents or something, but that means still doing stuff for all 
the ancestors of the textnodes, and in a non-recursive way.  It might be 
doable, though.



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:


  
  

To need less stack than something like this:

  
  div { display: table-cell }
  


  * 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.



As for other browsers:
I didn't find a depth limit for Chrome. (Tried up to 16000.)


Which version of Chrome?  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.



OK if I change the limit on a per-OS basis according to these numbers?


I'd really like to see testcases with: 1) Lots of nested inlines instead 
of lots of nested blocks and 2) my display:table-cell stress test to see 
what the numbers look like then.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Henri Sivonen]

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
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re-visiting the DOM tree depth limit in layout

[Henri Sivonen]

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 frame construction to deep trees; there is no
reason for the limit arising from the parser itself. The parser tries
to preserve text nodes even after the limit has been reached. This
works in simple cases, but apparently doesn't work in more complex
cases.

For many years, my standard response to people who complained was to
point the finger at layout and mark bug reports as duplicates of
https://bugzilla.mozilla.org/show_bug.cgi?id=256180 . This seems
acceptable, because the failures where on sites deep in the long tail.

Recently, it has come to my attention
(https://bugzilla.mozilla.org/show_bug.cgi?id=1188731) that the depth
limit is a problem in a more serious case. Apparently there are email
clients that generate unreasonably nested HTML as a side effect of
rich text editing and there are notable webmail clients (at least
Yahoo! apparently, but I have a vague recollection that I saw a
complaint about Hotmail, too, when browsing duplicates) that don't
restructure such HTML email, so the deep trees are exposed to Firefox.
When the HTML parser fails to keep text nodes visible when trying to
rewrite the tree before it reaches layout,  the result is parts of
emails going missing from layout, which may lead to notable badness
due to users misinterpreting what the email say, which may lead to
users switching browsers after realizing that there are other browsers
that don't hide these parts of emails.

There are three areas where changes could be made:
 1) We could re-calibrate the depth limit.
 2) The HTML parser could try harder to make the DOM rewrites keep
text nodes visible.
 3) The frame constructor could switch from a full-features recursive
algorithm to an iterative text node-only traversal near the depth
limit.

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?

In the meantime, considering that this is a problem that can result in
users switching browsers, I think we should change the depth limit and
make it different depending on operating system so that Mac and Linux
users don't need to switch browsers due to Windows limitations. (Or
users of 64-bit Windows due to 32-bit Windows limitations.)

My findings from testing with a very high limit so far are as follows:
 * Firefox opt build on x86_64 Linux crashes when the DOM depth is
between 3000 and 3100.
 * Mac: between 3900 and 4000.
 * 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.

As for other browsers:
I didn't find a depth limit for Chrome. (Tried up to 16000.)
On 64-bit Windows 10, Edge's content process crashes when the depth is
between 800 and 1000.
On 64-bit Windows 10, IE11's content process crashes when the depth is
between 1000 and 1100.

OK if I change the limit on a per-OS basis according to these numbers?

Can we ask Windows to give us more stack space?

(I'd appreciate testing help on 32-bit Windows. Build with the limit
set to so large that the stack overflows first:
https://queue.taskcluster.net/v1/task/TUMHVvq1QpG0qmsfREuDZw/runs/0/artifacts/public/build/target.zip
; test cases: https://hsivonen.com/test/moz/deeptree/ )

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform