Re: Coding style: brace initialization syntax

[gsquelart]

On Wednesday, June 6, 2018 at 5:35:59 AM UTC+10, Boris Zbarsky wrote:
> On 6/5/18 3:10 PM, Emilio Cobos Álvarez wrote:
> > I personally would prefer one space at each side when using braces:
> > 
> >   , mFoo { 0 }
> 
> I think the reason people tend to think of this as not wanting spaces is 
> that they are thinking of it as a constructor call.  The parentheses 
> syntax for initializer lists helps think of things that way, of course.
> [...]
> -Boris

I also prefer `m{ 0 }`.

`m(0)` (direct initialization) and `m{ 0 }` (list initialization) are really 
different operations, and may in fact call different constructors -- E.g., the 
latter will prefer constructors that take an std::initializer_list.
So I think it is important to emphasize the difference, especially for 
reviewers to be able to pick on that difference.

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

Re: OrangeFactor/Intermittent Failures View Update

[Robert O'Callahan]

Thank you very very much for making this information public again!

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Boris Zbarsky]

On 6/5/18 3:10 PM, Emilio Cobos Álvarez wrote:

I personally would prefer one space at each side when using braces:

  , mFoo { 0 }


I think the reason people tend to think of this as not wanting spaces is 
that they are thinking of it as a constructor call.  The parentheses 
syntax for initializer lists helps think of things that way, of course.


Though I really find no-spaces-around-braces harder to read, not only in 
constructors but in general initializer lists. For example, I find:


   return { Foo::Bar, bar, baz };

easier to read than:

   return {Foo::Bar, bar, baz};


Right, whereas this one feels more like a struct literal of some sort, 
where you do want the spaces delimiting things...


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

Re: Coding style: brace initialization syntax

[Emilio Cobos Álvarez]

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. was pragmatic as this is what we already do, 2. was for consistency with
1.


I personally would prefer one space at each side when using braces:

 , mFoo { 0 }

But people seemed to think that for consistency we should use no spaces 
with braces as well... So if more people agree with that, oh well :)


Though I really find no-spaces-around-braces harder to read, not only in 
constructors but in general initializer lists. For example, I find:


  return { Foo::Bar, bar, baz };

easier to read than:

  return {Foo::Bar, bar, baz};

(and also more consistent with what you write in Javascript or Rust).

But nor sure if this discussion would expand to those cases.

 -- Emilio



To answer Bogdan's question, it looks like we prefer [1], although it would
be nice to see that codified in our style doc.

jya, you make some interesting points, but we should keep the scope of this
discussion focused. You might want to raise them in separate threads --
"Should we recommend initialization at member declaration", "Should we
recommend where a ctor should is defined", etc.

-e


On Tue, Jun 5, 2018 at 5:50 AM, Jean-Yves Avenard 
wrote:





On 5 Jun 2018, at 12:54 pm, bposteln...@mozilla.com wrote:

I would like to resurrect this thread since it would help us a lot for

bug 1453795 to come up to a consensus on when to use bracelets and when to
use parenthesis. Also I must point out a thing here, that was also
mentioned here earlier, that there are situations where we cannot use
parenthesis. This is when we want to initialize a structure that doesn't
have a ctor, like:

[1]
struct str {
  int a;
  int b;
};

class Str {
  str s;
  int a;
public:
  Str() : s{0}, a(0) {}
};

Also it would help a lot if we would establish how many, spaces should

be between the parenthesis or the bracelets, like how do we prefer [1] or
[2]


[2]
class Str {
  str s;
  int a;
public:
  Str() : s{ 0 }, a( 0 ) {}
};

I don't have a personal preference here, but right now there are several

places in our code that combine spaces between parenthesis/bracelets with
no spaces.

The current coding style: https://developer.mozilla.org/
en-US/docs/Mozilla/Developer_guide/Coding_Style states to not use space.

There’s no case where a parenthesis should be followed by a space.

Many things wrong here:
First the bracket { should be on a new line :

class/struct str
{
…
}

Initialization are to be on multiple-lines.

clang-format would have made it:
   class Str
   {
 str s;
 int a;

   public:
 Str()
   : s{ 0 }
   , a(0)
 {
 }
   };

IMHO, should be going for C++11 initializer, it’s much clearer, and avoid
duplicated code when you need multiple constructors.
What is str? I assume not a plain object, so it should have its own
initializer.

so it all becomes:
   class Str
   {
 str s;
 int a = 0;

   public:
 Str() {}
   };

or:
   class Str
   {
 str s;
 int a = 0;

   public:
 Str() = default;
   };

(and I prefer constructors to be defined at the start of the class
definition)

My $0.02
___
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: Coding style: brace initialization syntax

[Eric Rahm]

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. was pragmatic as this is what we already do, 2. was for consistency with
1.

To answer Bogdan's question, it looks like we prefer [1], although it would
be nice to see that codified in our style doc.

jya, you make some interesting points, but we should keep the scope of this
discussion focused. You might want to raise them in separate threads --
"Should we recommend initialization at member declaration", "Should we
recommend where a ctor should is defined", etc.

-e


On Tue, Jun 5, 2018 at 5:50 AM, Jean-Yves Avenard 
wrote:

>
>
> > On 5 Jun 2018, at 12:54 pm, bposteln...@mozilla.com wrote:
> >
> > I would like to resurrect this thread since it would help us a lot for
> bug 1453795 to come up to a consensus on when to use bracelets and when to
> use parenthesis. Also I must point out a thing here, that was also
> mentioned here earlier, that there are situations where we cannot use
> parenthesis. This is when we want to initialize a structure that doesn't
> have a ctor, like:
> > [1]
> > struct str {
> >  int a;
> >  int b;
> > };
> >
> > class Str {
> >  str s;
> >  int a;
> > public:
> >  Str() : s{0}, a(0) {}
> > };
> >
> > Also it would help a lot if we would establish how many, spaces should
> be between the parenthesis or the bracelets, like how do we prefer [1] or
> [2]
> >
> > [2]
> > class Str {
> >  str s;
> >  int a;
> > public:
> >  Str() : s{ 0 }, a( 0 ) {}
> > };
> >
> > I don't have a personal preference here, but right now there are several
> places in our code that combine spaces between parenthesis/bracelets with
> no spaces.
>
> The current coding style: https://developer.mozilla.org/
> en-US/docs/Mozilla/Developer_guide/Coding_Style states to not use space.
>
> There’s no case where a parenthesis should be followed by a space.
>
> Many things wrong here:
> First the bracket { should be on a new line :
>
> class/struct str
> {
> …
> }
>
> Initialization are to be on multiple-lines.
>
> clang-format would have made it:
>   class Str
>   {
> str s;
> int a;
>
>   public:
> Str()
>   : s{ 0 }
>   , a(0)
> {
> }
>   };
>
> IMHO, should be going for C++11 initializer, it’s much clearer, and avoid
> duplicated code when you need multiple constructors.
> What is str? I assume not a plain object, so it should have its own
> initializer.
>
> so it all becomes:
>   class Str
>   {
> str s;
> int a = 0;
>
>   public:
> Str() {}
>   };
>
> or:
>   class Str
>   {
> str s;
> int a = 0;
>
>   public:
> Str() = default;
>   };
>
> (and I prefer constructors to be defined at the start of the class
> definition)
>
> My $0.02
> ___
> 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

Introducing #ci and the ciduty team

[Jordan Lund]

Hi all,

If you contribute to the development of Firefox, the changes outlined in
this post will impact you.

tl;dr - What’s changing:

   - Firefox continuous integration (firefox-ci) based discussions #releng,
   #buildduty, aed #taskcluster are being moved to the newly created #ci IRC
   channel
   - #releng and #buildduty will be closed over next 7 days and people will
  be directed over to #ci
  - #taskcluster will live on but be focused on the development of
  Taskcluster, the product itself
   - The buildduty team will now be known as ciduty
   - Firefox developers now have a 24/7 support team (ciduty) for reporting
   issues and enquiring about continuous integration infrastructure
   - ciduty will help track and publish changes across infrastructure. This
   will be used to correlate regressions or issues

See here for the motivation and details

of each of these bullet points.

For questions or concerns that weren't addressed in above motivation doc,
please add them to this Q doc

and we will make sure it gets a response.

CIDuty home page and official wiki 

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

OrangeFactor/Intermittent Failures View Update

[Sarah Clements]

Hi!

As of today, the OrangeFactor url is redirecting to Intermittent Failures
View  as part of
the decommission process. The API's that replace OrangeFactors API's are
Failures, FailuresByBug and FailureCount (you can find more info in the
Treeherder API docs ).

The Treeherder team will be dedicating more resources to improving
Intermittent Failures View, so please file any bugs or feature
requests for Intermittent
Failures View

rather than for OrangeFactor.

- Sarah
___
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 16 days

[Bogdan Maris]

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/ybeh964m
Bugs logged by Desktop Release QA in the last 16 days

Firefox: Theme:
NEW - https://bugzil.la/1463062 - Search bar - color adjustment inside the 
Overflow menu when in dark Theme
NEW - https://bugzil.la/1463720 - [Ubuntu] The fullscreen button from the zoom 
control bar is NOT visible in fullscreen mode when in dark theme

Firefox: New Tab Page:
NEW - https://bugzil.la/1463096 - [New tab page] Small thumbnail not updated in 
Top sites section

Firefox: Developer Tools:
NEW - https://bugzil.la/1463177 - Tab content fails to load if Developer 
toolbar and Inspector is opened

Firefox: Developer Tools: Object Inspector:
NEW - https://bugzil.la/1465456 - Inspector - highlight remains visible when 
element is deleted

Firefox: Developer Tools: Shared Components
NEW - https://bugzil.la/1465490 - [VirtualizedTree] Several elements are not 
displayed after vertically resizing the "Properties" panel

Firefox: Activity Streams: Newtab
NEW - https://bugzil.la/1463395 - The Privacy Notice is opened in the same tab 
when accessing the corresponding section context menu option
NEW - https://bugzil.la/1464349 - The highlight card description overlaps the 
default size of the cell

Firefox: Toolbars and Customization:
NEW - https://bugzil.la/1463708 - The theme list padding allows the current 
theme preview during hover in customize mode

Firefox: Menus:
NEW - https://bugzil.la/1465321 - Bookmark tooltip right border not displayed 
if name to long and space in front

Firefox: General:
NEW - https://bugzil.la/1465391 - User cannot log out of Pinterest on a 
specific platform and OS

Firefox: Bookmarks & History:
NEW - https://bugzil.la/1465777 - Bookmark context menu open from right-click 
on bottom of bookmark sidebaror library   

Core: Audio/Video: Playback:
NEW - https://bugzil.la/1465757 - Play button overlaps/greys out the clip 
suggestions on CNN

Core: Print Preview:
NEW - https://bugzil.la/1465774 - [Ubuntu] Distorted content while scrolling 
inside a Pdf file in Print Preview (Landscape mode only)

Core: DOM: Security
NEW - https://bugzil.la/1465017 - Safe Browsing - "See details" button not 
functioning

Core: Graphics:
NEW - https://bugzil.la/1463400 - Image flashes after browser resize

Tech Evangelism: Desktop:
NEW - https://bugzil.la/1463363 - Vimeo content disappears after opening a 
video in a new tab by middle clicking it 
NEW - https://bugzil.la/1463450 - Flicker when scrolling using up/down arrow 
keys

This is available as a Bugzilla bug list as well: https://tinyurl.com/y7cy3qgz

Regards,
Bogdan (:bogdan_maris)
Desktop Release QA

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

Re: Coding style: brace initialization syntax

[Jean-Yves Avenard]

> On 5 Jun 2018, at 12:54 pm, bposteln...@mozilla.com wrote:
> 
> I would like to resurrect this thread since it would help us a lot for bug 
> 1453795 to come up to a consensus on when to use bracelets and when to use 
> parenthesis. Also I must point out a thing here, that was also mentioned here 
> earlier, that there are situations where we cannot use parenthesis. This is 
> when we want to initialize a structure that doesn't have a ctor, like:
> [1]
> struct str {
>  int a;
>  int b;
> };
> 
> class Str {
>  str s;
>  int a;
> public:
>  Str() : s{0}, a(0) {}
> };
> 
> Also it would help a lot if we would establish how many, spaces should be 
> between the parenthesis or the bracelets, like how do we prefer [1] or [2]
> 
> [2]
> class Str {
>  str s;
>  int a;
> public:
>  Str() : s{ 0 }, a( 0 ) {}
> };
> 
> I don't have a personal preference here, but right now there are several 
> places in our code that combine spaces between parenthesis/bracelets with no 
> spaces.

The current coding style: 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style 
states to not use space.

There’s no case where a parenthesis should be followed by a space.

Many things wrong here:
First the bracket { should be on a new line :

class/struct str
{
…
}

Initialization are to be on multiple-lines.

clang-format would have made it:
  class Str
  {
str s;
int a;

  public:
Str()
  : s{ 0 }
  , a(0)
{
}
  };

IMHO, should be going for C++11 initializer, it’s much clearer, and avoid 
duplicated code when you need multiple constructors.
What is str? I assume not a plain object, so it should have its own initializer.

so it all becomes:
  class Str
  {
str s;
int a = 0;

  public:
Str() {}
  };

or:
  class Str
  {
str s;
int a = 0;

  public:
Str() = default;
  };

(and I prefer constructors to be defined at the start of the class definition)

My $0.02

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[bpostelnicu]

I would like to resurrect this thread since it would help us a lot for bug 
1453795 to come up to a consensus on when to use bracelets and when to use 
parenthesis. Also I must point out a thing here, that was also mentioned here 
earlier, that there are situations where we cannot use parenthesis. This is 
when we want to initialize a structure that doesn't have a ctor, like:
[1]
struct str {
  int a;
  int b;
};

class Str {
  str s;
  int a;
public:
  Str() : s{0}, a(0) {}
};

Also it would help a lot if we would establish how many, spaces should be 
between the parenthesis or the bracelets, like how do we prefer [1] or [2]

[2]
class Str {
  str s;
  int a;
public:
  Str() : s{ 0 }, a( 0 ) {}
};

I don't have a personal preference here, but right now there are several places 
in our code that combine spaces between parenthesis/bracelets with no spaces.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: New AltGr key behavior on Windows

[Masayuki Nakano]

Google suggested that browsers shouldn't set ctrlKey and altKey to true 
for keyboard events during AltGr key is pressed on Windows. We will 
follow the new behavior for compatibility with Chromium and better 
accessibility for some language users.

https://github.com/w3c/uievents/issues/147

Background: On Windows, AltGr key is mapped to AltRight key by some 
keyboard layouts. However, Windows represents AltGraph state with both 
Control and Alt modifier states.  For example, if user cannot use 
AltRight key (e.g., there is no AltRight key), user can emulate it with 
pressing both Ctrl and Alt keys.  Another example, when user presses 
AltGr key, ControlLeft keydown and AltRight keydown are fired, and when 
user releases it, CtrlLeft keyup and AltRight keyup are fired.


Firefox, Chrome and Edge set ctrlKey and altKey to true when 
getModifierState("AltGraph") returns true. However, web apps cannot 
distinguish whether given keydown event will input some characters 
strictly.  So, if both ctrlKey and altKey are set to false when user 
types some character(s) even with AltGr key, the keys won't be handled 
as shortcut key on the web apps.  The new behavior improves 
accessibility of users who use keyboard layout which has AltGr key, 
especially when they use different locale's web apps.


When user presses a key with AltGr key to input a character, Gecko has 
dispatched:


1. keydown for ControlLeft whose ctrlKey is true.
2. keydown for AltRight whose ctrlKey and altKey are true and 
getModifierState("AltGraph") returns true.
3. keydown for the key whose ctrlKey and altKey are true and 
getModifierState("AltGraph") returns true.
4. keypress for the key whose ctrlKey and altKey are *false* and 
getModifierState("AltGraph") returns true.
5. keyup for the key whose ctrlKey and altKey are true and 
getModifierState("AltGraph") returns true.

6. keyup for ControlLeft whose altKey is true.
7. keyup for AltRight (currently, this is not fired due regression of 
e10s )


This becomes:

1. keydown for ControlLeft whose ctrlKey is true.
2. keydown for AltRight whose ctrlKey and altKey are *false* and 
getModifierState("AltGraph") returns true.
3. keydown for the key whose ctrlKey and altKey are *false* and 
getModifierState("AltGraph") returns true.
4. keypress for the key whose ctrlKey and altKey are false and 
getModifierState("AltGraph") returns true.
5. keyup for the key whose ctrlKey and altKey are *false* and 
getModifierState("AltGraph") returns true.
6. keyup for ControlLeft whose altKey is *false* but 
getModifierState("AltGraph") returns *true*.

7. keyup for AltRight

Additionally, KeyboardEvent.key value for AltRight key becomes 
"AltGraph" instead of "Alt" (but KeyboardEvent.keyCode won't be changed 
for backward compatibility).


When user types a character with emulating AltGr with ControlLeft and 
AltLeft keys:


1. keydown for ControlLeft whose ctrlKey is true.
2. keydown for AltLeft whose ctrlKey and altKey are *true* and 
getModifierState("AltGraph") returns *false*.
3. keydown for the key whose ctrlKey and altKey are *false* and 
getModifierState("AltGraph") returns *true*.
4. keypress for the key whose ctrlKey and altKey are false and 
getModifierState("AltGraph") returns true.
5. keyup for the key whose ctrlKey and altKey are *false* and 
getModifierState("AltGraph") returns true.
6. keyup for ControlLeft whose altKey is *true* and also 
getModifierState("AltGraph") returns *false*.

7. keyup for AltRight

If the key produces no character when emulating AltGr key press with 
Ctrl and Alt keys, its keydown and keyup event's ctrlKey and altKey are 
set to *true* and getModifierState("AltGraph") returns false.


In other words, if user emulates AltGr key, only printable key's events 
are changed.  So, when a key does not input any characters with AltGraph 
state, the key combinations can be handled as shortcut keys. Although 
any web apps and extensions shouldn't use Control - Alt combination for 
shortcut keys at least on Windows.


Note that if active keyboard layout does not have AltGr key, 
getModifierState("AltGraph") always returns false (even if both Ctrl and 
Alt are pressed).


The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=900750
Target: Firefox 62 or 63.

Chrome has started to release new behavior with 67. And starting from 
68, they will switch this behavior permanently.


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