Re: Should &&/|| really be at the end of lines?

On Wed, Feb 22, 2017 at 10:27:33AM -0500, Benjamin Smedberg wrote: > On Thu, Feb 16, 2017 at 4:47 PM, wrote: > > > Question of the day: > > When breaking overlong expressions, should &&/|| go at the end or the > > beginning of the line? > > > > TL;DR: Coding style says 'end', I&others think we sh

Re: Should cheddar-generated headers be checked in?

On Thu, Feb 23, 2017 at 08:25:30AM +0200, Henri Sivonen wrote: > On Wed, Feb 22, 2017 at 5:49 PM, Ted Mielczarek wrote: > > Given that > > the C API here is under your complete control, it seems like it's > > possible to generate a cross-platform header > > I believe the header is cross-platform,

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

On Fri, Mar 17, 2017 at 12:03:30PM +0200, Henri Sivonen wrote: > It seems that our Rust bindings for nsresult are part of Stylo, but > Stylo isn't yet a guaranteed part of the build. FWIW those bindings are only checked-in into Servo for CI purposes (so we can build the Gecko version of the style

Intent to unship: :-moz-bound-element pseudo-class.

I intend to remove the :-moz-bound-element CSS pseudo-class in bug 1350147. It's an XBL-related pseudo-class that allows matching the XBL element bound in the current subtree. We could implement it in Stylo, I guess, but it is slightly annoying, and seems completely unused and untested both in mo

Using references vs. pointers in C++ code

