Re: Status of CSS break-* properties

[Karl Dubost]

Le 13 sept. 2017 à 21:24, Jonathan Kew  a écrit :
> There's a bug on file: https://bugzilla.mozilla.org/show_bug.cgi?id=775628. 
> But I'm not aware of any timeline for fixing this.

And https://bugzilla.mozilla.org/show_bug.cgi?id=1179406

-- 
Karl Dubost, mozilla  Webcompat
http://www.la-grange.net/karl/moz





___
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

[Mike Hommey]

On Wed, Sep 13, 2017 at 10:03:55AM -0700, Eric Rahm wrote:
> Jan is right, increasing the stack size for all threads would cause a very
> large memory regression. Lets not do that ;) Selectively increasing might
> make sense but we'd need to keep an eye on how large of an increase we're
> expecting.

We could also move the main thread loop to a thread that we create with
a stack size we want, and leave the original main thread just waiting
for it (joining it).

Mike
___
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

[Kim Moir]

Several releng folks, RyanVM and jcristau had a meeting today discussing
tomorrow's merge

We wanted to ensure that we would be able to have the correct branding for
Fennec beta after the merge.  In order to do this, we will have a relbranch
created for Fennec on Sept 14 named FIREFOX_56b13_RELBRANCH.  We'll use
this branch to build Fennec 56.0b13 on Sept 18. This process will look like
this:

Sept 13th:

   -

   GTB: Desktop and DevEdition 56.0b12

Sept 14:

   -

   Releng Migration
   -

  RyanVM: Create FIREFOX_56b13_RELBRANCH on m-b out of
  FIREFOX_BETA_56_END and manually bump version number to 56.0b13.
  -

 Approved patches for 56 will be landed on both mozilla-release
 (default branch) and mozilla-beta (FIREFOX_56b13_RELBRANCH).
 -

  Merge m-b->m-r normally. All tags will be made. Version numbers will
  be bumped. Branding will be release.
  -

  Merge m-c->m-b


   -

   No action on m-c.
   -

  Prior to m-c->m-b script run, comment out: https://dxr.mozilla.org/
  mozilla-central/source/testing/mozharness/scripts/
  merge_day/gecko_migration.py#329-336
  

  -

 Or undo those steps after the run


Between sept 14->21

   -

   GTB: DevEdition 57.0b1, sometimes this week, off mozilla-beta default
   -

   Uplifts: Regular merges will happen between still 57 m-c, to m-b.
   Preferably once a day.
   -

   Uplifts: Regular uplifts will happen to 56 m-r (and need to be
   backported to fennec 56 branch on m-b)


Sept 18th

   -

   GTB: Desktop 56.0rc1 off m-r default
   -

   GTB: Fennec 56.0b13 off m-b FIREFOX_56b13_RELBRANCH


The discussion is summarized in this document at the end under "Releng
actions"

https://docs.google.com/document/d/1SRjdBNjj4LM0IV4vs1UMrPnp
yhyNTYpJLZhLHg2TZI8

Kim

On Mon, Sep 11, 2017 at 12:28 PM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:

> 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/pushloght
>> ml?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 

PSA: nsPipe3.cpp is now using diagnostic assertions

[Ben Kelly]

Hi all,

FYI, I just pushed a patch to nsPipe3.cpp that switches it to use
MOZ_DIAGNOSTIC_ASSERT() instead of the weaker assertions it used to use.
This class is used extensively throughout the browser and state problems
can manifest as intermittent hangs, crashes, and memory leaks.

For example, we got lucky that we caught this intermittent in a debug build
in automation:

https://bugzilla.mozilla.org/show_bug.cgi?id=1397595

We currently have no idea how many release build sessions have run into
this state inconsistency in the wild.  The diagnostic assertions will help
us catch these problems much sooner.

We debated whether to wait until the FF58 merge next week or not.
Switching to diagnostic assertions now may raise crash rates in the short
term.  We decided, however, that the ability to detect problems sooner
before they hit the release channel outweighed the downsides of the
increased nightly/dev-edition crashes.

The diagnostic assertions were pushed in:

https://bugzilla.mozilla.org/show_bug.cgi?id=1398942

Please let me know if you have any questions or concerns.

Thanks.

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

Re: [Sheriffs] Intent to Implement: Remove Treeherder Exclusion Profiles in lieu of Tiers

[Ryan VanderMeulen]

How will this work with release branches like ESR52?

On Wed, Sep 13, 2017 at 1:25 PM, Cameron Dawson  wrote:

