New [must_use] property in XPIDL

2016-08-21 Thread Nicholas Nethercote 
Greetings,

I just added [1] a new property to XPIDL called [must_use].

When used with an IDL method, it will add MOZ_MUST_USE to the generated C++
declarations and macros relating to that method. Here is an example:

  /* [must_use] void init (in nsIFile file); */
  MOZ_MUST_USE NS_IMETHOD Init(nsIFile *file) = 0;

When used with an IDL attribute, it will add MOZ_MUST_USE to the generated C++
getter and setter declarations and macros for that attribute. Here is a
getter-only example:

  /* [must_use] readonly attribute nsIAsyncInputStream inputStream; */
  MOZ_MUST_USE NS_IMETHOD GetInputStream(nsIAsyncInputStream * *aInputStream) =
0;

Any method or attribute that is fallible and should usually/always have its
result checked should use this property. For example, I am working on
adding [must_use] to nsIFile.idl [2], and most of the methods and attributes in
that file should use this property. (But not all of them; the remove() method
is an example where not checking is common and reasonable, because it's usually
the last thing done on a file.)

I'm only part way through nsIFile.idl and I have already found dozens and
dozens of missing checks. Many of these missing checks constitute bugs, and the
effects depend on the call site. I am certain that the story will be similar
for other IDL files. Therefore, I strongly encourage people to do likewise on
any IDL files with which they are familiar. Adding appropriate checks isn't
always easy, so it's nice if it can be done by people familiar with the code in
question.

More generally, we stand to benefit from wider use of MOZ_MUST_USE in normal
C++ code, too. Any function that returns an error indicator (usually nsresult
or bool) is a good candidate. Past experience has shown that the use of
MOZ_MUST_USE frequently turns up missing checks.

If you file a bug to add [must_use] or MOZ_MUST_USE somewhere, please make the
bug block the tracking bug [3].

I'm happy to answer any questions people might have about this topic.

Nick

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1295825
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1296164
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=MOZ_MUST_USE
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: transitionstart event

2016-08-21 Thread Brian Birtles 

On 2016/08/22 8:18, Mantaroh Yoshinaga wrote:

Although this event is only defined in a very early editor's draft of
CSS Transitions Level 2 (Level 1 is still a working draft) this event
has already shipped in Edge[1].


Unfortunately, it appears the spec behavior does not agree with the Edge 
behavior[1] so we'll need to resolve that first.


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

Re: Keyboard scan codes on Linux

2016-08-21 Thread Karl Tomlinson 
On Fri, 19 Aug 2016 17:05:30 -0400, Eric Shepherd wrote:

> I'm trying to update the table of scan codes and the keys they go with here:
>
> https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/code#Code_values_on_Linux_(X11)_(When_scancode_is_available)
>
> But the values in that table for the hardware keycodes seem to have no
> relation whatsoever to any of the published tables of hardware key
> values I can find anywhere. Is that table completely wrong, or for a
> version of Linux that no longer exists? :)

I suspect the CODE_MAP_X11 native values derive from
https://cgit.freedesktop.org/xkeyboard-config/tree/keycodes/evdev

I don't know however whether there is much value in publishing
these values.  I guess someone could run xev to get the values,
but javascript to display the .code value would provide the more
direct answer. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: transitionstart event

2016-08-21 Thread Mantaroh Yoshinaga 

Summary:
CSS Transitions Level 1 defines the transitionend event but provides no  
means for detecting when a new transition is triggered (unlike CSS  
Animations which defines an animationstart event). As a result, after  
applying changes to content (e.g. adding a new class), authors don't  
know if it is necessary to wait for transitionend event or not--a  
problem we ourselves sometimes encountered developing apps for Firefox OS.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1287983

Link to standard:
https://drafts.csswg.org/css-transitions-2/#eventdef-transitionevent-transitionstart

Although this event is only defined in a very early editor's draft of  
CSS Transitions Level 2 (Level 1 is still a working draft) this event  
has already shipped in Edge[1]. A bug is on file to implement in Blink  
but has no commitment to implement yet (other than recently being added  
to Hotlist-Squash-A-Bug).[2]


[1] https://msdn.microsoft.com/library/dn632683(v=vs.85).aspx
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=439056

Platform coverage: all platforms.

Estimated or target release: 51

Preference behind which this will be implemented: Not needed.

DevTools bug: Not needed?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust 1.10 (to be) required to build Firefox with --enable-rust

2016-08-21 Thread Nicholas Nethercote 
On Sun, Aug 21, 2016 at 2:30 AM, Philip Chee  wrote:
>
>> We'll offer a standalone file that can be executed to install the
>> development environment.
>
> Isn't MozillaBuild "a standalone file that can be executed to install
> the development environment."

MozillaBuild unzips into lots of files and programs. It's a whole
programming environment.

AIUI, gps is referring to something more like a single script. I.e.
basically just run "mach bootstrap" and everything is done for you, as
is the case on Mac and Linux.

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