Re: Intent to ship: WebVR on macOS

[kgilbert]

On Tuesday, February 27, 2018 at 12:51:46 PM UTC-8, kear...@kearwood.com wrote:
> On Wednesday, September 20, 2017 at 4:30:56 PM UTC-7, Kearwood  Kip  Gilbert 
> wrote:
> > As of 2017-10-01, I intend to turn WebVR on by default for macOS.  It has 
> > been developed behind the dom.vr.enabled preference.  We have already 
> > shipped WebVR by default for the Windows platform.  macOS support has been 
> > implemented for several months but disabled by default.  Our WebVR 
> > implementation supports OpenVR for the HTC Vive on macOS High Sierra, which 
> > is now hitting release.
> > This feature was previously discussed in this "intent to implement" thread: 
> > . 
> > Bug to turn on by default: 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1374399
> > Link to standard: https://w3c.github.io/webvr/spec/1.1/
> > Testing: 
> > Automated tests have been implemented and are already active for the macOS 
> > builds in taskcluster.  Platform conformance tests are shared with other 
> > UA’s.
> 
> As of 2018-02-27, I intend to turn WebVR [back] on by default for macOS.  Due 
> to hardware availability for QA, this was disabled before riding to release 
> for FF58 and FF59.  We have since gained QA approval to allow it to ride to 
> release in FF60.
> 
> Bug to turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1438044
> 
> Link to standard:
> https://w3c.github.io/webvr/spec/1.1/
> 
> Testing: 
> Automated tests have been implemented and are already active for the macOS 
> builds in taskcluster.  Platform conformance tests are shared with other UA’s.

Enabling this was delayed / rolled back due to issues with the SteamVR runtime 
on macOS occurring when we disabled the macOS nano-allocator for the Firefox 
process to fix unrelated issues.  Updates to the SteamVR runtime have corrected 
this.

This will be re-re-enabled for FF64 on 2018-10-12.  The new bug to turn on by 
default:

Bug 1476091 ((Re-) Enable WebVR by default for macOS)

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

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

[Boris Zbarsky]

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1498357 to track 
these failures.


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

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

[Boris Zbarsky]

On 10/11/18 4:22 PM, Philip Jägenstedt wrote:

https://gist.github.com/foolip/a77c88e62aa3cfc461c2879f3e5d4855 is a
list of tests that fail in Firefox Nightly, but pass in stable
versions of Chrome, Edge and Safari.


Or more precisely have some sub-test that has that property, right?

Thank you for putting this list together.

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

web-platform-tests that fail only in Firefox (from wpt.fyi data)

[Philip Jägenstedt]

Hi all,

I sent the result of some investigation to webkit-dev [1] today and
thought you might be interested to take a look the equivalent list for
Firefox.

https://gist.github.com/foolip/a77c88e62aa3cfc461c2879f3e5d4855 is a
list of tests that fail in Firefox Nightly, but pass in stable
versions of Chrome, Edge and Safari. Although not all of them will be
high-value and really impact web developers, these are probably more
valuable to fix than a random WPT failure. Triage and prioritization
required, of course.

Skimming the list, I'd guess that css-flexbox, css-grid, fetch and
streams might be the most worth digging into.
cors-cookies-redirect.any.html, for example, seems like something that
could matter in the real world.

Making this part of the wpt.fyi UI is a current priority [2] but I
thought this one-off analysis might still be useful to y'all.

[1] https://lists.webkit.org/pipermail/webkit-dev/2018-October/030209.html
[2] https://github.com/web-platform-tests/wpt.fyi/issues/201
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebP image support

[Jeff Muizelaar]

Yes, that's part of it. Further, now that Edge has shipped it we can
cause there to be a majority of vendors supporting it. Having WebP
supported by all of the browsers changes the weight we put on the
different advantages and disadvantages. For example, Firefox
supporting WebP will allow now allow web authors to have lossy
compressed images with transparency (by using WebP with Chrome, Edge,
Firefox and JPEG2000 with Safari)

-Jeff

On Thu, Oct 11, 2018 at 11:48 AM, Boris Zbarsky  wrote:
> On 10/11/18 11:43 AM, Andrew Osmond wrote:
>>
>> We are facing a growing number of webcompat reports against our
>> Gecko-derived
>> Android offerings, where web developers assume Android and/or mobile
>> implies support for WebP.
>
>
> In the past, I believe we objected to adding WebP for various reasons. Do we
> feel that those reasons are now outweighed by the compat problems?
>
> -Boris
>
> ___
> 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 implement and ship: WebP image support

