Using inline variables (C++17) in Gecko

Hey, I have a use-case for inline variables, and it's not 100% clear to me how up-to-date is [1], so asking this mailing-list directly. Looks like they're supported from clang 3.9 [2] and gcc 7 [3]. We're requiring clang 4.0+ to build already, and IIUC we don't build with MSVC anymore. But

Intent to unship: -moz-binding CSS property from content.

Hi, In bug 1523712 I intend to unship the `-moz-binding` CSS property from content pages. This property is used to attach an XBL binding to an element, and it's pretty much useless already in content because we don't allow to attach XBL bindings to most elements already if not coming from a

Re: Does mozilla allow modification of Strings

There are probably two different issues. On 1/28/19 1:51 PM, edusubscr...@gmail.com wrote: > > > Is it possible to add an extra variable to mozilla string(nsTStringRepr). > > > I added a bool variable to nsTStringRepr class in Xpcom/Strings/ > > While building the build I got

Re: How do we land `./mach vendor rust` patches, these days?

On 1/18/19 4:19 PM, David Teller wrote: > Hi everybody, > > My last two attempts to update our crates with `./mach vendor rust` > failed, not during vendoring, but when I attempted to upload the patch. > Both times, moz-phab/arcanist or phabricator simply choked during the > call and I

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

On 1/14/19 7:23 PM, Boris Zbarsky wrote: > On 1/14/19 12:58 PM, Mats Palmgren wrote: >> Do other browser engines implement this? No, >> https://wpt.fyi/results/css/css-logical/logical-box-padding.html > > Do they plan to?  That is, is the spec reflecting some sort of general > consensus?

PSA: nsIDocument is now mozilla::dom::Document.

I've always been slightly annoyed at the fact that Gecko used to have multiple classes for the same concept of a document node without any clear separation these days (nsIDocument and nsDocument). Over the last week I decided to change that by first merging both in:

Re: Intent to implement and ship: Overflow media queries

On 1/2/19 5:18 PM, James Graham wrote: On 23/12/2018 10:59, Emilio Cobos Álvarez wrote: web-platform-tests: Minimal parsing tests are being added to:    https://wpt.fyi/results/css/mediaqueries/test_media_queries.html Unfortunately WPT has no way to test print preview or pagination right now

Intent to implement and ship: Overflow media queries

Summary: More explicitly expose the kind of handling for overflowing content in media queries. Using a media expression instead of the print media type allows for more flexibility, see the bug description. Implementation wise, we already expose the same kind of information via @media print

Re: Intent to Implement and Ship: break-before, break-after, break-inside CSS properties

CSS too :) -- Emilio On December 7, 2018 at 9:12:39 AM, Emilio Cobos Álvarez (emi...@crisal.io) wrote: Summary: Implement these properties to control breaks in the page, make page-break-{before,after} legacy shorthands of those. Eric Shepherd Senior Technical Writer MDN Web Docs <ht

Re: PSA: Landing Rust code that warns is no longer ok

On 12/15/18 1:35 PM, Xidorn Quan wrote: Does it affect third-party crates? If there is a new warning hits a crate we use, would that cause the build to fail? I suppose not, otherwise there needs to be some additional policy to handle that case I gues? It does not. Cargo is very helpful and

PSA: Landing Rust code that warns is no longer ok

In https://bugzilla.mozilla.org/show_bug.cgi?id=1513009 I just landed a patch so that warnings for non-third-party Rust code get reported as errors in automation, and thus fail to build (also if you build locally with --enable-warnings-as-errors). This is the equivalent of what we already do

Intent to Implement and Ship: break-before, break-after, break-inside CSS properties

Summary: Implement these properties to control breaks in the page, make page-break-{before,after} legacy shorthands of those. This work doesn't imply adding new layout functionality, just the style system rejiggering to make us comply with the spec and be compatible with other engines. Bug:

Re: The tree has been reformatted now!

And https://hg.mozilla.org/mozilla-central/rev/138f65958545 if you use the git driver if you don't want sadness :) -- Emilio On 11/30/18 6:20 PM, Andi-Bogdan Postelnicu wrote: Hello all, I’m coming back with a followup email since I don’t think that in the previous email we mentioned what

