Re: Where to put timeout test?

2019-03-05 Thread Cameron McCormack
On Wed, Mar 6, 2019, at 5:05 PM, violet.bugrep...@gmail.com wrote:
> However, both the reviewer and me don't know how to put a timeout test. 
> It won't crash in any case, so it's not a crash test. But the mochitest 
> can only be used to check JavaScript assertion, if I use mochitest, the 
> test utility will hang waiting for JavaScript stuff, then eventually 
> timeout because there is nothing to assert.
> 
> Where to put a testcase like this?

You can use a crashtest for this under layout/svg/crashtests/.  crashtests are 
like reftests that don't actually check against a reference, but will just fail 
if the test crashes, or causes some assertions, or times out.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Help Wanted: Looking for policies related to Firefox development

2019-03-05 Thread glob
The Engineering Workflow team is focused on improving the Firefox 
development processes. Many of the decisions are driven directly by 
established policies.


Finding clearly documented policies has proven to be a challenge - 
policies are stored across multiple systems making them difficult find, 
are clearly out of date, or simply don’t exist.


I’m working on creating a single catalogue which points to existing 
documentation (obsolete or not), and I’d like your help in finding 
documentation relating to Firefox development.


This should help us identify and reduce:

- “Mozilla Folklore” - where work is performed in a particular way 
however nothing is written down solidifying the practice.  This is 
problematic for tooling as quite often there are slight variations 
between teams in how these practices are followed.  One example that I’m 
trying to track down is “mozilla-central should be commit-level bisectable”.


- Out of date documentation - a central catalogue simplifies locating 
documentation that needs to be updated or removed as our policies 
change.  For example the Super Review Policy is still live, and contains 
a list of super-reviewers that appears to be 8+ years out of date.


For now I’ve created a Google document at 
https://docs.google.com/document/d/1MUNJXL360V62FiWYVLr2b8Spt6I4jIOGjGkI7Agwxt4 
as a collection point; please add your comments there or reply to this 
thread with pointers to documentation or to highlight “Mozilla Folklore” 
that you feel should be written down.


The contents will be moved to a more suitable home once the initial 
gathering phase is completed.


Thanks!
-glob


--
glob — engineering workflow — moz://a

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


Where to put timeout test?

2019-03-05 Thread violet . bugreport
Hi,

When fixing [this](https://phabricator.services.mozilla.com/D20947) bug, I need 
to add a test. If the patch is not applied, the test will spend almost infinite 
time to render a SVG; while if the patch is applied, it can be rendered 
instantly.

However, both the reviewer and me don't know how to put a timeout test. It 
won't crash in any case, so it's not a crash test. But the mochitest can only 
be used to check JavaScript assertion, if I use mochitest, the test utility 
will hang waiting for JavaScript stuff, then eventually timeout because there 
is nothing to assert.

Where to put a testcase like this?

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


Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

2019-03-05 Thread dmu
On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> To add to Dan's comments here...
> 
> Assuming that I'm reading this correctly [1], the fingerprinting risks are
> pretty extreme here.  In the touch spec, we have a monotonically increasing
> counter that doesn't appear to be origin-bound in any way.  What is the
> purpose of this identifier?  In the light spec, we have full RGB control
> over the light.  Does the light change back to a default state when the
> origin is no longer the primary input focus?
> 
> Implementing specs of a private GitHub account is fine for the purposes of
> getting feedback, but I think that we want a clearer signal that this is an
> accepted approach before we ship something like this.  When you consider
> the potential for security and privacy implications, this is particularly
> important.
> 
> 

Hi Martin,

Sorry for reply late. 
We will restrict theses APIs to secure contexts to help it be more secure. 
Regarding to the touchId, the reason we wanna make it monotonically increasing 
is order to recognize if fingers have been released after the last touch. Let 
me give you two examples.
 
Example 1: Let’s say touchId is currently set to 0 and no fingers are touching 
the touchpad.  When a finger touches the touchpad, touchId of this event would 
be 1.  As that finger moves around the touchpad, new touch events are added 
with updated coordinates, however, the touchId is still 1 to denote that the 
finger has not been lifted from the touchpad.  If the finger is released and 
touches again, the touchId would then be 2.

Example 2: In the case of multi touch, the first finger that touches the 
touchpad would have a touchId of 1.  The next finger that touches the touchpad 
before the first finger is released would have a touchId of 2.  If the first 
touch finger is released and touches again, that touchId would be 3.  This way, 
the application can distinguish between different touches that have or haven’t 
been removed from the touchpad.

In terms of lightColor,  we would give the default color to [0, 0, 0] if there 
is no one set it yet or when it is just plugged in. Then, the application is 
allowed to set the controller's lightbar color whenever they want. I have 
reached the author and ask him add this description into his proposal.
 

Cheers,
Daosheng Mu


> 
> On Tue, Feb 26, 2019 at 11:08 AM Daosheng Mu  wrote:
> 
> > Hi Daniel,
> >
> > We didn't have a chance to discuss privacy issues in Gamepad Extension or
> > Gamepad API. We were trying to get responses for the Privacy review [1] but
> > without any updates yet.
> >
> > Cheers,
> >
> > [1]
> > https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0030.html
> >
> > --
> > Daosheng Mu
> > Software Engineer | Mozilla
> > d...@mozilla.com
> >
> >
> > On Mon, Feb 25, 2019 at 2:47 PM Daniel Veditz  wrote:
> >
> > > Neither of the words "security" or "privacy" appear in this spec (most w3
> > > web specs have at least a token attempt at a "Privacy and Security
> > > Considerations" section). At a surface glance this appears to add
> > > additional fingerprinting exposure. Have you talked to the privacy team
> > > about ways to minimize this?
> > >
> > > -Dan Veditz
> > >
> > > On Mon, Feb 25, 2019 at 11:45 AM Daosheng Mu  wrote:
> > >
> > >> Summary:
> > >> In order to support controllers which have multi touch and light bar
> > >> features like Sony DualShock 4. The `*multi touch*` and `*light
> > >> indicator*`
> > >> APIs for gamepad extensions are the things we must have. In
> > >> `*GamepadTouch*`
> > >> API, it would make us know touch surface's dimension and its unique id.
> > We
> > >> also will have a way to know where is the place we are touching
> > according
> > >> to its position and the unique id. Regarding to
> > `*GamepadLightIndicator*`,
> > >> it could tell users the color of controller's light bar. The color is a
> > >> 8-bit size integer for defining `*red*`, `*green*`, `*blue*`, or other
> > >> colors to indicate the on-off light indicator is ON.
> > >>
> > >> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523350
> > >>
> > >> Link to standard:
> > >> W3C Multi touch spec proposal:
> > >> https://github.com/knyg/gamepad/blob/multitouch/extensions.html
> > >> W3C Light indicator spec proposal:
> > >> https://github.com/knyg/gamepad/blob/lightindicator/extensions.html
> > >>
> > >> Platform coverage: Windows, Mac OS, Linux
> > >>
> > >> Estimated or target release: Firefox 68
> > >>
> > >> Preference behind which this will be implemented:
> > >> "dom.gamepad.extensions.multitouch" and
> > >> "dom.gamepad.extensions.lightindicator"
> > >>
> > >> Do other browser engines implement this? Nope
> > >>
> > >> web-platform-tests: none exist (and I don't plan to write WPTs but we do
> > >> have gamepad mochitest, I will add new tests to cover these two new
> > APIs.)
> > >>
> > >> Is this feature restricted to secure contexts? Nope
> > >>
> > >> How stable is the spec? This