[Randell Jesup]

>Are we bringing in a new third party library for this? (Seems like yes?)

libwebp (see https://bugzilla.mozilla.org/show_bug.cgi?id=1294490)

>Who else uses it/audits it? Does anyone else fuzz it? Is it in OSS-fuzz?
>Are we fuzzing it?

http://developers.google.com/speed/webp - Chrome uses it.  They fuzz it
(including with private fuzzing).

It's in OSS-fuzz: see
https://groups.google.com/a/webmproject.org/forum/#!topic/webp-discuss/aqHRxQqJpH0

I don't believe we're fuzzing the patches yet, but I imagine we will.

>How does upstream behave? Do they cut releases or do they just have
>continual development and downstreams grab random versions of it? How do we
>plan to track security issues upstream? How do we plan to update it
>(mechanically and how often)?

You can see how they handle releases above.  Version 1.0.0 was cut in
April (though there were a number before then).
See https://chromium.googlesource.com/webm/libwebp

I don't know how they track sec issues; probably similar to other
google/chrome/chromium projects.
See https://bugs.chromium.org/p/webp/issues/list
You can report issues as "Security" issues.

> bz wrote:
>> In the past, I believe we objected to adding WebP for various reasons.
>> Do we feel that those reasons are now outweighed by the compat problems?

(Personal opinion) Yes, unfortunately.  And AV1F image format both isn't
ready and isn't universally supported; it will take a while.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: LocalMediaStream

[Mike Taylor]

On 10/11/18 11:13 AM, Andreas Pehrson wrote:
We don't have telemetry for this. On the other hand we're the last ones 
still implementing this, so that takes care of the people that don't 
test in Firefox that you mention.


FWIW Chrome removed this in 47. That's three years ago. And Chrome tends 
to be what most services develop and test against when it comes to 
webrtc (with its still actively changing spec).

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

In light of this, do you still think we need to add telemetry?


I think if Chrome was able to successfully remove, there's a lot less risk.

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: LocalMediaStream

[Andreas Pehrson]

On Thu, Oct 11, 2018 at 4:58 PM Mike Taylor  wrote:

> On 10/11/18 9:16 AM, Andreas Pehrson wrote:
> > I would like to unship the MediaStream subclass LocalMediaStream and its
> > stop method.
> >
> > Firefox is the only major browser to still ship LocalMediaStream. It is
> the
> > type we use for the MediaStream that is returned from getUserMedia.
> >
> > The most breakage I expect is for the removal of the stop method, but for
> > this we shipped a console deprecation warning in Firefox 44 (bug
> 1103188).
>
> Do we have telemetry on usage of stop? If not, can we collect it?
>
> In my experience, developers aren't really paying attention to
> deprecation warnings in the console (...especially the ones that don't
> test in Firefox).
>

We don't have telemetry for this. On the other hand we're the last ones
still implementing this, so that takes care of the people that don't test
in Firefox that you mention.

FWIW Chrome removed this in 47. That's three years ago. And Chrome tends to
be what most services develop and test against when it comes to webrtc
(with its still actively changing spec).
https://bugs.chromium.org/p/chromium/issues/detail?id=338500

In light of this, do you still think we need to add telemetry?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebP image support

[Tom Ritter]

Are we bringing in a new third party library for this? (Seems like yes?)

Who else uses it/audits it? Does anyone else fuzz it? Is it in OSS-fuzz?
Are we fuzzing it?

How does upstream behave? Do they cut releases or do they just have
continual development and downstreams grab random versions of it? How do we
plan to track security issues upstream? How do we plan to update it
(mechanically and how often)?

-tom

On Thu, Oct 11, 2018 at 3:50 PM Boris Zbarsky  wrote:

> On 10/11/18 11:43 AM, Andrew Osmond wrote:
> > We are facing a growing number of webcompat reports against our
> Gecko-derived
> > Android offerings, where web developers assume Android and/or mobile
> > implies support for WebP.
>
> In the past, I believe we objected to adding WebP for various reasons.
> Do we feel that those reasons are now outweighed by the compat problems?
>
> -Boris
> ___
> 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 implement and ship: WebP image support

[Boris Zbarsky]

On 10/11/18 11:43 AM, Andrew Osmond wrote:

We are facing a growing number of webcompat reports against our Gecko-derived
Android offerings, where web developers assume Android and/or mobile
implies support for WebP.


In the past, I believe we objected to adding WebP for various reasons. 
Do we feel that those reasons are now outweighed by the compat problems?


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

Intent to implement and ship: WebP image support

[Andrew Osmond]

WebP is an image format developed by Google, long supported by Chrome. We
are facing a growing number of webcompat reports against our Gecko-derived
Android offerings, where web developers assume Android and/or mobile
implies support for WebP. In addition, Edge has now shipped WebP [1]. As
such, I would like to add support for WebP images, still and animated, to
Firefox, to ensure our users are able to actually view content that relies
upon it.

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

Platform coverage: All.

Target Release: 65

Preference behind which this will be implemented: image.webp.enabled,
turned on by default.

Do other browser engines implement this?: Chrome, Edge.

Is this feature restricted to secure contexts?: No, it isn't. This is not a
new API, instead it is just accepting more types of content via existing
channels.

[1] https://developer.microsoft.com/en-us/microsoft-edge/platform/status/
webpimageformat/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: LocalMediaStream

[Mike Taylor]

On 10/11/18 9:16 AM, Andreas Pehrson wrote:

I would like to unship the MediaStream subclass LocalMediaStream and its
stop method.

Firefox is the only major browser to still ship LocalMediaStream. It is the
type we use for the MediaStream that is returned from getUserMedia.

The most breakage I expect is for the removal of the stop method, but for
this we shipped a console deprecation warning in Firefox 44 (bug 1103188).


Do we have telemetry on usage of stop? If not, can we collect it?

In my experience, developers aren't really paying attention to 
deprecation warnings in the console (...especially the ones that don't 
test in Firefox).


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: LocalMediaStream

[Andreas Pehrson]

I would like to unship the MediaStream subclass LocalMediaStream and its
stop method.

Firefox is the only major browser to still ship LocalMediaStream. It is the
type we use for the MediaStream that is returned from getUserMedia.

The most breakage I expect is for the removal of the stop method, but for
this we shipped a console deprecation warning in Firefox 44 (bug 1103188).

The alternative to stopping the MediaStream from getUserMedia is to stop
all the tracks that were originally present in it through the stop method
on MediaStreamTrack. We shipped this method in Firefox 34 (bug 1057955).

This work is tracked in bug 1258143.
https://bugzilla.mozilla.org/show_bug.cgi?id=1258143
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Extension to integrate Searchfox features in Phabricator

[Marco Castelluccio]

Thanks for the report, I had built it really quickly without actually
looking into perf.

I think the issue should be fixed in the newest version of the extension
(0.2.1), let me know if it isn't (I couldn't reproduce it).

