Intent to ship: Microsoft JhengHei as default Traditional Chinese locale font of sans serif on Windows
Windows Vista or later changes Traditional Chinese default font to Microsoft JhengHei [*1] that supports ClearType. So Firefox changes to it like other browsers such as Chrome. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1394709 This change is Nightly channel only at this point, but it will be changed by 64 for stable channel. -- Makoto Kato *1 https://docs.microsoft.com/en-us/typography/font-list/microsoft-jhenghei ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: media-capabilities
Hi The code is now in central and in the last nightly. It's currently disabled by default behind the pref media.media-capabilities.enabled The bug tracking fingerprinting concerns is done in https://bugzilla.mozilla.org/show_bug.cgi?id=1461454 Feel free to enable it and watch videos in YouTube. On mac in particular it would allow to re-enable the free vp9 codec (which has been disabled due to performance reason) Kind regards Jean-Yves On Mon, May 14, 2018 at 5:19 PM, Jean-Yves Avenard wrote: > Media Capabilities allow for web sites to better determine what content to > serve to the end user. > Currently a media element offers the canPlayType method ( > https://html.spec.whatwg.org/multipage/media.html#dom- > navigator-canplaytype-dev) to determine if a container/codec can be used. > But the answer is limited as a maybe/probably type answer. > > It gives no ability to determine if a particular resolution can be played > well/smoothly enough or be done in a power efficient manner (e.g. will it > be hardware accelerated). > > This has been a particular problem with sites such as YouTube that serves > VP9 under all circumstances even if the user agent won't play it well (VP9 > is mostly done via software decoding and is CPU itensive). This has forced > us to indiscriminately disable VP9 altogether). > For YouTube to know that VP9 could be used for low resolution but not > high-def ones would allow them to select the right codec from the start. > > This issue is tracked in bugzilla 1409664 (https://bugzilla.mozilla.org/ > show_bug.cgi?id=1409664) > > The proposed spec is available at https://wicg.github.io/ > media-capabilities/ > > Chrome has shipped it a while ago now and talking to several partners > (including YouTube, Netflix, Facebook etc) , Media Capabilities support has > been the number one request. > > We intend to implement and ship this API very soon. > > Early comment and feedback will be welcome. > > Kinds regards > Jean-Yves > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Disable Metadata:
There are two related requests to disable the use two tracking flag fields
in Bugzilla.
* https://bugzilla.mozilla.org/show_bug.cgi?id=1473002
Disable the verified-{aurora, beta, production} flag
We now use the status-firefoxNN flags for this.
* https://bugzilla.mozilla.org/show_bug.cgi?id=1473001
Disable the 'verifyme' keyword
We now use the qe-verify flag
Since it's a holiday in the US and people may not be back in the office
until next week, I'll wait until Tuesday the 10th to hear back on concerns
about disabling these, and then I'll follow through.
Sylvestre suggested these changes. You too can become a certified BMO
de-complexifiy-er (swag forthcoming). If you see a field, flag, or value we
aren't using and can be retired, open a bug in
bugzilla.mozilla.org::administration.
-- Emma
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to Ship: Logical properties in computed style objects.
Hi, In bug 1116638 I made changes so that getPropertyValue in computed style objects would correctly expose logical properties. This is more of a bug-fix than a new feature, but it was probably worth sending an email to the list. Let me know if there's any concern with this. Thanks! -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: block audible autoplay media intervention
Intent to ship: block audible autoplay media intervention
SUMMARY:
We intend to change the behaviour of HTMLMediaElement to block autoplay of
audible audio and video in Firefox on desktop and mobile.
We are not going to block WebAudio at the same time. While we do plan to block
audible autoplay of WebAudio content in the near future, we have not finalized
our WebAudio blocking logic or intended ship date for blocking WebAudio.
TIMELINE:
We intend to run shield studies on the user impact of enabling HTMLMediaElement
autoplay blocking. If those go well we hope to ship in Firefox 63 (2018-10-23)
or Firefox 64 (2018-12-11). Upon conclusion of our experiments, I’ll follow up
here with a confirmed ship date for this feature.
We hope to block autoplay in WebAudio in a release soon after, hopefully
Firefox 64 or 65.
DETAILS:
We intend to block autoplay of HTMLMediaElement in tabs which haven't had user
interaction. Web authors should assume that they require a user gesture (mouse
click on a "play" button for example) in order to play audible media.
HTMLMediaElements with a "muted" attribute or "volume=0" are still allowed to
play.
As with other browsers implementing this feature, we express playback being
blocked by rejecting the promise returned by HTMLMediaElement.play(). Web
authors should always check whether the promise returned by
HTMLMediaElement.play() is rejected, and handle that case accordingly.
We also plan to allow users to create their own whitelist of sites which they
trust to autoplay.
We are planning to experiment via shield studies with prompting users to
approve/block playback on sites that try to autoplay before receiving user
interaction.
ADVICE FOR WEB AUTHORS:
In general, the advice that applies to other browsers [1][2] with respect to
autoplaying media will apply to Firefox as well; you cannot assume that you can
just call HTMLMediaElement.play() for audible media and expect it to always
play. You should always check whether the play promise is rejected, and handle
that case accordingly.
For example:
var promise = document.querySelector('video').play();
if (promise !== undefined) {
promise.catch(error => {
// Auto-play was prevented
// Show a UI element to let the user manually start playback
}).then(() => {
// Auto-play started
});
}
(This example comes from WebKit’s announcement on blocking autoplay [2])
To test block autoplay in Firefox 63 (currently in Firefox Nightly channel),
download the latest Nightly and open about:config in the URL bar and set the
preferences:
media.autoplay.enabled=false
media.autoplay.enabled.user-gestures-needed=true
media.autoplay.ask-permission=true
Tracking bug: (block-autoplay)
https://bugzilla.mozilla.org/show_bug.cgi?id=1376321
If you find bugs, please file them via this link and CC or need-info me
(cpearce), and mark them blocking bug 1376321:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Audio%2FVideo%3A%20Playback
I will follow up with a confirmed ship date for block audible autoplay in
Firefox once we have one.
[1] https://developers.google.com/web/updates/2017/09/autoplay-policy-changes
[2] https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Update: Phabricator and commit series
Mark, I just wanted to thank you and your team for putting this plan together. It's very much appreciated! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
