Re: Intent to ship MediaSource SourceBuffer.changeType

[Jean-Yves Avenard]

> On 6 Aug 2018, at 10:30 pm, Boris Zbarsky  wrote:
> 
> On 8/6/18 5:37 AM, Jean-Yves Avenard wrote:
>> enable by default changeType method on MediaSource’s Source Buffer
> 
> To be clear, this is enabling by default on all channels, right?

yes

> 
>> The method has been availably since 61 behind the preference 
>> media.mediasource.experimental.enabled
> 
> But not default-enabled anywhere, so not much tested?

We have web-platform-tests for this feature which have landed… We know that 
YouTube intends to use this new functionality as soon as available.
http://w3c-test.org/media-source/mediasource-changetype.html
http://w3c-test.org/media-source/mediasource-changetype-play.html

As far as test is concerned, limiting the type of codecs used was an artificial 
limitation to start with. So the core code involved has always been exercised 
since the MSE rearchitecture (which came with 42)

> 
> How stable is the spec?

Stable I believe and unlikely to change again.
There’s a few “v2” MSE features in the pipeline, but they typically will 
require more work.

> 
> What is the status of implementation or interest in other browsers?

Chrome has it implemented behind a pref too, we haven’t discussed with others 
to determine their intention on that…
IMHO, it’s the most useful addition made to MSE since it first came out.
It will greatly improve adaptative quality streaming.
I’m fairly keen to see how AV1 can be used more easily that way (which 
otherwise would be limited to only the most powerful machines out there)

Google’s main interest for this is for ad insertions unfortunately, a bit sad 
when there’s so much potential.


> 
> What is the status of interest from authors?

Media Capabilities and changeType was the 2 most requested features by all 
content providers we’ve met this year.

> 
> Put another way, if we thought this was a safe change why did we have it off 
> by default to start with?  Were there substantive changes to the code since 
> 61 that prevented us from enabling by default before now?

The implementation behind changeType followed several iterations to reach that 
point. At which time the Chrome team and us agreed on the current definition.

I had put it behind a pref to start with as there were no specs at all defined 
for it. It was developed as a proof of concept, to show on what could be 
achieved and how easily it could be done.

Our MediaSource implementation and architecture had been conceived from the 
ground up with this capability in mind… So we were the first to implement it 
and it was done very quickly.

We then had a few back and forth meetings with the Chromium media team until we 
agreed (with compromises) on the final draft.

I hope I answered all your questions.

JY

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: overflow: -moz-scrollbars-* values

[Xidorn Quan]

In bug 1481125[1], I'm going to put some moz-prefixed values of overflow 
shorthand property behind pref, and disable them by default on all channel.

The values being unshipped are:
* -moz-scrollbars-none
* -moz-scrollbars-horizontal
* -moz-scrollbars-vertical

Their functionality can be fully replaced by standard syntax nowadays, and 
apparently no other browser supports them.

We probably preserved them for webcompat concerns, but as can be seen in the 
unshipping bug, keeping them causes real webcompat issues, so I think we should 
just try unshipping them and see.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1481125


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

[desktop] Bugs logged by Desktop Release QA in the last 7 days

[Bogdan Maris]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA team 
last two weeks.
Additional details on the team's priorities last week, as well as the plans for 
the current week are available at: https://tinyurl.com/ycd96onk
Bugs logged by Desktop Release QA in the last 7 days

Firefox: Toolbars and Customization
ASSIGNED - https://bugzil.la/1479721 - Saving a pdf page to pocket while in 
presentation mode breaks the "Page actions" and "Save to pocket" buttons
NEW - https://bugzil.la/1481242 - The "Page Actions" panel is misplaced after 
adding several buttons to the Address Bar

Firefox: Search
NEW - https://bugzil.la/1480674 - alt+enter does not open a new tab from 
about:newtab using the Location Bar

Firefox: Shell Integration
NEW - https://bugzil.la/1480686 - [windows] Tab previews are not displayed in 
the taskbar for more than 20 tabs