- Marco.

P.S.: Should you find other problems, you can file issues at
https://github.com/marco-c/mozsearch-phabricator-addon/issues.


Il 11/10/2018 00:26, Bobby Holley ha scritto:
> I noticed this extension seems to be causing significant jank while
> typing comments into phabricator. I'll send a profile to Marco, but
> just an FYI for anyone else who's using it.
>
> On Tue, Oct 2, 2018 at 6:03 AM Marco Castelluccio
> mailto:mcastelluc...@mozilla.com>> wrote:
>
> I've built an (experimental) WebExtension to integrate some of the
> Searchfox features into Phabricator.
> I find it very useful to be able to search code while reviewing, but I
> have to resort to opening a new
> Searchfox tab and looking for the code that is being modified. This
> extension makes my workflow much
> more pleasant.
>
> You can find it at
> https://addons.mozilla.org/addon/searchfox-phabricator/ (the
> source code
> is at
> https://github.com/marco-c/mozsearch-phabricator-addon).
>
> Currently, the extension does:
> 1) Highlight keywords when you hover them, highlighting them both
> in the
> pre-patch and in the post-patch view;
> 2) When you press on a keyword, it offers options to search for the
> definition, callers, and so on (the results are opened on
> Searchfox in a
> new tab).
>
> I'm planning to add support for sticky highlighting and blame
> information (when hovering on the line number on the left side).
>
> - Marco.
>
> P.S.: The extension relies on parsing pages from Searchfox and from
> Phabricator, so the maintenance might not be so easy. If there's
> enough
> interest, I might keep maintaining it or talk with someone to make
> Searchfox data accessible in an easier way.
> ___
> 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