NS_MIN/NS_MAX replaced by std::min/std::max

Our NS_MIN/NS_MAX C++ templates have been removed and we're now using std::min/std::max instead. There's one exception: files under xpcom/ still use the old templates (now renamed as XPCOM_MIN/MAX) because #include algorithm is not allowed in some build configurations of xpcom. See bug

Re: Keywords for flagging unreduced regression windows

On 11/26/2013 08:10 PM, Josh Matthews wrote: * regressionwindow-wanted, testcase-wanted: regression from earlier versions is present, and some help crafting a testcase/clear steps to consistently reproduce is desired I think we should keep testcase and steps to reproduce as separate notions.

Intent to ship: the 'box-decoration-break' CSS property

As of 2014-07-08 support for the CSS property 'box-decoration-break' has been turn on by default in Nightly (sorry for being late in announcing that). It's been developed behind the preference layout.css.box-decoration-break.enabled. The plan is to enable it by default also on Aurora (32) to

Re: Intent to ship: the 'box-decoration-break' CSS property

On 11/09/2014 06:28 PM, sime.vi...@gmail.com wrote: On Friday, July 11, 2014 7:38:39 PM UTC+2, Mats Palmgren wrote: IE10 has -ms-box-decoration-break I've tested[1] this property in IE11 with the values slice and clone. IE does not seem to support it. (I've also checked in older versions

Re: Intent to ship: CSS display:contents

On 02/04/2015 08:20 PM, cmzieba...@gmail.com wrote: I am trying to set up a CodePen to test this feature: http://codepen.io/WebDevCA/pen/vEeMjx If I understand display:contents properly then if it is working the green border around the DIV can't be seen but the contents of the H1 inside that

Re: Intent to ship: CSS display:contents

On 02/02/2015 07:27 PM, paul.ir...@gmail.com wrote: Hey Mats, the use cases are not obvious to me, but I didn't follow the original www-style threads on this so I'm lacking context. (A the spec doesn't help either) Can you help explain why a developer would use `display:contents`? I think it'd

Intent to implement: CSS Grid Layout Module Level 1

Summary: CSS Grid defines a two-dimensional grid-based layout system, optimized for user interface design. In the grid layout model, the children of a grid container can be positioned into arbitrary slots in a flexible or fixed predefined layout grid. Bug:

Intent to ship: CSS display:contents

CSS display:contents has been enabled by default in v37 and my intent is to ship this feature in v37 on all platforms. It can be disabled by setting the hidden preference layout.css.display-contents.enabled to false. Link to standard: CSS Display Module Level 3

Re: Intent to ship: CSS display:contents

On 02/02/2015 04:11 PM, Boris Zbarsky wrote: On 2/1/15 4:36 PM, Mats Palmgren wrote: CSS display:contents has been enabled by default in v37 and my intent is to ship this feature in v37 on all platforms. Do we have any indication on whether any other UAs are planning to ship this? I'm

Re: Intent to implement: CSS Grid Layout Module Level 1

On 02/03/2015 04:51 PM, Jonas Sicking wrote: Can we also expose this to certified apps so that our Gaia developers can start experimenting with using grids? There isn't any useful layout code in the tree yet. The ETA for anything that's worth experimenting with is still 3-4 weeks or so. I

Re: Using rr with test infrastructure

On 03/13/2015 12:26 PM, Ted Mielczarek wrote: The other question I have is: what percentage of our intermittent failures occur on Linux? If it's not that high then this is a lot of investment for minimal gain. FYI, there have been several intermittent crashes reported on Linux test runs

Re: Intent to ship: Directory picking and directory drag-and-drop

On 09/21/2015 05:37 PM, Jonathan Watt wrote: Targeting Firefox 44 we intend to ship[1] Directory Upload[2], It seems there are many security, privacy and UI issues discussed in bug 907707 that are still unresolved. I see that it's blocking the ship-it tracking bug, but it seems premature to

Re: Proposal: revisit and implement navigator.hardwareConcurrency

On 9/8/15 3:21 PM, Luke Wagner wrote: On a more technical detail: WebKit and Chromium have both shipped, returning the number of logical processors where WebKit additionally clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed by WHATWG text [7]. I would argue for not clamping

Re: Coding style for C++ enums

On 2016-04-08 23:03, Jeff Gilbert wrote: Strong preference against eFoo, here. :) Strong preference *for* eFoo, here. :) If I see Bar::Foo anywhere in code I'm not familiar with, my brain is likely to first parse that as a type before realizing that, hmm that doesn't make sense in an

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

On 2016-04-11 23:32, Emma Humphries wrote: Here's the open bugs they have touched http://mzl.la/1Q3w24o He touched 283 bugs in the last 48 hours, most of which are FIXED. Many comments are identical, for example: https://bugzilla.mozilla.org/show_bug.cgi?id=1240762

Re: Coding style for C++ enums

On 2016-04-11 19:47, Seth Fowler wrote: Let me suggest again (especially since I'm not sure my previous email reached this list yet) that rather than compromise on the "e" prefix, we compromise on all caps for values, which is just as readable without placing even more pressure on our

Re: Triage Plan for Firefox Components

On 04/01/2016 10:35, Marco Bonardo wrote: Fwiw, we (Awesome Search Team) also use Priority for the backlog, and we consider P1, P2 and P5 the same as Media Playback team. So there is some convergence about the meaning of those. Though we also use P3 for "we care about this and will fix it,

Re: MXR permanently offline, please transition to DXR

On 06/28/16 01:01, Tanvi Vyas wrote: Is it possible to safely redirect mxr to dxr? This would be most welcome. There are lots of pasted MXR links in Bugzilla comments which now requires tedious editing to follow. /Mats ___ dev-platform mailing

Re: Changing the representation of rectangles in platform code

On 02/09/2017 01:56 AM, Botond Ballo wrote: - Replace direct accesses to the 'width' and 'height' fields throughout the codebase with calls to getter and setter methods. (There aren't that many - on the order of a few dozen, last I checked.) I think you must have made a mistake, width/height

Re: Changing the representation of rectangles in platform code

On 02/09/2017 03:26 AM, Botond Ballo wrote: As far as I can tell, ISize and BSize are methods on mozilla::LogicalRect, which does not derive from BaseRect, and as such would not be affected. Here's LogicalRect::ISize():

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/16/2017 07:20 PM, Benjamin Smedberg wrote: It has happened repeatedly over the past two years that we discovered critical issues that affect websites only after we ship to release. I don't think removing -moz-appearance even has the potential of being "critical". All that happens is

Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

Summary: add support for the CSS UI property 'appearance:none | auto' with '-webkit-appearance' as an alias. Unship '-moz-appearance'. 'appearance:none' works exactly as '-moz-appearance:none' -- it turns off the native theme for elements that have one. 'appearance:auto' (the initial value)

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/11/2017 12:28 AM, Justin Dolske wrote: Do we have any data on existing content usage of -moz-appearance? Or is this a "ship it and see what breaks" kind of thing? I'm not aware of any data that would be useful here. Data on how often -moz-appearance is used isn't very useful since it

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/11/2017 04:59 AM, Boris Zbarsky wrote: The biggest worry for me is that inline style is never a "chrome sheet" in this sense. That's a valid concern, but I think ignoring -moz-appearance has fairly benign effects in most cases. And as Jet pointed out to me, just landing it and see what

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/16/2017 04:27 PM, Boris Zbarsky wrote: On 2/16/17 10:23 AM, Mats Palmgren wrote: That's a valid concern, but I think ignoring -moz-appearance has fairly benign effects in most cases. Well, as in things just look wrong, is all, right? Right. But as I said, at least in some cases

Re: Upcoming hg.mozilla.org certificate change

On 09/26/2016 07:20 PM, Gregory Szorc wrote: # Mercurial 3.9+ [hostsecurity] hg.mozilla.org:fingerprints = sha256:8e:ad:f7:6a:eb:44:06:15:ed:f3:e4:69:a6:64:60:37:2d:ff:98:88:37:bf:d7:b8:40:84:01:48:9c:26:ce:d9 # Mercurial <= 3.8 [hostfingerprints]hg.mozilla.org =

Intent to ship: CSS Grid

As of Gecko 52, I intend to let CSS Grid ride the trains on all platforms. https://drafts.csswg.org/css-grid/ This also includes all parts of the CSS Box Alignment spec that are relevant to Grid layout: https://drafts.csswg.org/css-align-3/ It has been developed behind the

Re: Intent to ship: CSS Grid

On 12/05/2016 09:53 PM, Benjamin Smedberg wrote: Have the various grid properties be added to our fuzzers and we've been fuzzing the implementation fairly comprehensively? Yes, I believe Grid is included in our normal fuzz testing. Grid has been enabled by default in Nightly and Aurora

Re: Intent to ship: CSS Grid

On 12/05/2016 08:00 PM, Boris Zbarsky wrote: What performance testing have we done on this implementation? Have we done edge-case stress-testing? Stress-testing with large but "real-life" layouts? Something else? Nope, I've done no /dedicated/ performance testing so far. Both I and dholbert

Re: Intent to implement and ship: CSS display:flow-root

FYI, Chrome is following our lead and now intend to ship too: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/k9WOAVA5Ewc /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Who loves multiple selection feature in editor?

On 12/20/2016 03:25 AM, Masayuki Nakano wrote: I'm talking about only nsISelectionController::SELECTION_NORMAL. Other selections need multiple selection. I suspect that treating SELECTION_NORMAL differently from other kinds of Selections will actually make the code more complicated, not less.

Intent to implement and ship: CSS display:flow-root

Summary: A display:flow-root element generates a block container box, and lays out its contents using flow layout. It always establishes a new block formatting context for its contents (per CSS2). This is intended to make "clearfix" hacks unnecessary. The implementation is fairly trivial: it

Re: Who loves multiple selection feature in editor?

On 12/15/2016 10:46 AM, Masayuki Nakano wrote: > Supporting multiple selection in editor makes our editor code > complicated. Why is that so exactly? By necessity, the code already operates on one Range, right? so why can't we implement something like: Selection.ApplyToAllRanges(aFunction)

Re: Who loves multiple selection feature in editor?

On 12/16/2016 06:32 PM, Ehsan Akhgari wrote: * The developer facing APIs. As you have noted above, our selection API allows you to construct and examine multi-range selections. This is something that we should fix at some point, since other browser vendors have been very clear that they won't

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/17/2017 03:22 AM, Boris Zbarsky wrote: I thought about this a fair bit the last few days, and I think it would be a mistake to tie shipping appearance/-webkit-appearance to the removal of -moz-appearance. We should ship the no-prefix version and the -webkit version. Then we should get

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

On 9/7/17 4:45 PM, Ehsan Akhgari wrote: $ git grep '\s(>|>=|<|<=|==|!=)\s*$' -- '*.c*' | wc -l 2794 Don't you get plenty of false positives for '>' with that regexp though? For example: dom/bindings/BindingUtils.h:template js/public/HashTable.h:struct IsPod > etc /Mats

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

Re: Coding style: Argument alignment

On 9/19/17 5:09 PM, Ehsan Akhgari wrote: Do you find the arguments that people have against this convincing? No. If not, would you mind elaborating why please? Sure, to recap, the arguments against aligned params in this thread are: 1. more work Not an issue if we use a tool to do the

Re: Intent to ship: CSS Shapes Module Level 1 (partial)

On 11/29/17 12:03 PM, Ting-Yu Lin wrote: We can ship all the properties in this module at once, or we could probably divide it into two stages, and ship it to the user incrementally. For example, stage 1 is to ship shape-outside" (except value) and "shape-margin", and stage 2 is to ship the

PSA: Microsoft VMs for testing

FYI, Microsoft distributes free VMs for browser testing purposes: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

On 8/14/18 12:52 AM, Jonathan Watt wrote: On 08/08/2018 21:08, Boris Zbarsky wrote: Are we writing down something that could get turned into a spec? I've got a bunch of messy notes that I hope will be of some use for that, but no, so far I have not attempted to create draft spec text to

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

The plan to ship -webkit-appearance looks good to me, fwiw. On 8/14/18 12:46 AM, Jonathan Watt wrote: > On 08/08/2018 16:31, Mike Taylor wrote: >> On 8/7/18 5:16 PM, Jonathan Watt wrote: >>> Spec: None. We're reverse engineering Chrome and ignoring >>>

Intent to implement: CSS subgrid

Hello Grid lovers, I've started implementing a prototype for CSS subgrid layout. I say "prototype" since the spec [1] is far from settled and will need to be updated based on feedback from implementors. I've summarized the features of this prototype and my views on the spec at [2]. (I'll use

Re: Intent to unship: URL.createObjectURL(MediaStream)

On 4/23/18 10:01 AM, Anne van Kesteren wrote: On Mon, Apr 23, 2018 at 9:50 AM, Andrea Marchesini wrote: . I haven't checked edge (I don't run windows locally) Ask for a BrowserStack account (not entirely sure who arranges these though, I got mine via jst). Or you

Intent to unprefix grid-gap, grid-row-gap, and grid-column-gap and updating them to spec

Hi, In bug 1398482 I'm unprefixing the grid-gap, grid-row-gap, and grid-column-gap properties. The old names becomes aliases for the respective unprefixed property. I'm also adding support for the 'normal' keyword to these properties and making it the initial value, per spec [1]. I'm also

Re: Intent to implement: Reporting API

On 11/13/18 10:33 AM, Andrea Marchesini wrote: *Summary*: Reporting API allows the page to receive notifications such as the usage of deprecated APIs and FeaturePolicy violations. I decided to implement this API, because it is required in the web-platform-tests for FeaturePolicy. Reporting API

Intent to unship: most -moz-appearance values not supported by other UAs / spec

Hi, In bug 1496720 I intend to unship most -moz-appearance values that aren't supported by other UAs / spec. These are mostly XUL-related values that we use internally in our UI (and they will continue to be available for that purpose). Also, since -webkit-appearance is now an alias for

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

On 9/20/18 5:59 PM, Andrew McCreight wrote: On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione wrote: On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote: So, I don't think we need to do anything fancy with forking - we'd just need to capture stacks and send them via telemetry rather

Intent to Implement and Ship: CSS inset/inset-block/inset-inline shorthands

Summary: The inset-block CSS property is a shorthand for the inset-block-start/end properties (ditto -inline). The 'inset' CSS property is a shorthand for the top, right, bottom, and left properties. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1520229 Link to standard:

Intent to Implement and Ship: CSS border-{block,inline}-{color,style,width} and border-{block,inline} shorthands

Summary: The border-{block,inline}-{color,style,width} CSS properties are shorthand for their respective -start/-end properties. The border-{block,inline} are shorthand for their respective -start/-end shorthands, though you can only specify one value (which is used on both the -start/-end

Intent to Implement and Ship: The border-{start,end}-{start,end}-radius CSS properties

Summary: The border-{start,end}-{start,end}-radius CSS properties are flow-relative versions of their corresponding physical property, border-top-left-radius etc Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1520684 Link to standard:

Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

On 1/14/19 7:23 PM, Boris Zbarsky wrote: Do you know whether this is purposeful or just a typo? Dunno. It seems like a typo to me. 2) We are just implementing the padding shorthands for now, not the margin ones? Yes, but I should probably just add margin-block/inline while I'm at it...

Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

Summary: The padding-block CSS property is a shorthand for the padding-block-start/end properties (ditto -inline) Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1519847 Link to standard: https://drafts.csswg.org/css-logical/#propdef-padding-inline Platform coverage: All platforms

Intent to Implement and Ship: CSS margin-block and margin-inline shorthands

Summary: The margin-block CSS property is a shorthand for the margin-block-start/end properties (ditto -inline) Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1519944 Link to standard: https://drafts.csswg.org/css-logical/#propdef-margin-inline Platform coverage: All platforms Estimated

Intent to implement and ship: CSS counter-set property

Summary: The counter-set CSS property assigns an absolute value to a CSS counter. (It behaves the same as counter-increment but assigns instead of increments.) It will be used internally to map to set the value of the built-in 'list-item' counter (see separate announcement following this).

Intent to implement and ship: built-in CSS counter 'list-item'

Summary: The built-in 'list-item' counter is used to implement HTML / (and other elements with display:list-item) using CSS. I'm also removing our old (frame-based) code for list item counters, which had a number of decades-old bugs (bug 4522 et al), was rather slow (bug 3246) and crashy (bug

Intent to implement and ship: CSS ::marker pseudo-element

Summary: The ::marker pseudo-element represents the automatically generated marker box of a list item. It allows authors to style the marker and generate content for it through its 'content' property (like ::before/::after). Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=205202 Animation

Re: Intent to implement and ship: built-in CSS counter 'list-item'

On 3/25/19 6:21 AM, Domenic Denicola wrote: > The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item > seems to contradict that hard-fought consensus. It seems like a > regression to implement list item numbering according to that spec, > instead of according to HTML. As others

Re: Intent to implement and ship: built-in CSS counter 'list-item'

On 3/27/19 12:30 AM, Domenic Denicola wrote: (On-list this time) However, the actual semantics for how list items work are exclusively defined by CSS ([css-lists], [css-pseudo]). The above mentioned HTML elements/attributes simply maps to the relevant CSS properties, using a built-in

Intent to implement and ship: CSS 'prefers-color-scheme' media feature

Summary: The 'prefers-color-scheme' media feature is way for pages to detect if the user prefers a light or dark color theme. The values are 'light', 'dark', and 'no-preference'. If the "resist fingerprinting" feature is active we always match 'light'. If the media type is 'print' we always

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

On 7/4/19 1:11 PM, Henri Sivonen wrote: I don't _know_, but most like they want to benefit from optimizations based on overflow being UB. It's worth noting that such optimizations can be exploitable if an overflow do occur. See bug 1292443 for an example. Compiling with -fwrapv would fix

Re: Intent to ship: CSS 'display:block ruby'

On 8/14/19 9:51 PM, David Burns wrote: Are there any web platform tests for this ... Yes, it seems I missed to include this item in my original email: Tests: WPT and other tests were added. /Mats ___ dev-platform mailing list

Re: Intent to ship: multi-keyword values on the CSS 'display' property

On 8/14/19 6:52 PM, Boris Zbarsky wrote: On 8/14/19 12:37 PM, Mats Palmgren wrote: This first patch set adds support for the new syntax only, but no new box types (I'll add those separately in a bit). In general, it seems like we should think about how to integrate this stuff into layout

PSA: Removing display:-moz-inline-grid and -moz-inline-stack

In bug 1574994, I'm removing the display:-moz-inline-grid/stack values. (They are inline-level versions of display:-moz-grid/stack XUL boxes which we continue to support, for now). These values are not exposed to web-content and there are no internal uses in mozilla-central nor comm-central.

Intent to ship: CSS 'display:inline list-item' and 'display:inline flow-root list-item'

Summary: Add support for 'display:inline list-item', which creates an inline box with a ::marker box inside it, and 'display:inline flow-root list-item', which creates an inline-block with a ::marker (inside or outside). Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1105868 Standard:

Intent to ship: multi-keyword values on the CSS 'display' property

Summary: Add support for multi-keyword values on the CSS 'display' property. The spec splits this property into three parts: an outside part, an inside part, and a list-item part so the author can specify them separately. This first patch set adds support for the new syntax only, but no new box

Intent to ship: CSS 'display:block ruby'

Summary: Add support for 'display:block ruby' which creates a block box with a ruby box inside it. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1557825 Standard: https://drafts.csswg.org/css-display/#the-display-properties Platform coverage: All Estimated or target release: v70

Re: Intent to ship: multi-keyword values on the CSS 'display' property

On 8/26/19 4:42 PM, Boris Zbarsky wrote: On 8/19/19 3:42 PM, Mats Palmgren wrote: Sure.  I'm just saying that I suspect some of the combinations may be hard to implement using anon boxes, depending on what combinations are allowed. For example, can one have a thing which is "table

Re: Intent to ship: CSS subgrid

On 10/17/19 8:12 PM, ikilpatr...@chromium.org wrote: On Thursday, October 17, 2019 at 11:06:48 AM UTC-7, Mats Palmgren wrote: As far as I know, we never constrain new CSS features to secure contexts. At least not on the property/value level. According to https://blog.mozilla.org/security/2018

Re: Intent to ship: CSS subgrid

On 10/17/19 5:35 PM, ikilpatr...@chromium.org wrote: On Wednesday, October 16, 2019 at 11:14:02 AM UTC-7, Mats Palmgren wrote: *Secure contexts:* N/A Replying as requested from: https://twitter.com/ecbos_/status/1184690249324290048 Well, I just copy-pasted the email-template TYLin used

Re: Intent to ship: CSS subgrid

On 10/18/19 12:31 AM, ikilpatr...@chromium.org wrote: I think one interesting part here is that (from my knowledge) this policy actually hasn't been applied yet, due to the "other browsers shipping insecurely" exception. Do other vendors apply the same policy for new CSS features? For

Intent to unship: MathML mfenced element

In bug 1603773 I intend to ship 'mathml.mfenced_element.disabled' set to true in all builds. This pref is already set to true in Nightly builds for ~2 months (added in bug 1587577), so my change just makes it ride the trains. The intention is to remove the preffed-off code eventually. The

Re: Intent to unship: MathML mfenced element

On 12/18/19 10:11 AM, Frédéric Wang wrote: Thanks for doing it. Out of curiosity, what do our counters say about the % of pages containing mfenced relative to the number of pages containing MathML? FYI, most of our telemetry data is public. You should be able to find it from here:

Intent to Prototype: CSS Masonry layout

Summary: Masonry layout is a popular idea of how to lay out content on the web, e.g. a Pinterest wall of images. I've made a detailed proposal on how to support this natively as feature of CSS Grid here: https://github.com/w3c/csswg-drafts/issues/4650 The feedback has been overwhelmingly positive

Intent to ship: CSS overflow:clip

Summary: We intend to ship CSS overflow:clip in v81, which is the standardized version of a prefixed value (-moz-hidden-unscrollable) that we already ship. The prefixed value becomes an alias for the new value. The standardized value is mostly compatible, but there are some differences. Most