Re: QA Firefox 60 feature testing pi-requests deadline is January 10

[Tom Grabowski]

Hi,

Just a reminder that the deadline for submitting your PI-requests for Fx60
feature testing is today.

Thanks,
Tom


On Mon, Jan 8, 2018 at 12:30 PM, Tom Grabowski 
wrote:

>
> Hi,
>
> Similar to what QA did for Fx59 feature testing prioritization
> ,
> we would like to do the same for Fx60. In order to help with the process, 
> *please
> submit your pi-request
>  by Jan 10. *This is
> needed to assure QA will be involved in your feature development work for
> the next Nightly 60 cycle.
>
>
> *Q: What happens after the deadline?*
> A: After the deadline QA will come back with a prioritized list of work
> that represents what we are committing to for the next cycle. We want to
> ensure this list matches eng and product expectations.
>
> *Q: What if I miss the deadline?*
> A: We reserve the right to say that we can't pick up work for late
> requests in the current cycle. You can still develop and execute your own
> test plan or defer the work to the following cycle.
>
> *Q: What about unknown or unexpected requests? What if there is a business
> reason for a late request? What do we do with experiments and System
> Add-ons?*
> A: In order to remain flexible, we will keep some percentage of time open
> for requests like these.
>
> *Q: There's no way I'm going to remember to do this. *
> A: Do it now! I'll also send out a reminder next week.
>
> Thanks,
> Tom
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[cwiemeersch]

Exciting to hear, Kyle!