> Just an update that Bug 1387640 is progressing and soon the “Excluded
> Jobs” button in Treeherder will disappear.
>
> We have rolled out the changes to our staging environment (
> treeherder.allizom.org) and will let it soak for a day or so before
> pushing to production.
>
> Going forward, to view “hidden” jobs, you will need to check “tier 3” in
> the tiers menu.
> To hide a job, you would follow these instructions: https://
> treeherder.readthedocs.io/common_tasks.html#hide-jobs-with-tiers
>
> If you find a job that was previously hidden, but which no longer is, then
> please file a bug against Treeherder for BuildBot jobs and Taskcluster for
> TC jobs.
>
> Thanks for your time!
> -Cam
>
>
> On Sep 8, 2017, at 12:30 PM, Cameron Dawson  wrote:
>
> == Summary ==
>
> Remove the use of Exclusion Profiles to hide jobs and set Tier values.  We 
> will expect the correct tier value to be set in a test’s Task Definition 
> (default to 1).
>
> Anything hidden from BuildBot will be managed in the Treeherder code-base 
> directly.
>
>
> == Use cases / Motivation ==
> The mechanism that is currently used in Treeherder for hiding jobs is
> overly cumbersome and redundant with the Tier system.
>
> The main issues we are trying to solve for Treeherder users are:
>
>1. Make the mechanism for hiding jobs simpler (reduce from 2 paths to
>1)
>2. Put the tier and hiding capability in the hands of the test authors
>3. Make it easier for 3rd party tools to identify which tests are
>hidden
>
>
> The current system has several drawbacks:
>
>
>1. There are three different ways we track/apply tiers/visibility
>(in-tree, in Treeherder at time of ingestion, in Treeherder at time of
>retrieval)
>2. Confusing logic for setting Tiers in TaskCluster definitions.  This
>tier setting can be overridden (intentionally or unintentionally) by the
>treeherder visibility/tier profiles.
>3. We have 6 different states (3 tiers x hidden+not hidden)
>4. Considerable business logic in Treeherder that is cumbersome to
>understand and maintain.
>5. Unnecessary burden on Sheriffs:
>1. on merge day, they must manually change visibility for eg
>   mozilla-beta (since the in-tree logic will follow the code around)
>   2. when people stand up new tests - the sheriffs are asked to add a
>   job to the exclusion profile instead of the tier being in the in-tree 
> code.
>   6. Unnecessarily hard for tooling to analyze mozilla-central and
>determine what proportion of jobs are not even visible and could be
>switched off, or set to a lower priority.
>
>
> == Timeframe == I expect to complete this work by end of September 2017 ==
> Tracking progress == https://bugzilla.mozilla.org/show_bug.cgi?id=1387640
> == Additional Details (optional) == More detail can be found here:
>
> https://docs.google.com/document/d/1-BzCN97aCZKovWeh1zU6ASyp_FVtg0mbITN7C_iWXzg/edit#
>
>
> Please let me know if you have any comments or suggestions.
>
> Thanks!!
>
> -Cam
>
>
>
> ___
> Sheriffs mailing list
> sheri...@mozilla.org
> https://mail.mozilla.org/listinfo/sheriffs
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Implement: Remove Treeherder Exclusion Profiles in lieu of Tiers

[Cameron Dawson]

Just an update that Bug 1387640 is progressing and soon the “Excluded Jobs” 
button in Treeherder will disappear.

We have rolled out the changes to our staging environment 
(treeherder.allizom.org ) and will let it soak 
for a day or so before pushing to production.  

Going forward, to view “hidden” jobs, you will need to check “tier 3” in the 
tiers menu.
To hide a job, you would follow these instructions: 
https://treeherder.readthedocs.io/common_tasks.html#hide-jobs-with-tiers 


If you find a job that was previously hidden, but which no longer is, then 
please file a bug against Treeherder for BuildBot jobs and Taskcluster for TC 
jobs.

Thanks for your time!
-Cam