Re: The upcoming C/C++ coding style change

On 11/30/18 2:06 AM, Ehsan Akhgari wrote: On Thu, Nov 29, 2018 at 9:43 AM Emilio Cobos Álvarez wrote: On 11/29/18 1:38 PM, Sylvestre Ledru wrote: This extension will automatically rebase the local changes to avoid conflicts. Is there a way to do the same for cinnabar users? Yes! Sorry

Re: The upcoming C/C++ coding style change

On 11/29/18 1:38 PM, Sylvestre Ledru wrote: This extension will automatically rebase the local changes to avoid conflicts. Is there a way to do the same for cinnabar users? -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

Sorry for the lag replying to this. On 11/13/18 4:35 PM, James Graham wrote: On 11/11/2018 17:57, Emilio Cobos Álvarez wrote: web-platform-tests: Test coverage for all the values is pre-existing. There's unfortunately little coverage in WPT, but a lot in our selection and contenteditable

Re: Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

On 11/12/18 2:36 AM, flor...@rivoal.net wrote: On Monday, November 12, 2018 at 2:57:14 AM UTC+9, Emilio Cobos Álvarez wrote: Summary: Unprefix the -moz-user-select property, so that it works without the -moz- prefix. We happen to be supporting the -webkit- prefixed version of the property

Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

Summary: Unprefix the -moz-user-select property, so that it works without the -moz- prefix. We happen to be supporting the -webkit- prefixed version of the property, but other browsers support it also unprefixed, which causes a lot of confusion. As part of this work I'm also unshipping the

Intent to implement and ship: overflow-wrap: anywhere

Summary: Implement a new keyword for the overflow-wrap / word-wrap properties (which are aliases) which affects min-content sizing. We tried to make break-word affect min-content sizing (see bug 1472386), but that was found not to be web-compatible. See

Intent to implement and ship: CSS environment variables.

Summary: Implement the CSS env() function which allows to take a variable name and a fallback value. Note that this intent goes only for the CSS feature, not for the rest of the display cutout support, which is tracked in bug 1503656. This work would add support for four variables (the four

Re: Intent to Implement and Ship: window.screenLeft and window.screenTop aliases

PM Emilio Cobos Álvarez <mailto:emi...@crisal.io>> wrote: (Trying to be more disciplined about pinging dev-platform@ about web-exposed changes, a few other emails will come up in a bit) Summary: I plan to add the screenLeft and screenTop properties to the window, as

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

On 10/17/18 11:56 AM, James Graham wrote: On 17/10/2018 10:12, James Graham wrote: On 17/10/2018 01:23, Emilio Cobos Álvarez wrote: Hi Philip, Do you know how do reftests run in order to get that data? I'm particularly curious about this Firefox-only failure:    css/selectors/selection

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

Hi Philip, Do you know how do reftests run in order to get that data? I'm particularly curious about this Firefox-only failure: css/selectors/selection-image-001.html It passes both on our automation and locally. I'm curious because I was the author of that test (whoops) and the Firefox

Intent to Implement: selector() function for @supports / CSS.supports.

Summary: Fruit of procrastination, I plan to implement (but not ship) David's proposal for a selector() function in @supports. See https://github.com/w3c/csswg-drafts/issues/3207 for an explainer, discussion and context. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1499386 No spec

Intent to Implement and Ship: window.screenLeft and window.screenTop aliases

(Trying to be more disciplined about pinging dev-platform@ about web-exposed changes, a few other emails will come up in a bit) Summary: I plan to add the screenLeft and screenTop properties to the window, as aliases of screenX and screenY respectively, mostly for compat with other engines.

Re: Intent to unship: display: -moz-box and display: -moz-inline-box from content pages.

I just removed the nightly / beta restriction in bug 1496961, so unless there's any regression this should ride the trains in 64. Cheers, -- Emilio On 7/23/18 2:15 AM, Emilio Cobos Álvarez wrote: Hi, In bug 1477553 I intend to disable the ability for content to specify display: -moz-box

Re: Intent to unship: ::-moz-tree pseudo-elements.

On 8/4/18 5:10 PM, Emilio Cobos Álvarez wrote: Hi, In bug 1480054 I intend to avoid exposing the XUL ::-moz-tree pseudo-elements to content pages in Nightly and Early beta, with the hope of eventually riding to release. I just removed the beta / nightly restriction in bug 1496961, so unless

Re: Dead-code removal of unused Rust FFI exports

On 8/28/18 9:35 AM, Henri Sivonen wrote: Does some lld mechanism successfully remove dead code when gkrust exports some FFI function that the rest of Gecko never ends up calling? I would expect LTO to get rid of it, but haven't checked myself. I.e. in terms of code size, is it OK to

Re: PSA: cbindgen will be required to build in the near future.

On 8/17/18 2:53 PM, Xidorn Quan wrote: I'm actually thinking about pulling bindgen out from build-dependency and make it use binary as well. bindgen was made a build-dependency and build in the process because at that time, bindgen wasn't stable enough, and we usually need to fix it for stylo

Re: PSA: cbindgen will be required to build in the near future.

On 8/17/18 1:37 PM, Jan Beich wrote: Emilio Cobos Álvarez writes: Hi, In bug 1478813 (now on inbound), I've added a new toolchain job and code to install cbindgen[1] via `mach bootstrap`, and it will become a hard build dependency in the near future. We use it on the style system

PSA: cbindgen will be required to build in the near future.

Hi, In bug 1478813 (now on inbound), I've added a new toolchain job and code to install cbindgen[1] via `mach bootstrap`, and it will become a hard build dependency in the near future. We use it on the style system to generate C++ structs / enums from the Rust definitions (as opposed to

Intent to unship: ::-moz-tree pseudo-elements.

Hi, In bug 1480054 I intend to avoid exposing the XUL ::-moz-tree pseudo-elements to content pages in Nightly and Early beta, with the hope of eventually riding to release. The reasoning for that is, apart of them being non-standard and such, that they're the only pseudo-elements (except

Intent to unship: display: -moz-box and display: -moz-inline-box from content pages.

Hi, In bug 1477553 I intend to disable the ability for content to specify display: -moz-box and -moz-inline-box, which will be consistent with what we did for the rest of -moz- prefixed values in bug 1288572. We have a use counter for this in [1], which is somewhat high. This could however

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

Thanks for doing this! Just curious, is there a bug on file to measure excess capacity on nsTArrays and hash tables? WebKit has a bunch of bugs like: https://bugs.webkit.org/show_bug.cgi?id=186709 Which seem relevant. -- Emilio On 07/10/2018 08:19 PM, Kris Maglione wrote: Welcome to

Re: Coding style: Making the `e` prefix for enum variants not mandatory?

On 7/6/18 8:21 PM, Ehsan Akhgari wrote: On Fri, Jun 29, 2018 at 2:36 PM, smaug wrote: On 06/29/2018 05:58 PM, Boris Zbarsky wrote: On 6/29/18 10:30 AM, Nathan Froyd wrote: Given the language-required qualification for `enum class` and a more Rust-alike syntax, I would feel comfortable

Intent to Ship: Logical properties in computed style objects.

Hi, In bug 1116638 I made changes so that getPropertyValue in computed style objects would correctly expose logical properties. This is more of a bug-fix than a new feature, but it was probably worth sending an email to the list. Let me know if there's any concern with this. Thanks! --

Re: Coding style: Making the `e` prefix for enum variants not mandatory?

On 6/29/18 12:15 AM, Mike Hommey wrote: On Thu, Jun 28, 2018 at 05:27:23PM +0200, Emilio Cobos Álvarez wrote: I asked kats@ (which added the list item regarding enums) and he was fine removing it from the coding style, so given that and the rest of the thread I've edited the page accordingly

Re: Coding style: Making the `e` prefix for enum variants not mandatory?

guide. On Mon, Jun 25, 2018 at 2:17 PM, Peter Saint-Andre wrote: And perhaps good reason for removing it from the style guide? ;-) On 6/25/18 3:08 PM, Emilio Cobos Álvarez wrote: And Kris pointed out that we already had another huge thread on this: https://groups.google.com/d/msg

Intent to deprecate and remove: offset-* logical properties.

In bug 1464782 I renamed these to inset-*, and left the offset-* properties as an alias behind a (enabled-by-default) pref: layout.css.offset-logical-properties.enabled I want it to turn it off by default sooner rather than later, given no other engine supports it, but keep the pref around

Intent to ship: inset-* logical properties.

Hi, In bug 1464782 I renamed the long-shipped offset-* logical properties (offset-inline-start, offset-inline-end, offset-block-start, offset-block-end), which map to top / bottom / left / right, to their standard name (inset-*), and turned the later into aliases. No other browser

Re: Intent to ship: Some of the mediaqueries-4 syntax improvements.

how unlikely it is to change. Let me know if you think otherwise though. -- Emilio -David On Monday 2018-06-25 21:13 +0200, Emilio Cobos Álvarez wrote: In bug 145 I plan to land most of the syntax improvements to mediaqueries-4. Some of the features included are: * Allowing operators

Re: Coding style: Making the `e` prefix for enum variants not mandatory?

Cobos Álvarez wrote: Our coding style states that we should use an `e` prefix for enum variants, that is:   enum class Foo { eBar, eBaz }; We're not really consistent about it: looking at layout/, we mostly use CamelCase, though we do have some prefixed enums. Looking at other modules, enum

Coding style: Making the `e` prefix for enum variants not mandatory?

Our coding style states that we should use an `e` prefix for enum variants, that is: enum class Foo { eBar, eBaz }; We're not really consistent about it: looking at layout/, we mostly use CamelCase, though we do have some prefixed enums. Looking at other modules, enum classes almost never

Intent to ship: Some of the mediaqueries-4 syntax improvements.

Hi, In bug 145 I plan to land most of the syntax improvements to mediaqueries-4. Some of the features included are: * Allowing operators such as >, <, >=, or <= in media feature expressions, which allows to properly exclude media queries in a way min-* and max-* cannot, like:

Slightly delayed Intent to Ship: getComputedStyle changes on some edge cases.

Hi, Just something I figure was worth sending an email for, due to the potential (ideally positive) web-compat impact. In bug 1467722[1], I brought us closer to the spec and to WebKit / Blink in terms of what happens when we can't return a style for an element from getComputedStyle (mostly

Intent to Unship: -moz-is-resource-document media feature from content pages.

Hi, In bug 1468854 I plan to unship the -moz-is-resource-document media feature from content pages. This was introduced to prevent leaking the theme from SVG resource documents in bug 686581. I expect no compat fallout whatsoever since it can only match, well, in SVG resource documents,

Re: Intent to ship: shape-outside

On 6/11/18 10:19 AM, Bradley Werth wrote: On Mon, Jun 11, 2018 at 7:54 AM, Emilio Cobos Álvarez wrote: On 06/08/2018 08:08 PM, Bradley Werth wrote: On Monday June 11th, I intend to land Bug 1457297 <https://bugzilla.mozilla.org/show_bug.cgi?id=1457297> which will enable shape-o

Re: Intent to ship: shape-outside

On 06/08/2018 08:08 PM, Bradley Werth wrote: On Monday June 11th, I intend to land Bug 1457297 which will enable shape-outside for all channels in Firefox 62. The feature has been on by default in Nightly 61, and available in other channels

Re: Coding style: brace initialization syntax

On 06/05/2018 06:48 PM, Eric Rahm wrote: Reading back through I think the consensus, at least for initializer lists was: 1. Prefer parenthesis, ie: , mBool(true) 2. If using braces, maintain the same spacing you would use with parenthesis, ie: , mStructWithoutCtor{42} 1.

Intent to unship: XUL display values from content pages

Hi, In bug 1288572 I plan to remove the XUL display property values from content pages. This includes the following display values: -moz-grid -moz-inline-grid -moz-grid-group -moz-grid-line -moz-stack -moz-inline-stack -moz-deck -moz-popup -moz-groupbox This was going to

Re: Intent to Unship: -moz-window-opacity / -moz-window-transform / -moz-window-transform-origin CSS properties.

The subject of the email should probably say "from content pages" :) On 6/2/18 5:18 PM, Emilio Cobos Álvarez wrote: Hi, In bug 1419695 I plan to unship the CSS properties mentioned in the subject of this email. The only reason they were exposed were because they landed as ac

Intent to Unship: -moz-window-opacity / -moz-window-transform / -moz-window-transform-origin CSS properties.

Hi, In bug 1419695 I plan to unship the CSS properties mentioned in the subject of this email. The only reason they were exposed were because they landed as accidentally exposed given the confusing semantics of the "internal" properties (that just hides them from CSSOM enumeration code),

PSA: No more mozilla::Move

Hi, just a quick PSA: In bug 1465585 I switched all uses of mozilla::Move to std::move, and removed the former. The reasoning for that is that it allows compilers to detect misuses of std::move and warn about them (-Wpessimizing-move / -Wself-move / -Wreturn-std-move). Beware of some local mac

Intent to unship: getPropertyCSSValue-related interfaces Rect, RGBColor, CSSValue, CSSPrimitiveValue and CSSValueList

Related to the unshipping of getPropertyCSSValue, in bug 1459871 I intend to unexpose the following related interfaces from the platform: Rect, RGBColor, CSSValue, CSSPrimitiveValue, CSSValueList Instances of these objects could only be constructed via getPropertyCSSValue, so they're not

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

and similar bits. Does that seem like a reasonable path forward? Thanks! -- Emilio -David On Saturday 2018-05-12 11:30 +0200, Emilio Cobos Álvarez wrote: Following up on this, no breakage whatsoever was reported, so I removed the pref and the API from the tree in bug 1408301. Thanks

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

this... probably we should uplift a pref switch to beta to make it unship in 61 directly, and then remove in 62. I think that's probably safer than not unshipping it in 61 but removing directly in 62. - Xidorn On Sat, May 12, 2018, at 7:30 PM, Emilio Cobos Álvarez wrote: Following up

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

Following up on this, no breakage whatsoever was reported, so I removed the pref and the API from the tree in bug 1408301. Thanks, -- Emilio On 3/23/18 7:23 PM, Emilio Cobos Álvarez wrote: Hi, Bug 1408301 tracks unshipping CSSStyleDeclaration.getPropertyCSSValue. This is a non-standard

Re: Intent to unprefix: ::-moz-selection.

AM, Emilio Cobos Álvarez wrote: Hi, In bug 509958 I intend to unprefix the ::-moz-selection pseudo-element. The situation here is not great wrt the spec saying what we do, or what other implementations do for that matter, see [1]. However other engines have shipped this unprefixed for a long time

Re: Intent to unprefix: ::-moz-selection.

that they can remove it. -- Emilio On Mon, Mar 26, 2018 at 9:21 AM Emilio Cobos Álvarez <emi...@crisal.io> wrote: Hi, In bug 509958 I intend to unprefix the ::-moz-selection pseudo-element. The situation here is not great wrt the spec saying what we do, or what other implementati

Re: Default Rust optimization level decreased from 2 to 1

On 4/25/18 6:11 PM, Gregory Szorc wrote: On Apr 25, 2018, at 08:35, Emilio Cobos Álvarez <emi...@crisal.io> wrote: There's a fair amount of people bitten by this constantly, which see long style profiling markers and what's really happening is that they're profiling a local opt

Re: Default Rust optimization level decreased from 2 to 1

There's a fair amount of people bitten by this constantly, which see long style profiling markers and what's really happening is that they're profiling a local opt build, and thus the Rust code in style has barely any optimization and is slow. I know that shouldn't be a thing, and that people

Re: Coding style: brace initialization syntax

On 4/13/18 4:49 PM, Nathan Froyd wrote: On Fri, Apr 13, 2018 at 9:37 AM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: Those changes I assume were generated with clang-format / clang-format-diff using the "Mozilla" coding style, so I'd rather ask people to agree in whether we p

Coding style: brace initialization syntax

Sorry, I know, coding style thread... But it's Friday and this is somewhat related to the previous thread. Bug 525063 added a lot of lines like: explicit TTextAttr(bool aGetRootValue) : mGetRootValue(aGetRootValue) , mIsDefined{ false } , mIsRootDefined{ false } {

Intent to ship: Allow the overflow shorthand to accept two values.

Hi, In bug 1453148 I'm planning to implement the CSSWG resolution at: https://github.com/w3c/csswg-drafts/issues/2484 It's a very uncontroversial change that doesn't change backwards compat, and makes the shorthand more consistent. But it was probably worth an intent. WPT tests are being

Re: Intent to unprefix: ::-moz-selection.

On 03/28/2018 12:09 AM, twisniew...@mozilla.com wrote: > On Tuesday, March 27, 2018 at 4:38:56 PM UTC-4, Emilio Cobos Álvarez wrote: >> That looks like an easy fix though, I'll ensure it gets fixed before >> landing. Filed bug 1449010. > > If it helps, I had a patchset f

Re: Intent to unprefix: ::-moz-selection.

On 3/26/18 4:13 PM, Boris Zbarsky wrote: On 3/26/18 3:16 AM, Emilio Cobos Álvarez wrote: However other engines have shipped this unprefixed for a long time with the same semantics that we implement https://bugzilla.mozilla.org/show_bug.cgi?id=509958#c14 claims the semantics are not actually

Intent to unprefix: ::-moz-selection.

Hi, In bug 509958 I intend to unprefix the ::-moz-selection pseudo-element. The situation here is not great wrt the spec saying what we do, or what other implementations do for that matter, see [1]. However other engines have shipped this unprefixed for a long time with the same semantics that

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

On 03/23/2018 11:50 PM, Jonathan Watt wrote: > On 23/03/2018 18:23, Emilio Cobos Álvarez wrote: >> Bug 1408301 tracks unshipping CSSStyleDeclaration.getPropertyCSSValue. >> >> This is a non-standard API only implemented by Mozilla > > It was removed from Blink[1]

PSA: --disable-stylo is gone.

Following [1], the code for the old style system has been removed[2][3], and cleanups started[4][5]. There's tons of easy-ish cleanups that you're welcome to help with if you want, see bugs blocked by https://bugzil.la/stylo-everywhere. The --disable-stylo build option is gone[6], and thus you

PSA: --disable-stylo is gone

Following my last message[1], the code for the old style system has been removed (bug 1447358, bug 1447367), and cleanups started (bug 1447367, bug 1447476, ...). There's tons of easy-ish cleanups that you're welcome to help with if you want, see bugs blocked by

Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

Hi, Bug 1408301 tracks unshipping CSSStyleDeclaration.getPropertyCSSValue. This is a non-standard API only implemented by Mozilla, and that generally can be replaced by usage of the standard .getPropertyValue. We added a use counter and deprecation warning in bug 474655. The data seems to

PSA: --disable-stylo is gone.

Following [1], the code for the old style system has been removed[2][3], and cleanups started[4][5]. There's tons of easy-ish cleanups that you're welcome to help with if you want, see bugs blocked by https://bugzil.la/stylo-everywhere. The --disable-stylo build option is gone[6], and thus you

PSA: No longer needed to annotate tests differently for stylo-disabled platforms.

In bug 1446954 I'm removing those platforms from our automation in preparation to removing the old code, now that stylo is enabled everywhere. This mostly affects you if you're hacking on the style system itself, or in Shadow DOM stuff, which only works on the new style system. There's probably

Re: Intent to ship: OpenType Variation Font support

On 03/20/2018 11:22 AM, Jonathan Kew wrote:> There are a handful of tests now in > web-platform/tests/css/css-fonts/variations, and there a bunch more > currently in preparation (e.g. see > https://bugzilla.mozilla.org/show_bug.cgi?id=1436588). There's also

Re: Intent to unship: @-moz-document from content pages.

On 3/19/18 11:21 AM, Emilio Cobos Álvarez wrote: > On 11/29/17 6:36 PM, Mike Taylor wrote: >> >>> On Nov 29, 2017, at 10:53 AM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: >>> >>> In bug 1035091 I intend to remove support for the @-moz-document C

Re: Intent to unship: @-moz-document from content pages.

On 11/29/17 6:36 PM, Mike Taylor wrote: > >> On Nov 29, 2017, at 10:53 AM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: >> >> In bug 1035091 I intend to remove support for the @-moz-document CSS >> rule in content pages (more exactly in author stylesheets).

Re: skip-if(verify)

t sense, thanks a lot! -- Emilio > On Tue, Mar 6, 2018 at 10:49 AM, Emilio Cobos Álvarez <emi...@crisal.io> > wrote: > >> On 03/06/2018 06:04 PM, Geoffrey Brown wrote: >>> It is now possible to skip tests in test-verify. Simplify annotate the >>>

Re: skip-if(verify)

On 03/06/2018 06:04 PM, Geoffrey Brown wrote: > It is now possible to skip tests in test-verify. Simplify annotate the > manifest for your test: > > [test] > skip-if = verify > > or, for reftests: > > skip-if(verify) ... > > and the test-verify (TV) test task will not try to verify the

Re: Intent to unship: ::-moz-math-anonymous.

On 02/21/2018 09:13 PM, Frédéric Wang wrote: On 21/02/2018 19:07, Emilio Cobos Álvarez wrote: On 02/21/2018 07:02 PM, Tantek Çelik wrote: SGTM. I did not find any references on MDN, so nothing to update there AFAIK. However with a broader web search I found https://gist.github.com/yields

Re: Intent to unship: ::-moz-math-anonymous.

the -moz-math- pseudos. On Wed, Feb 21, 2018 at 4:30 AM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: Hi, In bug 1439837 I intend to remove access to the ::-moz-math-anonymous pseudo-element. This is a Gecko-only pseudo-element that is there since the initial Gecko export, and is onl

Intent to unship: ::-moz-math-anonymous.

Hi, In bug 1439837 I intend to remove access to the ::-moz-math-anonymous pseudo-element. This is a Gecko-only pseudo-element that is there since the initial Gecko export, and is only used to get a style inheriting from another one for some MathML characters, so it has no good reason to be

Intent to unship: Legacy -moz-transform syntax.

Hi, In bug 1438297 I intend to remove the legacy syntax for -moz-transform, which allows lengths or percentages apart from numbers in some transform matrix components. That will make -moz-transform a normal alias for the "transform" property, just like -webkit-transform, following the usual

Re: Intent to unship: -moz-user-input: disabled / enabled

On 02/14/2018 06:00 PM, L. David Baron wrote: On Wednesday 2018-02-14 09:25 +0100, Emilio Cobos Álvarez wrote: Hi, In bug 1405087 I intend to remove the "enabled" and "disabled" values of the -moz-user-input property. Do other browser engines implement the 'user-input

Intent to unship: -moz-user-input: disabled / enabled

Hi, In bug 1405087 I intend to remove the "enabled" and "disabled" values of the -moz-user-input property. The reasoning for this is because they're slightly broken in presence of dynamic changes (see the bug), and their usage seems low / web-compat risk seems not too high. In particular,

Commit messages in Phabricator

Hey, So I've been testing Phabricator for a while and I've noticed that the arc tool uses different formatting for the commit messages than what usually lands on mozilla-central. In particular I usually lay out my commits like: --- Bug XXX: Short summary. r= Long description, if needed.

Re: gkrust compilation RAM requirements and 32-bit systems

On 02/09/2018 10:49 AM, Henri Sivonen wrote: > Is there some trick to make gkrust compilation succeed on a 32-bit system? The BSD folks seem to be using --disable-debug-symbols for that, see https://bugzilla.mozilla.org/show_bug.cgi?id=1401093 -- Emilio

Re: Correct way to build style bindings on GNU/Linux ARMv7?

On 02/07/2018 06:04 PM, Henri Sivonen wrote: > mach bootstrap doesn't appear to download a bindgen-compatible clang > on an ARMv7 GNU/Linux host. > > mach build then complains about not being able to generate the stylo bindings. > > As I understand it, --disable-stylo-build-bindgen should be OK

Re: Intent to ship: Array.prototype.values

On 02/02/2018 03:27 PM, Andrew Overholt wrote: > On Fri, Feb 2, 2018 at 8:45 AM, Tom Schuster > wrote: > > Chrome seems to > want to add a kill pref for this,  from my experience more difficult > for us with the way we define methods in

Re: How to use Gecko in my web browser as web engine

I think probably dev-platform is a better list to get an answer regarding Gecko embedding, rather than dev-tech-layout, so posting there. I wish I could be more helpful, but I know nothing about that :). -- Emilio On 1/31/18 8:23 AM, malay emailme wrote: > Dear Sir, >I want to

