RE: Running mochitest on packaged builds with the sandbox

[Kearwood Kip Gilbert]

Hi all,

The VR team is working on a Steam packaged browser with a VR specific UI and 
richer VR experience.  In order to prevent the overhead of having the VR 
specific assets included in every Firefox build while still running on tested 
executables, we will be doing a repack build.

WebVR will still continue to be supported in the regular Firefox builds; API 
surface area is the same in normal desktop builds.  Mochitests validating these 
API calls should be unaffected.

We will need a means for testing the VR frontend and assets that are added with 
the re-pack.  Ideally, we could use the existing test mechanisms, including 
mochitests.

Perhaps we could disable the sandbox for these front-end tests?

The Steam packaged builds will also need slightly expanded access to resources 
such as files, registry, and pipes required for communication with Steam.

Are there any plans to make the sandboxing rules configurable at runtime?

Cheers,
- Kearwood “Kip” Gilbert


From: Alex Gaynor
Sent: May 8, 2017 10:26 AM
To: dev-platform@lists.mozilla.org
Subject: Running mochitest on packaged builds with the sandbox

Hi dev-platform,

Top-line question: Do you rely on being able to run mochitests from a
packaged build (`--appname`)?

Context:

The sandboxing team has been hard at work making the content process
sandbox as restrictive as possible. Our latest focus is  removing file read
permissions from content processes -- the sandbox's value is pretty limited
if a compromised content process can ship all your files off by itself!

One of the things we've discovered in the process of developing these
patches is that they break running mochitest on packaged firefox builds
(this is the `--appname` flag to mochitest)! `try` doesn't appear to use
this, and none of us use it in our development workflows, but we wanted to
check in with dev-platform and see if we were going to be breaking people's
development flows! While these restrictions are not on by default yet, once
they are you'd only be able to run tests on packaged builds by disabling
the sandbox. If this is a fundamental part of lots of folks' workflows
we'll dig into whether there's a way to keep this working.

Happy Monday!
Alex
___
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

Running mochitest on packaged builds with the sandbox

[Alex Gaynor]

Hi dev-platform,

Top-line question: Do you rely on being able to run mochitests from a
packaged build (`--appname`)?

Context:

The sandboxing team has been hard at work making the content process
sandbox as restrictive as possible. Our latest focus is  removing file read
permissions from content processes -- the sandbox's value is pretty limited
if a compromised content process can ship all your files off by itself!

One of the things we've discovered in the process of developing these
patches is that they break running mochitest on packaged firefox builds
(this is the `--appname` flag to mochitest)! `try` doesn't appear to use
this, and none of us use it in our development workflows, but we wanted to
check in with dev-platform and see if we were going to be breaking people's
development flows! While these restrictions are not on by default yet, once
they are you'd only be able to run tests on packaged builds by disabling
the sandbox. If this is a fundamental part of lots of folks' workflows
we'll dig into whether there's a way to keep this working.

Happy Monday!
Alex
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mixing nsresult and Result code

[Michael Layzell]

I also don't like the NS_TRY name, it seems too close to MOZ_TRY. I would
prefer to avoid names which are identical except s/NS/MOZ/.

Perhaps NSRESULT_TRY would be a better name? It makes it clear that it is
performing the try against the nsresult type.

On Mon, May 8, 2017 at 10:17 AM, Ehsan Akhgari 
wrote:

> I think these seem like valuable additions to nscore.h.  It would be
> helpful to extend these facilities that would allow more code to use the
> Result-based programming model.
>
> (I'm not too much of a fan of the NS_TRY name, but can't think of a better
> name myself... :/ )
>
>
>
> On 05/07/2017 03:34 PM, Kris Maglione wrote:
>
>> I've been trying to write most of my new code to use Result.h as much as
>> possible. When I have to mix Result-based code with nsresult-based code,
>> though, things tend to get ugly, and I wind up writing helpers. At this
>> point I've wound up writing the same helpers in 3 or 4 different places, so
>> it may be time to try to standardize on something.
>>
>> The helpers I've been using look something like:
>>
>>  template <>
>>  class MOZ_MUST_USE_TYPE GenericErrorResult
>>  {
>>nsresult mErrorValue;
>>
>>template friend class Result;
>>
>>  public:
>>explicit GenericErrorResult(nsresult aErrorValue) :
>> mErrorValue(aErrorValue) {}
>>
>>operator nsresult() { return mErrorValue; }
>>  };
>>
>>  static inline Result
>>  WrapNSResult(PRStatus aRv)
>>  {
>>  if (aRv != PR_SUCCESS) {
>>  return Err(NS_ERROR_FAILURE);
>>  }
>>  return Ok();
>>  }
>>
>>  static inline Result
>>  WrapNSResult(nsresult aRv)
>>  {
>>  if (NS_FAILED(aRv)) {
>>  return Err(aRv);
>>  }
>>  return Ok();
>>  }
>>
>>  #define NS_TRY(expr) MOZ_TRY(WrapNSResult(expr))
>>
>> And their use looks something like:
>>
>>  Result
>>  GetFile(nsIFile* aBase, const char* aChild)
>>  {
>>nsCOMPtr file;
>>NS_TRY(aBase->Clone(getter_AddRefs(file)));
>>NS_TRY(aBase->AppendNative(aChild));
>>
>>return Move(file);
>>  }
>>
>>  nsresult
>>  ReadFile(const char* aPath)
>>  {
>>nsCOMPtr file;
>>MOZ_TRY_VAR(file, GetFile(mBase, aPath));
>>
>>PRFileDesc* fd;
>>NS_TRY(file->OpenNSPRFileDesc(PR_RDONLY, 0, ));
>>
>>...
>>return NS_OK;
>>  }
>>
>> Where NS_TRY converts a nsresult or PRStatus to an appropriate Result or
>> GenericErrorResult, and the GenericErrorResult specialization
>> automatically converts an nsresult when used in nsresult-based code.
>>
>> Does this seem like the kind of thing we should implement in some
>> standard header, or would a different approach be better?
>>
>> -Kris
>> ___
>> 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: Notification() deprecation question

[Anne van Kesteren]

On Mon, May 8, 2017 at 4:24 PM, Ehsan Akhgari  wrote:
> AFAIK this was discussed at the spec level in
> https://github.com/whatwg/notifications/issues/26 and the conclusion was to
> *not* deprecate the construcutor for the non-persistent notifications.
> Perhaps something has changed afterwards?

I think Chrome isn't super interested in non-persistent notifications,
basically. We don't really have an owner for the Notifications API on
the engineering/UX side to drive discussion surrounding the standard.


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

Re: Notification() deprecation question

[Ehsan Akhgari]

AFAIK this was discussed at the spec level in 
https://github.com/whatwg/notifications/issues/26 and the conclusion was 
to *not* deprecate the construcutor for the non-persistent 
notifications.  Perhaps something has changed afterwards?



On 05/08/2017 03:09 AM, Chris Mills wrote:

Hi there,

I found this thread recently:

https://bugs.chromium.org/p/chromium/issues/detail?id=481856

Are we following the same path to deprecating Notification() and insisting 
people use ServiceWorkerRegistration.showNotification() instead in Gecko, or is 
this just a Google thing for now?

In any case, we’ve got some documentation updates to do on MDN — I just wanted 
to check exactly what the deal is.

Thanks,

Chris Mills
  MDN content lead || Mozilla
developer.mozilla.org || MDN
cmi...@mozilla.com || @chrisdavidmills

___
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: Mixing nsresult and Result code

[Ehsan Akhgari]

I think these seem like valuable additions to nscore.h.  It would be 
helpful to extend these facilities that would allow more code to use the 
Result-based programming model.


(I'm not too much of a fan of the NS_TRY name, but can't think of a 
better name myself... :/ )



On 05/07/2017 03:34 PM, Kris Maglione wrote:
I've been trying to write most of my new code to use Result.h as much 
as possible. When I have to mix Result-based code with nsresult-based 
code, though, things tend to get ugly, and I wind up writing helpers. 
At this point I've wound up writing the same helpers in 3 or 4 
different places, so it may be time to try to standardize on something.


The helpers I've been using look something like:

 template <>
 class MOZ_MUST_USE_TYPE GenericErrorResult
 {
   nsresult mErrorValue;

   template friend class Result;

 public:
   explicit GenericErrorResult(nsresult aErrorValue) : 
mErrorValue(aErrorValue) {}


   operator nsresult() { return mErrorValue; }
 };

 static inline Result
 WrapNSResult(PRStatus aRv)
 {
 if (aRv != PR_SUCCESS) {
 return Err(NS_ERROR_FAILURE);
 }
 return Ok();
 }

 static inline Result
 WrapNSResult(nsresult aRv)
 {
 if (NS_FAILED(aRv)) {
 return Err(aRv);
 }
 return Ok();
 }

 #define NS_TRY(expr) MOZ_TRY(WrapNSResult(expr))

And their use looks something like:

 Result
 GetFile(nsIFile* aBase, const char* aChild)
 {
   nsCOMPtr file;
   NS_TRY(aBase->Clone(getter_AddRefs(file)));
   NS_TRY(aBase->AppendNative(aChild));

   return Move(file);
 }

 nsresult
 ReadFile(const char* aPath)
 {
   nsCOMPtr file;
   MOZ_TRY_VAR(file, GetFile(mBase, aPath));

   PRFileDesc* fd;
   NS_TRY(file->OpenNSPRFileDesc(PR_RDONLY, 0, ));

   ...
   return NS_OK;
 }

Where NS_TRY converts a nsresult or PRStatus to an appropriate Result 
or GenericErrorResult, and the GenericErrorResult 
specialization automatically converts an nsresult when used in 
nsresult-based code.


Does this seem like the kind of thing we should implement in some 
standard header, or would a different approach be better?


-Kris
___
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: Re: CodeCoverage Monthly Update

[Marco Castelluccio]

No, currently not, but we can build one ourselves using their API (which 
we might to do with codecov.io anyway, since we expect to have custom 
needs).


- Marco.


Il 04/05/17 08:22, Chris Peterson ha scritto:

On 2017-05-03 8:44 PM, Kyle Lahnakoski wrote:

  * Daily coverage reports on coveralls.io [1] and on codecov.io[2].
Which do you like?


Does coveralls.io have a top-down coverage view like codecov.io? That 
view seems more useful for both people that want a global view and 
developers that want to drill down into just their component directories.




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

[Firefox Desktop] Issues found: May 1st to May 5th

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *May 1 - May 5* (week 18).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL*

ID  Summary Product Component   Is a regression 
Assigned to
1361288 
	The Advanced button from the "Unable to Connect Securely" neterror page 
is not working

Firefox
Security
	YES 
 
	Masatoshi Kimura 

2818 
Downloaded Screenshot leaks from Private Browsing to Normal Browsing
Firefox
Screenshots
NO  NOBODY


*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1361758  	[W8.1] White artifacts on left and 
right extremities of Fx when switching between low and high resolution 
screens

Core
Widget: Win32
	YES 
 
	NOBODY

1362378 
[e10s] Web content fails to load after reloading all tabs
Core
Layout
	YES 
 
	NOBODY


*

ESR CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1362380 
The Home page is scrolled to the top when opening a photo on LinkedIn
CoreLayout  TBD NOBODY



Regards,
Cornel Ionce
Team Lead
Softvision

The content of this communication is classified as Softvision 
Confidential and Proprietary Information.


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

Notification() deprecation question

[Chris Mills]

Hi there,

I found this thread recently:

https://bugs.chromium.org/p/chromium/issues/detail?id=481856

Are we following the same path to deprecating Notification() and insisting 
people use ServiceWorkerRegistration.showNotification() instead in Gecko, or is 
this just a Google thing for now? 

In any case, we’ve got some documentation updates to do on MDN — I just wanted 
to check exactly what the deal is.

Thanks,

Chris Mills
 MDN content lead || Mozilla
developer.mozilla.org || MDN
   cmi...@mozilla.com || @chrisdavidmills

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