Intent to ship: setting keyCode value of punctuation keys (if US keyboard layout) to non-zero

[Masayuki Nakano]

Gecko's KeyboardEvent.keyCode value for each printable key is mapped 
from an ASCII character which is produced by the key with active 
keyboard layout or alternative ASCII capable keyboard layout if active 
keyboard layout is not ASCII capable. However, we decided not to use 
ASCII punctuation character of alternative ASCII capable keyboard layout 
when we compute keyCode value of punctuation keys ("Backquote", "Equal", 
"Minus", "LeftBracket", "RightBracket", "Semicolon", "Quote", "Comma", 
"Period", "Slash", "Backslash", "IntlBackslash", "IntlYen" and "IntlRo" 
keys of KeyboardEvent.code) since we tried to avoid mapping same keyCode 
value to 2 or more keys.


However, a lot of web applications still use KeyboardEvent.keyCode even 
in these days and they can support only their main target's keyboard 
layout.  Therefore, if users whose active keyboard layout produces only 
Unicode character with punctuation keys like Russian, such keys are not 
available on web applications which supports only ASCII capable keyboard 
layout (i.e., such users need to switch active keyboard layout to 
alternative ASCII capable keyboard layout only while they want to use 
keyboard on such web applications).


For making this issue a little better, Firefox 60 will set such keys' 
keyCode value to same keyCode value as alternative ASCII capable 
keyboard layout only when Firefox 59 and earlier set the value to 0.


So, please not that this behavior change does NOT try to solve 
compatibility with the other browsers because it's impossible without 
breaking compatibility with Firefox-aware web applications. This change 
tries to improve compatibility with web applications which supports 
Firefox but assumes users use ASCII capable keyboard layout.


If web applications hit this issue, they should use KeyboardEvent.code 
in most cases because they don't check each keyboard layout's key 
meaning actually.


The bug to change this behavior:
https://bugzilla.mozilla.org/show_bug.cgi?id=1036008

Document in MSDN:
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode#keyCode_of_punctuation_keys_on_some_keyboard_layout

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship experimental Mixed Content upgrading (Nightly only)

[Jonathan Kingston]

We are experimenting with ways to eliminate insecure content on secure
pages, while increasing HTTPS adoption. With bug 1435733
, we are adding an
experimental pref to upgrade all mixed passive content. The pref is enabled
in Nightly-only by default.

Mixed passive content[1] currently gets loaded in HTTPS pages with a
degraded security UI - a grey padlock with a yellow triangle over it. With
this change, we will upgrade HTTP mixed passive content (images and media)
to HTTPS on secure pages. If the resource doesn’t exist over HTTPS, it will
fail to load. The security UI will show the green lock, since no insecure
content was loaded on the page.

The categorization of mixed passive content we are using is the same as the
one defined in the  Mixed Content Specification[2]. For example srcset and
 won’t be upgraded.

Chrome is currently also working to experiment in this area as a plan for a
new version of the Mixed Content Specification[3].

The preference to disable this is:
"security.mixed_content.upgrade_display_content" which will be enabled in
Nighty by default for two weeks. The code will remain in Firefox.

Developers and Nightly users can see which content is upgraded in the
developer console[4].

We would love to hear feedback and receive breakage reports.  Please file
bugs here
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=DOM%3A%20Security


[1] https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content

[2] https://w3c.github.io/webappsec-mixed-content/

[3]
https://github.com/mikewest/webappsec-mixed-content/blob/master/proposed-level-2-roadmap.md

[4] https://imgur.com/Ig5QttW
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Emilio Cobos Álvarez]

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/6648240

Is ::-moz-math-anonymous special? (last of its kind?) Or would the
same reasoning apply to removing access to ::-moz-math-stretchy or any
of the others in that list? Or is that just an out-of-date list that
we can ignore?


Looks out of date to me. ::-moz-math-stretchy was removed four years ago
in https://bugzilla.mozilla.org/show_bug.cgi?id=1000879.


Hi Emilio,

IIRC, ::-moz-math-stretchy was the only MathML pseudo element that was
publicly documented but it's no longer needed now that people can just
use font-family and/or the font preference menu to select a math font.
It should be safe to stop exposing -moz-math-anonymous and
-moz-mathml-anonymous-block, if we do.


Thanks for confirming that Fred!

Just for the record, ::-moz-mathml-anonymous-block is already not 
exposed, since it's an anonymous box. This looks to be the case since 
https://bugzilla.mozilla.org/show_bug.cgi?id=377824.


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

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