Re: Intent to implement: support CSS paint-order for HTML text

On 12/24/2017 02:01 PM, Jonathan Kew wrote: > Tests - Is this feature fully tested by web-platform-tests? No, as it is > not yet spec'd (see above). I propose to land a basic mozilla reftest > along with the patches in bug 1426146 (behind a pref); if/when the CSS > WG agrees to accept this issue

Re: Next year in web-platform-tests

On 12/16/2017 04:57 AM, L. David Baron wrote: > On Friday 2017-12-15 16:00 -0600, Andrew McCreight wrote: >> For me, a blocker to only having WPT is leak checking, both in terms of >> XPCOM leak checking and LeakSanitizer. (The latter is probably going to >> automatically work if you run them in

Re: Intent to implement: individaul transform

On 12/15/2017 08:51 AM, Ku(顧思捷)CJ wrote: > Summary: > The translate, rotate, and scale properties allow authors to specify > simple transforms independently, in a way that maps to typical user > interface usage, rather than having to remember the order in transform that > keeps the actions of

Re: Intent to unship: @-moz-document from content pages.

On 11/29/2017 06:36 PM, Mike Taylor wrote: > >> On Nov 29, 2017, at 10:53 AM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: >> >> In bug 1035091 I intend to remove support for the @-moz-document CSS >> rule in content pages (more exactly in author stylesheets).

Intent to unship: @-moz-document from content pages.

Hi again, In bug 1035091 I intend to remove support for the @-moz-document CSS rule in content pages (more exactly in author stylesheets). The reasoning for this, apart from it being a non-standard mozilla-only CSS feature, is that it's a possible security risk in presence of CSS injection

Intent to unship -moz-border-*-colors from content pages.

Hi dev-platform@, In bug 1417200, I intend to hide the -moz-border-top-colors, -moz-border-bottom-colors, -moz-border-left-colors, and -moz-border-right-colors from content pages. The reasons for doing this are multiple: * Non-standard properties. * Kinda-weird, in the sense that the

Re: Intent to implement (again): Shadow DOM

On 11/28/2017 10:44 AM, Philip Jägenstedt wrote: > On Mon, Nov 27, 2017 at 2:50 PM Emilio Cobos Álvarez <emi...@crisal.io > <mailto:emi...@crisal.io>> wrote: > > On 11/27/2017 02:01 PM, James Graham wrote: > > On 27/11/17 12:20, smaug wrote: > >&

Re: Intent to implement (again): Shadow DOM

On 11/27/2017 02:01 PM, James Graham wrote: > On 27/11/17 12:20, smaug wrote: >> This is basically an after the fact notification that >> we're in progress of implementing Shadow DOM again, this time v1[1]. >> While doing this, the v0 implementation, which was never exposed to >> the web, will be

Re: Fennec/Android turns on Quantum CSS (stylo) as default

On 11/22/2017 05:15 PM, Tom Ritter wrote: > On Wed, Nov 22, 2017 at 9:51 AM, Jet Villegas wrote: >> Do you have a use case for shipping the ESR with --disable-stylo? We want to >> be very quick about removing the legacy C++ style system as it adds >> significant impedance

Re: Intent to unship: mozmm CSS unit.

On 11/15/2017 11:51 AM, Jonathan Kew wrote: > On 15/11/2017 03:32, Emilio Cobos Álvarez wrote: > >> So, I've looked through and I haven't found any related minutes (I've >> looked for minutes that mentioned "physical", of which they were many, >> but all related

Re: Intent to unship: mozmm CSS unit.

Hi David, On 11/15/2017 02:27 AM, L. David Baron wrote: > On Sunday 2017-11-12 16:11 +0100, Emilio Cobos Álvarez wrote: >> Hi, >> >> In bug 1416564 I intend to remove the mozmm CSS unit. >> >> This unit is Mozilla-only, has no spec, and is unused in all our >&

<    1   2   3   >