As mentioned earlier, Chrome for Android M63+ has shipped an implementation 
(disabled by default, with an Origin Trial) of the Generic Sensor API, but TAG 
review (https://github.com/w3ctag/design-reviews/issues/207) feedback needs to 
be addressed.

For our WebVR use cases, there's an ongoing discussion for the WebVR Polyfill 
here: https://github.com/googlevr/cardboard-vr-display/issues/10

Jonathan/Anne/Martin/Kyle, feel free to correct me, but as I see it, here's a 
potential process of the actionable steps we can take to securing the legacy 
Device Sensor APIs today and eventually deprecating them in favor of an 
implementation of the Generic Sensor APIs.

1. Lock down the Device Sensor APIs APIs in Gecko to only secure contexts, with 
`deviceorientation`, `absolutedeviceorientation`, and `devicemotion` being 
enabled by default.
* Despite the bug title, the WIP patches in http://bugzil.la/1359076 do handle 
this with the `device.sensors.orientation.enabled` flag:
* https://reviewboard.mozilla.org/r/160400/diff/#index_header

2. Implement the Generic Sensor APIs in Gecko.
* Spec:
* https://w3c.github.io/sensors/
* File a Bugzilla tracking bug for Gecko implementation (à la 
https://crbug.com/750018).
* Announce Intent to Implement.
* Chrome's platform status:
* Platform feature page:
* https://www.chromestatus.com/feature/5698781827825664
* Blink's Implementation (shipped in M63):
* https://crbug.com/750018
* 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/TkfdVqYAYiE
* https://developers.google.com/web/updates/2017/09/sensors-for-the-web
* Blink's Origin Trial (ends Feb 27, 2018):
* 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2zPZt3watBk
* 
https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/available-trials.md#current-experimental-features

2. Implement the Feature Policy API in Gecko.
* Spec:
* https://wicg.github.io/feature-policy/
* https://w3c.github.io/sensors/#feature-policy-api
* 
https://github.com/WICG/feature-policy/blob/gh-pages/features.md#sensor-features
* 
https://docs.google.com/document/d/1k0Ua-ZWlM_PsFCFdLMa8kaVTo32PeNZ4G7FFHqpFx4E/edit
* File a Bugzilla tracking bug for Gecko implementation for implementing the 
Feature Policy (à la Blink's: https://crbug.com/623682).
* File a Bugzilla tracking bug for Gecko implementation for having the legacy 
Device Orientation API (or Generic Sensor API, if it's implemented) use the 
Feature Policy (à la Blink's: https://crbug.com/750018).
* Announce Intent to Implement the Feature Policy.
* Announce Intent to Implement the Feature Policy for the Device Orientation 
and/or Generic Sensor APIs.
* Chrome's platform status:
* Platform feature page for Feature Policy:
* https://www.chromestatus.com/feature/5694225681219584
* Blink's Implementation for Feature Policy (shipped in M60):
* https://crbug.com/623682
* https://bugs.chromium.org/p/chromium/issues/detail?id=623682=2
* Platform feature page for page for Feature Policies for the Device 
Orientation API (i.e., `deviceorientation`, `deviceorientationabsolute`, and 
`devicemotion` events):
* https://www.chromestatus.com/feature/5758486868656128
* Blink's in-progress Implementation for Feature Policy for the Device 
Orientation API:
* https://crbug.com/750018

4. Deprecate the legacy Device Orientation API in Gecko.
* This email thread could suffice, but a new thread might be best.
* Close http://bugzil.la/1359076, and file a new Bugzilla tracking bug for 
removing Gecko implementation.
* Announce Intent to Deprecate.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Fabrice Desre]

On 01/09/2018 04:59 PM, Jonathan Kingston wrote:

I would like to see the expansion of this feature here, especially for
handling more types of content. Chrome has been working on Web Share Target
API[1] which somewhat overlaps this behaviour and could be expanded to cope
with the use cases here. I actually think web sharing is the answer here,
it also seems like we need to go back to the drawing board for this API if
we want this anyway.


WebShare is more a trimmed down version of the WebActivities/WebIntents 
apis. I think it's unfortunate that instead of fixing the issues with 
WA/WI they went with a single purpose API - this doesn't scale at all 
with uses case they don't think about and limits the innovation for 
content publishers.


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

Re: Intent to unship: navigator.registerContentHandler()

[Jonathan Kingston]

I would like to see the expansion of this feature here, especially for
handling more types of content. Chrome has been working on Web Share Target
API[1] which somewhat overlaps this behaviour and could be expanded to cope
with the use cases here. I actually think web sharing is the answer here,
it also seems like we need to go back to the drawing board for this API if
we want this anyway.

Also if there is need for web extension functionality here that could
be addressed without having to expose this to the web.

I have an r+ on the patch which disables this in Nightly and early
Beta, unless there are objections I will land this in central in a few
days and we can measure if there is any issues before filing another
removal for stable.


[1] https://github.com/WICG/web-share-target/blob/master/docs/explainer.md



On Tue, Jan 9, 2018 at 4:54 PM, L. David Baron  wrote:

> On Tuesday 2018-01-09 08:51 -0800, L. David Baron wrote:
> > I'm a little hesitant here -- this is an important feature for
> > allowing Web apps to fulfil the function that desktop apps do, and
> > I'd rather push to see it expand.
> >
> > For example, if we added support for registering for text/calendar,
> > then Google Calendar could choose to register for that, and thus
> > become the handler for random ICS files that I'm served by sites
> > that allow me to make appointments.
> >
> > Right now desktop calendar apps have more power than web calendar
> > apps do here, for no good reason, and it seems like we ought to be
> > trying to change that.
>
> Though given Anne's point about wanting an API that doesn't do two
> loads of the content, I guess removal is probably the right thing.
> But it would really be good to work on standardizing something
> better here.
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

stockwell (intermittent failures) policy change - recommend disabling tests when 150 failures are seen in 21 days

[jmaher]

Happy new year from the stockwell team!  We have been busy triaging bugs and 
getting the test-verify job to be fine tuned for all platforms and test suites.

If you want to read about what we plan to do in the near future, you can follow 
along in this tracking bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1428828

One change I wanted to make everyone aware of is the threshold we use to set 
the whiteboard tag: [stockwell disable-recommended].  For the last 4 months 
that has been 200 failures in 30 days.  We look at this whiteboard tag twice a 
week and focus on those bugs- basically if there isn't signs of an upcoming 
patch we disable the test to reduce the pain on the trees.

What I would like to change on January 15th, is the threshold so that it is 150 
failures over 21 days.  In analyzing data over the last 4 months there would 
have been 2 bugs which we would have disabled which ended up getting fixed a 
week later- the rest of the bugs had active development taking place and would 
have been fixed/resolved as they were normally.

The advantage of doing this is we would disable tests 9 days faster, reducing 
failures on the tree and more importantly fewer failures on your try pushes 
with almost the exact same end result.

Please reply if you have concerns or other ideas we should consider.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Password autofilling

[Eric Rescorla]

On Tue, Jan 9, 2018 at 8:43 AM, Gervase Markham  wrote:

> On 01/01/18 20:08, Jonathan Kingston wrote:
> > A recent research post[1] have highlighted the need for Firefox to
> disable
> > autofilling of credentials. The research post suggests web trackers are
> > using autofilling to track users around the web.
>
> Autofill is restricted to same-domain (roughly) so how can they track
> users "around the web"?



The third party JS is loaded into the page's context:

"Thus, third-party javascript can retrieve the saved credentials by
creating a form with the username and password fields, which will then be
autofilled by the login manager."



Other than not being cleared when cookies are cleared, how is this
> technique more powerful than a cookie containing one's email address?
>

Being unclearable is certainly more powerful, but it also allows
cross-correlation
between different tracking domains because the identifiers are stable.

-Ekr


> Autofill is an extremely, extremely convenient browser function, and the
> fact that Firefox's current implementation doesn't always do the right
> thing (e.g. offering me 3 choices of username and, when I pick one, 3
> choices of password rather than autofilling the one which matches the
> username, ) is a source of regular frustration. Let's not break
> the usability more.
>
> Gerv
> ___
> 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: navigator.registerContentHandler()

[L. David Baron]

On Tuesday 2018-01-09 08:51 -0800, L. David Baron wrote:
> I'm a little hesitant here -- this is an important feature for
> allowing Web apps to fulfil the function that desktop apps do, and
> I'd rather push to see it expand.
> 
> For example, if we added support for registering for text/calendar,
> then Google Calendar could choose to register for that, and thus
> become the handler for random ICS files that I'm served by sites
> that allow me to make appointments.
> 
> Right now desktop calendar apps have more power than web calendar
> apps do here, for no good reason, and it seems like we ought to be
> trying to change that.

Though given Anne's point about wanting an API that doesn't do two
loads of the content, I guess removal is probably the right thing.
But it would really be good to work on standardizing something
better here.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[L. David Baron]

On Wednesday 2018-01-03 15:15 +, Jonathan Kingston wrote:
> I am suggesting the removal of navigator.registerContentHandler
> 
> API used to register a web page to handle content types.
> 
> Firefox has an implementation that only can be used to allow a web page to
> handle RSS feeds. We don't have telemetry on this feature however we do
> know that registerProtocolHandler has around 0.2% usage and this feature is
> implemented in multiple browsers and isn't specific to Firefox.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398169
> 
> There is a small risk of breakage that we could decide to delay and instead
> implement telemetry. However if the site is feature testing rather than
> user agent testing there shouldn't be an issue here. As this API throws
> errors there is likelihood websites account for it throwing anyway. I would
> prefer however to let the removal ride the trains due to it's low risk
> before 61 so our ESR doesn't have it.
> 
> Alternatively we could restrict this API to Secure Context only due to the
> risk of passing web content to an insecure context. This would be aligned
> with our overall plan regarding HTTP APIs.
> 
> Removal of this feature requires the removal of some internal tests and to
> stop ignoring a web platform test.
> 
> The rationale:
> 
> - This API had bugs filed on it's implementation
> - Is only implemented by Firefox
> - The API is now non standard
> - No other browsers have intent to implement

I'm a little hesitant here -- this is an important feature for
allowing Web apps to fulfil the function that desktop apps do, and
I'd rather push to see it expand.

For example, if we added support for registering for text/calendar,
then Google Calendar could choose to register for that, and thus
become the handler for random ICS files that I'm served by sites
that allow me to make appointments.

Right now desktop calendar apps have more power than web calendar
apps do here, for no good reason, and it seems like we ought to be
trying to change that.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Password autofilling

[Gervase Markham]

On 01/01/18 20:08, Jonathan Kingston wrote:
> A recent research post[1] have highlighted the need for Firefox to disable
> autofilling of credentials. The research post suggests web trackers are
> using autofilling to track users around the web.

Autofill is restricted to same-domain (roughly) so how can they track
users "around the web"?

Other than not being cleared when cookies are cleared, how is this
technique more powerful than a cookie containing one's email address?

Autofill is an extremely, extremely convenient browser function, and the
fact that Firefox's current implementation doesn't always do the right
thing (e.g. offering me 3 choices of username and, when I pick one, 3
choices of password rather than autofilling the one which matches the
username, ) is a source of regular frustration. Let's not break
the usability more.

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

Re: Intent to unship: navigator.registerContentHandler()

[Anne van Kesteren]

On Tue, Jan 9, 2018 at 5:30 PM, Gervase Markham  wrote:
> I'm sure unshipping it is the right thing to do, but it's very sad. :-(
> Allowing web pages to register for content types and protocols seems
> kind of important if you want the web to have the capability of
> seamlessly replacing desktop and mobile apps.

It might still be worth pursuing, but note that the current API is
rather broken and results in two loads of the content (and how it
integrated with navigation/fetching was never really defined in
sufficient detail). A better API would be handing of the stream of the
download somehow to the third-party. Also note that the "protocol" API
is still there.


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

Re: Intent to unship: navigator.registerContentHandler()

[Gervase Markham]

On 03/01/18 15:15, Jonathan Kingston wrote:
> I am suggesting the removal of navigator.registerContentHandler
> 
> API used to register a web page to handle content types.

I'm sure unshipping it is the right thing to do, but it's very sad. :-(
Allowing web pages to register for content types and protocols seems
kind of important if you want the web to have the capability of
seamlessly replacing desktop and mobile apps.

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