DevTools: Animation Inspector
ASSIGNED - https://bugzil.la/1479756 - UI scales overlap
NEW - https://bugzil.la/1479761 - Animations could be listed in the inspector 
as inactive
NEW - https://bugzil.la/1479773 - Timeline cursor changes when scorlling and 
moving over other elements
NEW - https://bugzil.la/148 - Update style for animation playback rates 
button and dropdown
NEW - https://bugzil.la/1480008 - Timestamp headers disappear when resizing the 
3rd pane
NEW - https://bugzil.la/1480027 - Animations tab crashes when timer is set to 
long values
NEW - https://bugzil.la/1480067 - Animations scale-sections displayed after 
DevTools tab change
NEW - https://bugzil.la/1479451 - Default animation playback speed value should 
be saved after being changed
NEW - https://bugzil.la/1479468 - Seek bar loses functionality while being 
dragged at the beginning or at the end of the progress chart

Toolkit: Password Manager
NEW - https://bugzil.la/1480395 - [Ubuntu] The right border fields inside the 
"Saved Logins..." dialog appear as cut off
NEW - https://bugzil.la/1480440 - Saved credentials are not exported from 
Firefox to other browsers under Ubuntu OS

Toolkit: Reader Mode
NEW - https://bugzil.la/1480415 - NVDA Screen Reader doesn't read the Reader 
View button on hover

Tech Evangelism: Desktop
NEW - https://bugzil.la/1480681 - Video feed not streamed
NEW - https://bugzil.la/1480683 - [Netflix] The default login form background 
message is not falling back if credentials are typed

This is available as a Bugzilla bug list as well: https://tinyurl.com/yaw8tl8v

Regards,
Bogdan (:bogdan_maris)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship MediaSource SourceBuffer.changeType

[Boris Zbarsky]

On 8/7/18 6:21 AM, Jean-Yves Avenard wrote:

We have web-platform-tests for this feature which have landed… We know that 
YouTube intends to use this new functionality as soon as available.
http://w3c-test.org/media-source/mediasource-changetype.html
http://w3c-test.org/media-source/mediasource-changetype-play.html


Right, I meant tested against actual sites.


As far as test is concerned, limiting the type of codecs used was an artificial 
limitation to start with. So the core code involved has always been exercised 
since the MSE rearchitecture (which came with 42)


Great, thank you.


Chrome has it implemented behind a pref too, we haven’t discussed with others 
to determine their intention on that…


OK.  Do you have any signals at all from Safari and Edge?  Even just 
knowing "not opposed in current form but no concrete plans to implement" 
would be useful, compared to them suddenly coming back with requests for 
changes in the spec.



Google’s main interest for this is for ad insertions unfortunately, a bit sad 
when there’s so much potential.


Does this make the ad insertion case better for our users in some way, 
at least?



The implementation behind changeType followed several iterations to reach that 
point.


Ah, OK.  That makes sense.


I hope I answered all your questions.


Yes, thank you.  This sounds reasonable to ship without a pref at all 
(which is the actual proposal here, just so everyone is clear), 
especially if we are fairly sure that Safari and Edge won't end up 
objecting to the spec.


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

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

[Boris Zbarsky]

On 7/30/18 8:03 PM, Kip Gilbert wrote:

Link to standard:


Kip,

Could you please ensure that all the relevant .webidl files have links 
to the relevant bits of the standard at the top of the file (and on the 
individual interface definitions if there are multiple interfaces in the 
file)?  See Navigator.webidl for an example of what I'm talking about. 
Right now our WebVR IDLs do not have such links, and that makes working 
with those files a lot more difficult and error-prone than it really 
should be.



The api is documented on the immersive-web GitHub page:

https://immersive-web.github.io/webxr/ 


Is this meant to replace the existing WebVR APIs or augment them? 
Sounds like replace in the long term?



Final TAG review and W3C Working Group discussion may result in late breaking 
changes.  These changes are expected to affect the syntax of the API and not 
the general behaviour.  Any changes are expected to be identified before our 
implementation is ready to ship to release.


Sounds great.  :)

-Boris

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

Re: Intent to ship MediaSource SourceBuffer.changeType

[Jean-Yves Avenard]

> On 7 Aug 2018, at 5:24 pm, Boris Zbarsky  wrote:
> 
> OK.  Do you have any signals at all from Safari and Edge?  Even just knowing 
> "not opposed in current form but no concrete plans to implement" would be 
> useful, compared to them suddenly coming back with requests for changes in 
> the spec.

I’ll enquire on that…

https://wpt.fyi/results/media-source/mediasource-changetype-play.html 

https://wpt.fyi/results/media-source/mediasource-changetype.html 


> 
>> Google’s main interest for this is for ad insertions unfortunately, a bit 
>> sad when there’s so much potential.
> 
> Does this make the ad insertion case better for our users in some way, at 
> least?

It makes it easier for the site.
They typically gets ads from ad suppliers with h264/aac content ; for YouTube 
that allows to easily insert them in their vp9/opus content without having to 
convert them…

So previously, you would have to either pause the current video element, create 
a new one, and set it as overlay, and once done tear everything done.

Now, everything can be done inline, much smoother transitions

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Enable navigator.clipboard.* APIs by default

[Anny Gakhokidze]

As of Firefox 63 I intend to turn on navigator.clipboard.* by default.
It has been developed behind the “dom.events.asyncClipboard” preference.
The APIs that will be exposed are clipboard.readText and
clipboard.writeText and
they will be exposed to secure contexts only.
The readText API will only be usable from WebExtension contexts.

See more details about this feature in the following ‘intent to implement’
thread:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/skHoHwfapEY

Chrome has been shipping this by default since 66.

Spec: https://www.w3.org/TR/clipboard-apis/#async-clipboard-api

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1479935

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

Re: ./mach try fuzzy: A Try Syntax Alternative

[Andrew Halberstadt]

I recently added the ability to specify --query multiple
times (where the set of tasks is the union of each
individual query). So something like:

./mach try fuzzy -q "'android !pgo !cov" -q "'build !pgo !cov"

Should also accomplish what you want. It's still a bit clunky
as multiple queries don't work with --save yet (just the first
query will be saved). But at least this will get the command
in your shell history (and you can also use |mach try again| to
rerun it).

On Mon, Aug 6, 2018 at 3:06 AM James Graham  wrote:

> On 06/08/2018 01:25, Botond Ballo wrote:
> > Is there an easy way to do a T-push (builds on all platforms, tests on
> > one platform only) with |mach try fuzzy|?
> >
> > I usually do T-pushes using try syntax, by Trychooser seems to be out
> > of date when it comes to building a T-push syntax for Android, so I'm
> > at a loss as to how to do a T-push for Android right now.
>
> There are a couple of options. Interactively you can select all the
> builds you want, press ctrl+a (or whatever the select-all keybinding you
> have configured is), then do the same again with the tests you want,
> then accept all your choices.
>
> If you want to construct a single query string that can be reused with
> --save, something like 'test-linux64 | build !ccov !pgo !msvc' seems to
> select all builds and tests just on linux64. Unfortunately I can't
> figure out any way to logically group expressions, which does make
> composing multiple terms more tricky.
> ___
> 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 ship: Enable navigator.clipboard.* APIs by default

[Vlad Filippov]

On Tuesday, August 7, 2018 at 2:19:58 PM UTC-4, Anny Gakhokidze wrote:
> As of Firefox 63 I intend to turn on navigator.clipboard.* by default.
> It has been developed behind the “dom.events.asyncClipboard” preference.
> The APIs that will be exposed are clipboard.readText and
> clipboard.writeText and
> they will be exposed to secure contexts only.
> The readText API will only be usable from WebExtension contexts.
> 
> See more details about this feature in the following ‘intent to implement’
> thread:
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/skHoHwfapEY
> 
> Chrome has been shipping this by default since 66.
> 
> Spec: https://www.w3.org/TR/clipboard-apis/#async-clipboard-api
> 
> Bug to turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1479935
> 
> -Anny.

Exciting new APIs. Great work!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

[Eric Shepherd (Sheppy)]

Thank you; that will help the docs team very much as well.

On Tue, Aug 7, 2018 at 11:30 AM, Boris Zbarsky  wrote:

> On 7/30/18 8:03 PM, Kip Gilbert wrote:
>
>> Link to standard:
>>
>
> Kip,
>
> Could you please ensure that all the relevant .webidl files have links to
> the relevant bits of the standard at the top of the file (and on the
> individual interface definitions if there are multiple interfaces in the
> file)?  See Navigator.webidl for an example of what I'm talking about.
> Right now our WebVR IDLs do not have such links, and that makes working
> with those files a lot more difficult and error-prone than it really should
> be.
>
> The api is documented on the immersive-web GitHub page:
>>
>> https://immersive-web.github.io/webxr/ > io/webxr/>
>>
>
> Is this meant to replace the existing WebVR APIs or augment them? Sounds
> like replace in the long term?
>
> Final TAG review and W3C Working Group discussion may result in late
>> breaking changes.  These changes are expected to affect the syntax of the
>> API and not the general behaviour.  Any changes are expected to be
>> identified before our implementation is ready to ship to release.
>>
>
> Sounds great.  :)
>
> -Boris
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: WebXR Device API in Firefox Nightly

[L. David Baron]

On Monday 2018-07-30 17:03 -0700, Kip Gilbert wrote:
> Is this feature enabled by default in sandboxed iframes?
> WebXR will not be enabled by default in sandboxed iframes.  This will likely 
> be enabled later, by use of Feature Policy: 
> https://github.com/immersive-web/webxr/issues/86 
> 

I'm curious why this is specific to sandboxed iframes, rather than,
say, any cross-origin iframes (and perhaps also same-origin
sandboxed ones).

That said, some of this concern comes from not being sure what it
looks like to a user if a page wants to use XR.  Is there some sort
of permission prompt or request that the user sees first?

If there is... what domain is it associated with?

One of the goals of feature policy is to allow permission requests
be *associated* only with the toplevel page.  This is useful since
permission requests coming from subframes aren't particularly
meaningful and are also confusing -- they don't correspond to the
URL bar, it's not clear what persisting them would mean, etc.

A page would be able to use feature policy to delegate their ability
to use/request capabilities to a cross-origin frame.  Without that
delegation a cross-origin subframe would not have access to the
capability; with the delegation requests from the cross-origin frame
would appear as though they come from the toplevel document (and if
remembered, would be remembered as such).

*If* something like that is the model here, then maybe a
cross-origin iframes restriction rather than a sandbox iframes
restriction makes more sense.

-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

Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Jonathan Watt]

Summary
---

I plan to enable the pref in Nightly builds (using EARLY_BETA_OR_EARLIER) to
turn on the '-webkit-appearance' alias for '-moz-appearance'. This pref
simultaneously changes the behavior of the 'menulist-button' value, and shortly
the 'button-bevel' value.

Spec: None. We're reverse engineering Chrome and ignoring
  https://drafts.csswg.org/css-ui-4/#appearance-switching
  since the 'appearance' property defined there is not
  web compatible.

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

Preferences: layout.css.webkit-appearance.enabled

Platfrom coverage: All

Estimated release: 63 (tentatively)

Known webcompat impact: 19 out of 20 of the open -webkit-appearance
webcompat.org issues are fixed by this change.


The alias
-

The primary concern currently is to get `-webkit-appearance: none` shipped to
fix a bunch of web compat issues and unblock geckoview. That said, previously we
tried to implement and ship the 'appearance' property with only the values
'none' and 'auto' (as per CSS UI 4), along with a '-webkit-appearance' alias.
That attempt was unsuccessful for various reasons, but mainly because cascading
of a '-moz-appearance' other than 'none'/'auto' would not replace a lower
specificity 'appearance' value, breaking current web content and user
expectations about how the properties should cascade.

This time around by aliasing '-webkit-appearance' to '-moz-appearance' our
implementation of '-webkit-appearance' will support all the values that
'-moz-appearance' supports, avoiding the funky cascading issues.


Changes in behavior for existing values
---

Aliasing means that we'll recognize and react to a bunch of other
'-webkit-appearance' values that sites set, so to minimize the chances of
undesirable changes on existing web content, we've also been changing the
behavior of some '-moz-appearance' values to more closely align with the way
that Chrome handles the values of the same name for '-webkit-appearance'. Some
of those changes have shipped. The two that haven't are guarded behind the same
pref that turns on the '-webkit-appearance' alias: 'menulist-button' and
'button-bevel'. (They probably don't need to be though, so we could potentially
ship those separately if desirable.)

Both 'menulist-button' and 'button-bevel' occur two orders of magnitude fewer
than 'none' as a '-moz-appearance' value in github repos, and almost all the
occurrences for the two values seem to be non-interesting.

menulist-button
  https://github.com/search?o=desc&q=-moz-appearance+menulist-button&type=Code

  I dug through hundreds of these and didn't encounter any instances
  that would impact web content. The vast majority appear to occur in
  forks of the Mozilla source or appear in a list of possible values in
  csslint.js.

  The change here makes us display the appearance of an entire (collapsed)
  menulist, not just the drop marker to its right. That makes the change
  here more substantial and so in principal breakage could be significant.

button-bevel
  https://github.com/search?o=desc&q=-moz-appearance+button-bevel&type=Code

  Again, I dug through hundreds of these with the same observation as
  for menulist-button. Even in the places where it is used, border is
  typically overridden meaning that there will likely be no visual
  change for consumers.

  Additionally, the difference between the way button-bevel currently
  displays and how it will be changed to match Chrome is minimal.

Perhaps more significant is the usage count of the various values reported by
the crawl MS did for Edge:

https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-appearance/

Blink/Webkit have no equivalent to our old behavior for 'menulist-button' (show
a dropmarker) which indicates that demand hasn't been high enough for them to
add that functionality. Given that, I expect the number of sites using and
depending on our old 'menulist-button' behavior are extremely low.

Blink's 'square-button' (which behaves the same as our 'button-bevel') was only
used on 0.002% of the pages that they crawled, and again, the visual appearance
change we're making is minimal.


Further aligning '-moz-appearance' with '-webkit-appearance'


I've filed a bunch of bugs for the differences that I'm aware of between the
behavior of '-moz-appearance' in Firefox and '-webkit-appearance' in Chrome, and
marked them as blocking this meta bug:

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

The possible uses and permutations of '-moz/webkit-appearance' are vast, so if
anyone is aware of anything significant that I may have missed please file a new
bug and make it block that meta bug.

I don't think fixing/not fixing any of the issues that that meta bug tracks so
far is likely to cause significant improvements/regressions for a significant
amount of web content, or prevent us from 

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Chris Peterson]

Awesome! This should fix some common webcompat issues for 
Firefox/GeckoView on Android.


What are the criteria for letting -webkit-appearance ride the trains? 
The GeckoView team is eager to ship mobile webcompat fixes, so they 
might be willing to accept more risk than Firefox desktop.


Are there any significant differences between -webkit-appearance on 
Chrome and WebKit? Chrome has more mobile market share than Safari, but 
many of these mobile sites may have been written when a -webkit- prefix 
actually meant WebKit. :)



On 2018-08-07 3:16 PM, Jonathan Watt wrote:

Summary
---

I plan to enable the pref in Nightly builds (using EARLY_BETA_OR_EARLIER) to
turn on the '-webkit-appearance' alias for '-moz-appearance'. This pref
simultaneously changes the behavior of the 'menulist-button' value, and shortly
the 'button-bevel' value.

Spec: None. We're reverse engineering Chrome and ignoring
   https://drafts.csswg.org/css-ui-4/#appearance-switching
   since the 'appearance' property defined there is not
   web compatible.

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

Preferences: layout.css.webkit-appearance.enabled

Platfrom coverage: All

Estimated release: 63 (tentatively)

Known webcompat impact: 19 out of 20 of the open -webkit-appearance
webcompat.org issues are fixed by this change.


The alias
-

The primary concern currently is to get `-webkit-appearance: none` shipped to
fix a bunch of web compat issues and unblock geckoview. That said, previously we
tried to implement and ship the 'appearance' property with only the values
'none' and 'auto' (as per CSS UI 4), along with a '-webkit-appearance' alias.
That attempt was unsuccessful for various reasons, but mainly because cascading
of a '-moz-appearance' other than 'none'/'auto' would not replace a lower
specificity 'appearance' value, breaking current web content and user
expectations about how the properties should cascade.

This time around by aliasing '-webkit-appearance' to '-moz-appearance' our
implementation of '-webkit-appearance' will support all the values that
'-moz-appearance' supports, avoiding the funky cascading issues.


Changes in behavior for existing values
---

Aliasing means that we'll recognize and react to a bunch of other
'-webkit-appearance' values that sites set, so to minimize the chances of
undesirable changes on existing web content, we've also been changing the
behavior of some '-moz-appearance' values to more closely align with the way
that Chrome handles the values of the same name for '-webkit-appearance'. Some
of those changes have shipped. The two that haven't are guarded behind the same
pref that turns on the '-webkit-appearance' alias: 'menulist-button' and
'button-bevel'. (They probably don't need to be though, so we could potentially
ship those separately if desirable.)

Both 'menulist-button' and 'button-bevel' occur two orders of magnitude fewer
than 'none' as a '-moz-appearance' value in github repos, and almost all the
occurrences for the two values seem to be non-interesting.

menulist-button
   https://github.com/search?o=desc&q=-moz-appearance+menulist-button&type=Code

   I dug through hundreds of these and didn't encounter any instances
   that would impact web content. The vast majority appear to occur in
   forks of the Mozilla source or appear in a list of possible values in
   csslint.js.

   The change here makes us display the appearance of an entire (collapsed)
   menulist, not just the drop marker to its right. That makes the change
   here more substantial and so in principal breakage could be significant.

button-bevel
   https://github.com/search?o=desc&q=-moz-appearance+button-bevel&type=Code

   Again, I dug through hundreds of these with the same observation as
   for menulist-button. Even in the places where it is used, border is
   typically overridden meaning that there will likely be no visual
   change for consumers.

   Additionally, the difference between the way button-bevel currently
   displays and how it will be changed to match Chrome is minimal.

Perhaps more significant is the usage count of the various values reported by
the crawl MS did for Edge:

https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-appearance/

Blink/Webkit have no equivalent to our old behavior for 'menulist-button' (show
a dropmarker) which indicates that demand hasn't been high enough for them to
add that functionality. Given that, I expect the number of sites using and
depending on our old 'menulist-button' behavior are extremely low.

Blink's 'square-button' (which behaves the same as our 'button-bevel') was only
used on 0.002% of the pages that they crawled, and again, the visual appearance
change we're making is minimal.


Further aligning '-moz-appearance' with '-webkit-appearance'


I've filed a bunch of bugs for the differences that 

Re: Intent to implement and ship: HTMLMediaElement.allowedToPlay

[Jan-Ivar Bruaroey]

On 8/6/18 4:03 PM, Jan-Ivar Bruaroey wrote:

On 8/1/18 3:36 AM, Chris Pearce wrote:
I think the only thing that you're missing is how vehemently some 
sites are in their desire to avoid the doorhanger prompt.


No, I'm also missing why we should listen to them.

If Netflix fights our doorhanger, then they're fighting our best attempt 
to whitelist them.


To clarify, I care about Netflix, which is why I question giving up on 
persisting autoplay for them, which is what allowedToPlay does.


AFAICT allowedToPlay's sole purpose is to avoid our doorhanger.

I've heard two reasons to fear our doorhanger:

  1. Sites doesn't want to get blocked.

This seems bogus, because "getting blocked" appears no different from 
avoiding the prompt with allowedToPlay. Both prevent the prompt.


Try it yourself: https://jsfiddle.net/jib1/rwkLaofx/show
Press "Don't Allow", then click anywhere on the page to play.

In other words, users aren't blocking audio, only un-gestured audio, 
which shouldn't matter to sites who already avoid it with allowedToPlay.


Also, allowedToPlay will never suddenly return true if used to suppress 
the prompt, because we have no other whitelisting strategy.


  2. User testing shows many users don't understand the prompt.

This one makes sense to me. If avoiding our one-time prompt matters more 
to them than autoplay itself, it's a sign our prompt isn't great. We 
should fix that, not help sites opt out.



Here's my take on our prompt:

I love that we went with a visible user agent feature instead of 
breaking the web. Even the permission part, partly. The management part.


But the prompt itself is too complicated. It's hard to glean how little 
is at stake: delaying audio by a mere click in many cases.


Try the fiddle again, ignore the prompt and just click somewhere on the 
page. Tone.


I think we need to rephrase this as a helpful user agent:

 _/\_
||
| Wanna hear sound ? |
||
|No|   Yes   |
`'
or
 _/\___
|  |
|  Sound blocked.  |
|  |
|  Don't | Thanks  |
`--'

Then have the user agent set the permission wisely.

By putting the agent in charge, we might even get away with a path to 
whitelisting without a prompt, where the user agent implicitly turns the 
permission on for well-behaved sites after users have interacted 
sufficiently with gesture-driven audio, without signs of distress.


This seems similar to Google's engagement system, except it's visible, 
so users can override the agent should it get it wrong, since it's still 
permission-based at heart.


Then allowedToPlay might make sense.

Thoughts?

.: Jan-Ivar :.


cpearce.


.: Jan-Ivar :.

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