> On Sep 8, 2017, at 12:30 PM, Cameron Dawson  wrote:
> 
> == Summary ==
> Remove the use of Exclusion Profiles to hide jobs and set Tier values.  We 
> will expect the correct tier value to be set in a test’s Task Definition 
> (default to 1).  
> Anything hidden from BuildBot will be managed in the Treeherder code-base 
> directly.
> 
> == Use cases / Motivation ==
> 
> The mechanism that is currently used in Treeherder for hiding jobs is overly 
> cumbersome and redundant with the Tier system.  
> 
> The main issues we are trying to solve for Treeherder users are:
> Make the mechanism for hiding jobs simpler (reduce from 2 paths to 1)
> Put the tier and hiding capability in the hands of the test authors
> Make it easier for 3rd party tools to identify which tests are hidden
> 
> The current system has several drawbacks:
> 
> There are three different ways we track/apply tiers/visibility (in-tree, in 
> Treeherder at time of ingestion, in Treeherder at time of retrieval)
> Confusing logic for setting Tiers in TaskCluster definitions.  This tier 
> setting can be overridden (intentionally or unintentionally) by the 
> treeherder visibility/tier profiles.
> We have 6 different states (3 tiers x hidden+not hidden)
> Considerable business logic in Treeherder that is cumbersome to understand 
> and maintain.
> Unnecessary burden on Sheriffs:
> on merge day, they must manually change visibility for eg mozilla-beta (since 
> the in-tree logic will follow the code around)
> when people stand up new tests - the sheriffs are asked to add a job to the 
> exclusion profile instead of the tier being in the in-tree code.
> Unnecessarily hard for tooling to analyze mozilla-central and determine what 
> proportion of jobs are not even visible and could be switched off, or set to 
> a lower priority.
> 
> 
> == Timeframe ==
> 
> I expect to complete this work by end of September 2017
> 
> == Tracking progress ==
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1387640 
> 
> 
> == Additional Details (optional) ==
> More detail can be found here:
> https://docs.google.com/document/d/1-BzCN97aCZKovWeh1zU6ASyp_FVtg0mbITN7C_iWXzg/edit#
>  
> 
> 
> Please let me know if you have any comments or suggestions.
> Thanks!!
> -Cam

___
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

[Eric Rahm]

Jan is right, increasing the stack size for all threads would cause a very
large memory regression. Lets not do that ;) Selectively increasing might
make sense but we'd need to keep an eye on how large of an increase we're
expecting.

-e

On Wed, Sep 13, 2017 at 7:19 AM, Jan de Mooij  wrote:

> On Wed, Sep 13, 2017 at 10:44 AM, Henri Sivonen 
> wrote:
>
> > 3) Increase the run-time stack size on Windows such that 1026-deep
> > display: table-cell doesn't overflow the stack.
> >
>
> On Windows, threads that are created without an explicit stack size also
> use the executable's stack size. So increasing our stack size will also
> affect a bunch of other threads and we risk an increase in virtual memory
> OOMs on Win32. I filed bug 1257522 [0] two years ago to pass an explicit
> stack size for a number of background threads we create in Gecko, it would
> be nice to fix that first.
>
> Jan
>
> [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1257522
> ___
> 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: Intent to unship: Visibility of window.content to untrusted code

[Mike Taylor]

On 9/12/17 5:04 PM, Boris Zbarsky wrote:

> We could also delay the removal to after 57 to mitigate 57 risk 

Or remove it for non-RELEASE_OR_BETA builds for a release or two to see
what shakes out in Nightly/DevEdition reports.

-- 
Mike Taylor
Web Compat, Mozilla

___
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 Wed, Sep 13, 2017 at 10:44 AM, Henri Sivonen 
wrote:

> 3) Increase the run-time stack size on Windows such that 1026-deep
> display: table-cell doesn't overflow the stack.
>

On Windows, threads that are created without an explicit stack size also
use the executable's stack size. So increasing our stack size will also
affect a bunch of other threads and we risk an increase in virtual memory
OOMs on Win32. I filed bug 1257522 [0] two years ago to pass an explicit
stack size for a number of background threads we create in Gecko, it would
be nice to fix that first.

Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1257522
___
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 Sep 13, 2017 15:52, "Ben Kelly"  wrote:



On Wed, Sep 13, 2017 at 4:44 AM, Henri Sivonen  wrote:

> I suggest we do the following:
>
>  1) Change the HTML parser behave more like Blink's: Raise the limit
> to 513 elements deep and append elements violating the limit to the
> 512th element on the stack instead of dropping them. (Since the
> off-the-main-thread parser can't read from the DOM, the previous
> sentence is defined in terms of the stack and not in terms of looking
> up a parent as in Blink.) I already have the code for this.
>
>  2) Change the frame constructor limit to 1026. Rationale: This is
> notably larger than 513 by being 513 times two and just within what
> can be handled in the table-cell worst case on Mac and Linux with the
> existing run-time stack size limits.
>
>  3) Increase the run-time stack size on Windows such that 1026-deep
> display: table-cell doesn't overflow the stack.
>

Is it possible to have automated tests to verify these tunings remain valid
as the tree is changed over time?  Or maybe we already have those?


My plan is to write a reftest that will fail if 1) frame construction stops
too soon or 2) it crashes due to stack overflow. AFAICT, it has to be
skip-if debug, because the stack frames are substantially larger in debug
builds.
___
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

[Ben Kelly]

On Wed, Sep 13, 2017 at 4:44 AM, Henri Sivonen  wrote:

> I suggest we do the following:
>
>  1) Change the HTML parser behave more like Blink's: Raise the limit
> to 513 elements deep and append elements violating the limit to the
> 512th element on the stack instead of dropping them. (Since the
> off-the-main-thread parser can't read from the DOM, the previous
> sentence is defined in terms of the stack and not in terms of looking
> up a parent as in Blink.) I already have the code for this.
>
>  2) Change the frame constructor limit to 1026. Rationale: This is
> notably larger than 513 by being 513 times two and just within what
> can be handled in the table-cell worst case on Mac and Linux with the
> existing run-time stack size limits.
>
>  3) Increase the run-time stack size on Windows such that 1026-deep
> display: table-cell doesn't overflow the stack.
>

Is it possible to have automated tests to verify these tunings remain valid
as the tree is changed over time?  Or maybe we already have those?

Thanks.

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

Re: Status of CSS break-* properties

[Jonathan Kew]

On 13/09/2017 12:31, thomas.ja...@gmail.com wrote:

Hi there!

Apparently, most major browsers are currently supporting "break-column", e.g., or its 
"-webkit-column-"-prefixed variant (based on manual testing of 
https://www.quirksmode.org/css/columns/breaks.html in latest Chrome, Safari, Edge and IE 11). 
However, I couldn't find any information on its status in Firefox.


See https://developer.mozilla.org/en-US/docs/Web/CSS/break-after and 
related properties. (Answer: not currently supported.)


> Does anyone know whether there is an intent to implement?

There's a bug on file: 
https://bugzilla.mozilla.org/show_bug.cgi?id=775628. But I'm not aware 
of any timeline for fixing this.


(I think some use-cases can be handled using (or abusing) page-break-* 
properties, which may also affect column breaking, but that's a hacky 
workaround and I don't know if it is guaranteed to continue working once 
the CSS Fragmentation properties are actually implemented.)


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

Status of CSS break-* properties

[thomas . jaggi]

Hi there!

Apparently, most major browsers are currently supporting "break-column", e.g., 
or its "-webkit-column-"-prefixed variant (based on manual testing of 
https://www.quirksmode.org/css/columns/breaks.html in latest Chrome, Safari, 
Edge and IE 11). However, I couldn't find any information on its status in 
Firefox. Does anyone know whether there is an intent to implement?

Best regards,
Thomas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Making Windows 10 SDK version 10.0.10586 the minimum for building Firefox

[bowen]

Hi,

I'm just about to land a patch that makes Windows 10 SDK version 10.0.10586 the 
minimum required for building Firefox.

We require this to be able to compile certain features for the Chromium Windows 
process sandbox.

If you are using Visual Studio 2015 and you don't have this, it (or a later 
version) can be installed using the Visual Studio installer or from here:
https://developer.microsoft.com/en-us/windows/downloads/sdk-archive

Automation is already using version 10.0.14393.

I've updated:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites

Thanks,
Bob

___
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 Tue, Sep 12, 2017 at 12:46 PM, Henri Sivonen  wrote:
> On Tue, Sep 12, 2017 at 12:35 PM, Henri Sivonen  wrote:
>> I'm rather unhappy about the prospect of having to examine another
>> browser's HTML parser beyond reading the spec in order to achieve
>> interop. :-(
>
> Fortunately, not too complicated:
> https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/parser/HTMLConstructionSite.cpp?sq=306

I did some additional testing with
https://hsivonen.com/test/moz/deeptree/dom/ . The content process of
64-bit Chrome 61 on Windows 10 crashes when the depth is a bit over
2530. This happens at the same depth with display: block and display:
table-cell. Curiously, despite its lower crash threshold for
parser-generated trees, Edge can do over 4000 but slows to a crawl. (I
didn't have the patience to watch what the exact crash number was, but
unattended it did crash eventually.)

So even though the HTML parser-enforced depth in Chrome is 513
elements, Chrome's call stack can tolerate much deeper trees even on
Windows. This suggests that our frame constructor limit should be
larger than 513. In particular, this would help when the parser hits
the 513 limit in innerHTML.

I suggest we do the following:

 1) Change the HTML parser behave more like Blink's: Raise the limit
to 513 elements deep and append elements violating the limit to the
512th element on the stack instead of dropping them. (Since the
off-the-main-thread parser can't read from the DOM, the previous
sentence is defined in terms of the stack and not in terms of looking
up a parent as in Blink.) I already have the code for this.

 2) Change the frame constructor limit to 1026. Rationale: This is
notably larger than 513 by being 513 times two and just within what
can be handled in the table-cell worst case on Mac and Linux with the
existing run-time stack size limits.

 3) Increase the run-time stack size on Windows such that 1026-deep
display: table-cell doesn't overflow the stack.

Thoughts?

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