Hi dev-platform@, So, yesterday was working on a bug (bug 1362991, if you're curious) when I decided to do some spring cleanup and pass some non-optional argument as a reference instead of as a pointer. I got the cleanup patch rejected, because it went against the prevailing style of the codebase

Re: Using references vs. pointers in C++ code

On Tue, May 09, 2017 at 06:24:56PM +0300, smaug wrote: > On 05/09/2017 04:52 PM, smaug wrote: > > On 05/09/2017 01:55 PM, Mike Hommey wrote: > > > On Tue, May 09, 2017 at 01:31:33PM +0300, Henri Sivonen wrote: > > > > On Tue, May 9, 2017 at 12:58 PM, Emilio

Re: Using references vs. pointers in C++ code

On Tue, May 09, 2017 at 02:11:41PM -0700, L. David Baron wrote: > On Tuesday 2017-05-09 11:58 +0200, Emilio Cobos Álvarez wrote: > > I think references help to encode that a bit more in the type system, > > and help reasoning about the code without having to look at the > >

Re: Using references vs. pointers in C++ code

On Tue, May 09, 2017 at 06:56:03PM -0700, L. David Baron wrote: > On Wednesday 2017-05-10 02:43 +0200, Emilio Cobos Álvarez wrote: > > The issue I have with per-type conventions is that it doesn't scale very > > well, specially when you're writing new code (and more spe

Re: C++ performance test harness?

On 07/05/2017 10:19 AM, Henri Sivonen wrote: > Do we have a gtest analog for local performance testing? That is, > something that makes it easy to microbenchmark libxul methods? For CSS parsing there is a benchmark using MOZ_GTEST_BENCH[1]. From grepping a bit seems like we also use it for testin

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

On 07/07/2017 06:03 AM, Xidorn Quan wrote: > On Fri, Jul 7, 2017, at 01:42 PM, Jet Villegas wrote: >> Thanks for cleaning this up. >> >> On Thu, Jul 6, 2017 at 8:29 PM, Xidorn Quan wrote: >> >>> Although they don't currently match anything on web content, there is >>> still some risk for unshipp

Re: Care in the use of MOZ_CRASH_UNSAFE_* macros: data review needed

On 07/17/2017 05:18 PM, Benjamin Smedberg wrote:> Unlike MOZ_CRASH, which only annotates crashes with compile-time constants > which are inherently not risky, both MOZ_CRASH_UNSAFE_OOL and > MOZ_CRASH_UNSAFE_PRINTF can annotate crashes with arbitrary data. Crash > reasons are publicly visible in cr

Re: wpt CSS tests now running on Linux

Thanks for this James! \o/ One question, do we run the CSS test linter on automation, or are there any plans for it? We probably should, because otherwise we may only notice when trying to upstream, like in [1], which is more work for everyone. [1]: https://github.com/w3c/web-platform-tests/pull

Re: Keyboard APZ has landed on Inbound

On 07/22/2017 08:05 AM, Ryan Hunt wrote: > Keyboard APZ can't be used in every case. Currently it's disabled in the > presense of key event listeners, as they can preventDefault scrolling and that > is a non-negotiable part of the web. Just curious, is there data about how often this happens? Does

Debugging Firefox e10s with rr?

Hi, I didn't find any obvious docs in either the rr wiki[1] or MDN, so I thought I'd ask before I actually need it. What is the best/easiest way to debug Firefox multi-process using rr? Right now I just disable e10s, but that's probably not a great long-term solution... -- Emilio [1]: https:/

Re: Debugging Firefox e10s with rr?

On 08/29/2017 03:16 PM, Kartikaya Gupta wrote: > Once you have a recording > you can use `rr ps` to show all the process that were recorded and `rr > replay -p ` to attach to a particular process. I see, so `rr ps` was the bit whose existence I was missing :) Thanks a lot! -- Emilio ___

Intent to unship: :-moz-system-metric pseudo-class and media queries in content pages.

Hi dev-platform@, I'd like to unship access to the :-moz-system-metric pseudo-class, and the system metric media queries, from content pages. I just filed for that. They're not in any spec, and they seem unused (I can't find anything non-mozi

Intent to unship: :-moz-empty-except-children-with-localname, :-moz-devtools-highlighted, and :-moz-styleeditor-transitioning from content documents.

Pretty much in the same spirit as my previous mail, I intend to unship access to these pseudo-classes in content documents. The idea would be, similarly, to do that for FF 58. The reasoning behind is that there's no spec for them, and they're implementation details, basically. In particular: *

Re: Intent to unship: :-moz-system-metric pseudo-class and media queries in content pages.

On 09/02/2017 12:03 PM, Gijs Kruitbosch wrote: > On 01/09/2017 20:06, Emilio Cobos Álvarez wrote: > Can you elaborate on what you mean by "content pages" in this context? In general I mean "exposed to web authors". > I'm asking because I think the following

Coding style question: Meaningless argument names in declarations

Hi, I have a coding style question which I don't see addressed in the coding style page. Given there have been a few threads lately on coding style, I guess I should just ask. We have a lot of meaningless argument names in function declarations, like: void DoFoo(Element& aElement); Or: en

Re: Coding style question: Meaningless argument names in declarations

On 09/07/2017 04:01 PM, Andrew McCreight wrote: > I don't know if it rises to the level of something that should be in the > style guide, but I find the names very useful as a form of lightweight > documentation. Sure, if you are naming your Foo arguments aFoo the names > aren't useful, but for m

Re: Intent to unship: Visibility of window.content to untrusted code

Just for the record, since I got curious and I saw no mention in the intent email: I've noticed that this may be used pretty easily for UA detection. So far [1] is the only remotely related thing I've found from a search on Google and GitHub (outside of the firefox codebase ofc). I suspect keepin

Re: getComputedStyle now skips restyling if possible

On 09/28/2017 11:00 AM, Wei-Cheng Pan wrote: > Hi, > > This week I landed bug 1363805[1], which will skip restyling if the > element does > not need that for getting correct value. Normal users should not notice any > difference, but this change may affect some test cases which need to force > res

Re: Intent to implement: CSS media queries, interaction media features

On 10/03/2017 10:12 PM, Thomas Wisniewski wrote:> Security & Privacy Concerns: this exposes whether the user has pointer that > is finely controlled like a mouse, or more coarse-grained like a > touchscreen (or no pointer at all). It also exposes whether they have a > pointer capable of "hover" eff

#pragma once?

Hi, I'm adding a header to the build, and I'm wondering: Can we use pragma once? I don't see it anywhere in the build except third-party paths and: dom/svg/nsISVGPoint.h xpcom/io/nsAnonymousTemporaryFile.h So I'm not sure if it's because it's somehow prohibited or not recommended, or just b

Re: Default Rust optimization level decreased from 2 to 1

On 10/25/2017 07:59 PM, Boris Zbarsky wrote: > On 10/25/17 1:34 PM, Gregory Szorc wrote: >> Also, due to ongoing work around Rust integration in the build system, it >> is dangerous to rely on manual `cargo` invocations to compile Rust >> because >> bypassing the build system (not using `mach bui

Intent to remove: elements matching hack

Hi, In bug 1374247, I intend to remove the XBL compatibility hack introduced in bug 653881 [1] for which elements may be "transparent" in selector-matching. That means that a selector like .foo > .bar, would match a tree like: The motivation is the following: This was no

Intent to unship: as in image maps

Hi, In bug 1317937 I intend to unship the feature of elements acting the same way as elements in image maps. This functionality was specced in HTML 4, but no other browser implemented it and was removed from HTML 5. Timothy (:tnikkel) tried to do it before, but it got blocked on getting teleme

Intent to unship: mozmm CSS unit.

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 codebase (except for two tests, one of those which tests the unit itself). This unit was introduced experimentally in bug 537890, our browser chrome code used it in bug 5884

Re: Intent to unship: mozmm CSS unit.

On 11/12/2017 05:14 PM, Xidorn Quan wrote: > IIRC, we have discussed unshipping this somewhere before we added its > support to stylo (maybe the Taipei meeting this year?) and dbaron said > that mozmm provides an ability to size something based on physical size > which is not directly possible in

Re: Intent to unship: mozmm CSS unit.

Also, another thought I just had about this unit: Probably if we don't unship it, then privacy.resistFingerPrinting should do something about it, since it allows to calculate the DPI of the screen trivially using CSSOM accessors. Filed bug 1416574. ___ d

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

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

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 to new feature developmen

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 r

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 <mailto:emi...@crisal.io>> wrote: > > On 11/27/2017 02:01 PM, James Graham wrote: > > On 27/11/17 12:20, smaug wrote: > >> This is basically an

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 "border"

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 attack

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 wrote: >> >> In bug 1035091 I intend to remove support for the @-moz-document CSS >> rule in content pages (more exactly in author stylesheets). > > This is

Re: Firefox build issues with Rust and the new VS2017 15.5 update

On 12/05/2017 05:16 PM, Ryan VanderMeulen wrote: > FYI, the VC++ 2017 v14.12 toolset included in the recently-released VS2017 > 15.5 update appears to have broken building Firefox due to issues with the > Rust compiler (in particular, the version of libclang we ship with it) and > one of the system

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 t

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 AS

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

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 SpiderMonkey. Should th

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 i

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

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

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,

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

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

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 e

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

-moz-math- pseudos. On Wed, Feb 21, 2018 at 4:30 AM, Emilio Cobos Álvarez 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 only used to get a style

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

Re: skip-if(verify)

kes perfect sense, thanks a lot! -- Emilio > On Tue, Mar 6, 2018 at 10:49 AM, Emilio Cobos Álvarez > wrote: > >> 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 te

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 wrote: >> >> In bug 1035091 I intend to remove support for the @-moz-document CSS >> rule in content pages (more exactly in author stylesheets). > > This is a prett

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 wrote: >>> >>> In bug 1035091 I intend to remove support for the @-moz-document CSS >>> rule in cont

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 https://github.com/w3c/web-platform-test

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 a

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 indica

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 ma

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 https://bugzil.la/stylo-everywhere.

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 ma

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]

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 w

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

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 patch

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 adde

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 } {

Re: Coding style: brace initialization syntax

On 4/13/18 4:22 PM, Boris Zbarsky wrote: So my take is that we should not use braced initializer syntax in constructor initializer lists.  The reason for that is that it makes it much harder to scan for where the constructor body starts. I don't think that's true in the general case where th

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 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 prefer that style or

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: 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 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 build, an

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

enough to hint them that they can remove it. -- Emilio On Mon, Mar 26, 2018 at 9:21 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 d

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 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 unship: CSSStyleDeclaration.getPropertyCSSValue

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

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

emove all the CSSValue related code 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 fr

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 use

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 b

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), and

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

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

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 b

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

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, an

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 r

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

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 u

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

/18 10:41 PM, Emilio 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. Lookin

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

think it's worth it given 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 include

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 implements

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 f

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

be in the style 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.g

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 accord

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! -- E

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 w

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 th

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 b

  1   2   3   >