BMO service degradation

[Mark Côté]

As a result of the migration of bugzilla.mozilla.org (BMO) from SCL3 to AWS, 
mail from BMO is currently being sent very slowly. The mail servers are 
processing requests much more slowly than expected. There is no data loss; the 
mail will be sent out eventually. The BMO and Cloud Operations teams are 
actively investigating. I will send out another update later today, or when the 
problem is fully resolved.

As the delay is variable and depends on load, you may want to message users 
directly with bug numbers if you have time-sensitive issues.

You may also receive some duplicate bugmail today; that was an unrelated 
problem that we are also investigating but appears under control.

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

Style proposal: char32_t for Unicode scalar values

[Henri Sivonen]

Considering that C++11 has a type for a Unicode scalar value and
considering that our compilers support C++11, I suggest we adopt a C++
code style guideline that we should use char32_t (as opposed to
uint32_t) to represent a single Unicode scalar value as the argument
type or return value of a method.

Rationale: Say what you mean when the language has vocabulary to do so.

Note: I'm not advocating for UTF-32 strings, i.e. having a buffer of
multiple char32_t values. UTF-32 string are, in my opinion, a design
bug, and I want to get rid of the existing cases of UTF-32 strings in
our codebase.

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

Re: BMO service degradation

[Mark Côté]

The issue has been resolved and all queued bugmail has been sent out.  Thank 
you for your patience.

Mark


On Monday, 26 March 2018 11:48:04 UTC-4, Mark Côté  wrote:
> As a result of the migration of bugzilla.mozilla.org (BMO) from SCL3 to AWS, 
> mail from BMO is currently being sent very slowly. The mail servers are 
> processing requests much more slowly than expected. There is no data loss; 
> the mail will be sent out eventually. The BMO and Cloud Operations teams are 
> actively investigating. I will send out another update later today, or when 
> the problem is fully resolved.
> 
> As the delay is variable and depends on load, you may want to message users 
> directly with bug numbers if you have time-sensitive issues.
> 
> You may also receive some duplicate bugmail today; that was an unrelated 
> problem that we are also investigating but appears under control.
> 
> Mark

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

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

[Boris Zbarsky]

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 quite the same.  Have we done some testing 
here?  Including on Edge?  It would be best to just have matching 
semantics, instead of unprefixing with slightly different behavior.


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

Re: Components and QueryInterface can no longer be used in non-system globals

[Boris Zbarsky]

On 3/26/18 1:55 PM, Boris Zbarsky wrote:
I have just landed changes on inbound that restrict WebIDL 
QueryInterface [1] and the Components object [2] to system scopes.


Oh, I meant to mention: in particular there is no longer a Components 
available in XBL bindings attached to non-system-principal elements.  In 
practice, none of our in-content bindings used Components, _and_ we're 
working on getting rid of them anyway.


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

Components and QueryInterface can no longer be used in non-system globals

[Boris Zbarsky]

I have just landed changes on inbound that restrict WebIDL 
QueryInterface [1] and the Components object [2] to system scopes.


There are two caveats:

1)  The Components bit is not fully enforced by the security 
infrastructure yet, but those patches are coming in the next day or so. [3].


2)  "system" in this case includes things that do enablePrivilege.  The 
only consumer blocking this being removed is Talos...


-Boris

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1448397
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1448735 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1448736
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1389585 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1389581
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can we focus more on color management support?

[sime . vidas]

For what it’s worth, here’s a summary of the issue:

Apple’s iMac (since September 2015) and MacBook Pro (since October 2016) 
computers have wide-gamut displays that support the P3 color space (larger than 
the sRGB color space). Unlike Safari and Chrome, Firefox still doesn’t convert 
sRGB data to P3 (for CSS colors and images that lack color space information), 
which results in oversaturated colors. Hence, if you use Firefox for web 
development on a wide-gamut display, you may want to additionally test web page 
colors in a different browser to ensure correct results.

People have been tweeting images that demonstrate this issue; see here: 
https://twitter.com/simevidas/status/954490103560331266
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unprefix: ::-moz-selection.

[Emilio Cobos Álvarez]

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 we implement, and we're seeing webcompat
problems due to people forgetting to include ::-moz-selection in their
style sheets, see bug 1427680 or bug 1448670 for some examples.

Given I don't think other engines have any incentive to implement what
the spec says (given it's slower, and has the chance of giving them
webcompat headache), and that we're compatible with them, I proposed to
adapt the spec to reality in that spec issue, and unprefix our
pseudo-element.

Let me know if there's any concerns with this plan. Thanks!

 -- Emilio

[1]: https://github.com/w3c/csswg-drafts/issues/2474
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can we focus more on color management support?

[Jeff Muizelaar]

Unfortunately it hasn't been a priority. Hopefully we'll get to it eventually.

-Jeff

On Fri, Mar 23, 2018 at 10:56 AM,   wrote:
> Chrome, Safari treat untagged images as sRGB, can read tagged ICCv4 images 
> and support video color management.
>
> Firefox does not have these features by default. Any ETA?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: nsIURI implementations are now threadsafe

[Patrick McManus]

\o/ !!


On Friday, March 23, 2018, Valentin Gosu  wrote:

> Hello everyone,
>
> I would like to announce that with the landing of bug 1447194, all nsIURI
> implementations in Gecko are now threadsafe, as well as immutable. As a
> consequence, you no longer have to clone a URI when you pass it around, as
> it's guaranteed not to change, and now it's OK to release them off the main
> thread.
>
> If you need to change a nsIURI, you should use the nsIURIMutator interface
> (in JavaScript - just call .mutate() on the URI) or the NS_MutateURI
>  TestURIMutator.cpp#22>
> helper class (in C++).
>
> More info here:
> https://wiki.mozilla.org/Necko/nsIURI
>
> If you find any bugs, make them block bug 922464 (OMT-nsIURI)
>
> I'd like to thank everyone who helped review the patches, especially Honza
> Bambas who reviewed most of my patches.
>
> Cheers!
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[desktop] Bugs logged by Desktop Release QA in the last 8 days

[Bogdan Maris]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA team 
last week.
Additional details on the team's priorities last week, as well as the plans for 
the current week are available at: https://goo.gl/fgDzo5

Bugs logged by Desktop Release QA in the last 8 days

Core: Widget: Gtk
NEW - https://bugzil.la/1446905 - [Linux] Toolbar button hover state and the 
pop-up menu should dismiss when click to another toolbar button with pop-up menu

Core: Graphics: Layers
NEW - https://bugzil.la/1446970 - [Linux] Toolbar button hover state was cut 
off when first click on a pop-up menu button

Firefox: Search
NEW - https://bugzil.la/1446934 - The Ecosia search engine is reset to Google 
after migrating to the WebExtension

Core: Canvas: WebGL
NEW - https://bugzil.la/1448002 - [Google Maps] Location names are displayed 
whiteout

Firefox: Activity Streams: Newtab
NEW - https://bugzil.la/1448394 - The "g" letter is cut off in Recommended by 
Pocket "Trending" status

This is available as a Bugzilla bug list as well: https://mzl.la/2ISXaZx

Regards,
Bogdan (:bogdan_maris)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

[Emilio Cobos Álvarez]

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] after they forked, but it's actually still
> implemented in Webkit it seems. Hopefully we shouldn't have too many problems
> removing it though.

Hmm, I should trust less our code comments[1], I guess the "sort of" is
key. :P

Looks like WebKit does indeed implement it, also on specified values (we
only expose it on the computed style declaration). But yeah, given
neither Blink or Edge implement it, and that what we implement is widely
different than what WebKit implements (that Blink thread is a good
summary) sounds unlikely that it cause compat pain.

[1]:
https://searchfox.org/mozilla-central/rev/56274d0a016a6833e5da7770ce70580b6f5abb21/dom/webidl/CSSStyleDeclaration.webidl#22

> 
> Jonathan
> 
> 1. 
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/3VmxWFzcyJc
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: nsIURI implementations are now threadsafe

[Valentin Gosu]

On 23 March 2018 at 21:06, Ben Kelly  wrote:

> This is so great.  Thank you!
>
> One question that comes to mind, though, is there any chance this could be
> uplifted to 60?  As we start doing more OMT nsIURI stuff its going to
> become difficult to uplift code to 60ESR.
>

Certainly doable.
Most of the code landed in 60. Only 5 bugs related to this were landed in
61, 1442239 , 1442242
, 1447190
, 1447194
, 1447330
. Still a fair amount
of code, but it might be worth it.


> On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu 
> wrote:
>
>> Hello everyone,
>>
>> I would like to announce that with the landing of bug 1447194, all nsIURI
>> implementations in Gecko are now threadsafe, as well as immutable. As a
>> consequence, you no longer have to clone a URI when you pass it around, as
>> it's guaranteed not to change, and now it's OK to release them off the
>> main
>> thread.
>>
>> If you need to change a nsIURI, you should use the nsIURIMutator interface
>> (in JavaScript - just call .mutate() on the URI) or the NS_MutateURI
>> > gtest/TestURIMutator.cpp#22>
>> helper class (in C++).
>>
>> More info here:
>> https://wiki.mozilla.org/Necko/nsIURI
>>
>> If you find any bugs, make them block bug 922464 (OMT-nsIURI)
>>
>> I'd like to thank everyone who helped review the patches, especially Honza
>> Bambas who reviewed most of my patches.
>>
>> Cheers!
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

[L. David Baron]

On Friday 2018-03-23 19:23 +0100, Emilio Cobos Álvarez wrote:
> 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.

I should clarify that it isn't actually non-standard:  it was part
of DOM Level 2:
https://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration
but ended up never being widely implemented.  It's not a
particularly nice API, nor was it specified in a way that could lead
to interoperability, and its replacement is intended to be
https://drafts.css-houdini.org/css-typed-om/ .

I'm still in favor of removing it.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

[Jonathan Watt]

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] after they forked, but it's actually still
implemented in Webkit it seems. Hopefully we shouldn't have too many problems
removing it though.

Jonathan

1. https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/3VmxWFzcyJc
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform