Hello,
Here's the list of new issues found and filed by the Desktop Release QA team
last two weeks.
Additional details on the team's priorities last week, as well as the plans for
the current week are available at: https://tinyurl.com/yb3fuetd
Bugs logged by Desktop Release QA in the last 8 days
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
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
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
How does the particular set of features that you're planning to ship
vs. not ship align with what other browsers have shipped (or are
close shipping)?
-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
> mediaque
And Kris pointed out that we already had another huge thread on this:
https://groups.google.com/d/msg/mozilla.dev.platform/WAuySoTfq_w/-DggRotpBQAJ
Looks like there wasn't agreement on that one... But oh well, don't want
to repeat a lot of that discussion.
I think the argument for consistenc
On 6/25/18 11:01 PM, L. David Baron wrote:
How does the particular set of features that you're planning to ship
vs. not ship align with what other browsers have shipped (or are
close shipping)?
I'm not aware of any other browser implementing or shipping any of the
changes from MQ3 to MQ4, so w
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/mozilla.dev.platform/WAuySoTfq_w/-DggRotpBQAJ
>
>
> Looks like there w
If we can't agree, it shouldn't 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
Hi,
After Firefox 57 removed support for legacy extensions, I decided to
(roughly) track how much XPIDL code we have. Here are some measurements:
Fri, Aug 4, 2017: m-i 372493:72873c109b1b
.idl files: 1167
.idl lines: 110240 total
.xpt bytes: 417621 total
Thu, Aug 17, 2017: m-i 375206:7a794cd2aee
On Tuesday 2018-06-26 14:29 +1000, Nicholas Nethercote wrote:
> The trend is clearly down, except for the large increase in .xpt size for
> the most recent measurement -- note the extra digit! It appears that .xpt
> files used to be binary, and now they are JSON. This might be related to
> mccr8's
On Mon, Jun 25, 2018 at 09:45:22PM -0700, L. David Baron wrote:
On Tuesday 2018-06-26 14:29 +1000, Nicholas Nethercote wrote:
The trend is clearly down, except for the large increase in .xpt size for
the most recent measurement -- note the extra digit! It appears that .xpt
files used to be binar
On 6/26/18 12:45 AM, L. David Baron wrote:
What's the relative value of making something not use xpidl anymore
vs. marking an xpidl interface as no longer [scriptable]?
I think the main value is in not using xpidl anymore, for two reasons:
1) You can't devirtualize things while still using xpi
13 matches
Mail list logo