[Frédéric Wang]

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/6648240
>>
>> Is ::-moz-math-anonymous special? (last of its kind?) Or would the
>> same reasoning apply to removing access to ::-moz-math-stretchy or any
>> of the others in that list? Or is that just an out-of-date list that
>> we can ignore?
> 
> Looks out of date to me. ::-moz-math-stretchy was removed four years ago
> in https://bugzilla.mozilla.org/show_bug.cgi?id=1000879.

Hi Emilio,

IIRC, ::-moz-math-stretchy was the only MathML pseudo element that was
publicly documented but it's no longer needed now that people can just
use font-family and/or the font preference menu to select a math font.
It should be safe to stop exposing -moz-math-anonymous and
-moz-mathml-anonymous-block, if we do.

-- 
Frédéric Wang - frederic-wang.fr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Emilio Cobos Álvarez]

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/6648240

Is ::-moz-math-anonymous special? (last of its kind?) Or would the
same reasoning apply to removing access to ::-moz-math-stretchy or any
of the others in that list? Or is that just an out-of-date list that
we can ignore?


Looks out of date to me. ::-moz-math-stretchy was removed four years ago 
in https://bugzilla.mozilla.org/show_bug.cgi?id=1000879.



Thanks,

Tantek

P.S. I also found moz-math-anonymous on
http://mdn.beonex.com/en/CSS_Reference/Mozilla_Extensions.html#Pseudo-elements_and_pseudo-classes
but that seems to just be an out-of-date copy of
https://developer.mozilla.org/en-US/docs/Web/CSS/Mozilla_Extensions#Pseudo-elements_and_pseudo-classes
which already removed the -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 inheriting from another one for some
MathML characters, so it has no good reason to be exposed to the web at all.

I'm not aware of anything or anyone using it apart from us.

  -- Emilio
___
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


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

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

[Tantek Çelik]

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/6648240

Is ::-moz-math-anonymous special? (last of its kind?) Or would the
same reasoning apply to removing access to ::-moz-math-stretchy or any
of the others in that list? Or is that just an out-of-date list that
we can ignore?

Thanks,

Tantek

P.S. I also found moz-math-anonymous on
http://mdn.beonex.com/en/CSS_Reference/Mozilla_Extensions.html#Pseudo-elements_and_pseudo-classes
but that seems to just be an out-of-date copy of
https://developer.mozilla.org/en-US/docs/Web/CSS/Mozilla_Extensions#Pseudo-elements_and_pseudo-classes
which already removed the -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 inheriting from another one for some
> MathML characters, so it has no good reason to be exposed to the web at all.
>
> I'm not aware of anything or anyone using it apart from us.
>
>  -- Emilio
> ___
> 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

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

[Emilio Cobos Álvarez]

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 exposed 
to the web at all.


I'm not aware of anything or anyone using it apart from us.

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

Re: Treeherder New Login Flow

[emorley]

The switch from `full-user-credentials` to `taskcluster-credentials` has now 
occurred, meaning users will see a one-off Auth0 scopes prompt for the new 
permissions next time they log into Treeherder.

The cause of the frequent log-outs is also believed to be fixed - please 
comment on bug 1437824 if experiencing otherwise. (Sessions will be maintained 
as long as the site has been visited once every 24 hours; bug 1439858 is filed 
for seeing if that can be raised to extend over weekends etc)

Best wishes,

Ed

On Friday, 9 February 2018 17:30:26 UTC, ha...@mozilla.com  wrote:
> Hi,
> 
> I am writing to inform you about Treeherder’s new login flow.  In the past, 
> logging in with Treeherder meant being redirected to the 
> login.taskcluster.net service. This had a couple of drawbacks, but one of the 
> main annoyance was that credentials expired every 3 days. You are probably 
> already familiar with the following error: "Your credentials are expired. 
> They must expire every 3 days (Bug 1328434). Log out and back in again to 
> refresh your credentials."
> 
> The new login flow now uses Auth0 instead of login.taskcluster.net for SSO. 
> Some relevant information to note:
> 
> - When you login for the first time, you will get a prompt asking permission 
> for treeherder.mozilla.org to access “full-user-credentials”. It’s not 
> something to be worried about. This is simply a request to access your 
> taskcluster credentials. Bug 1437116 was created to change that to 
> "taskcluster-credentials”.
> 
> - Treeherder session will stay alive as long as access to the site happens 
> once every 24 hours. 3 days session expiry is no longer in effect.
> 
> - If an email is associated with multiple login providers, then the most 
> secure login method should be used (LDAP > GitHub 2FA > GitHub > Google > 
> Passwordless).
> 
> Thanks,
> Hassan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform