Re: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

[Boris Zbarsky]

On 5/3/18 6:21 PM, Karl Tomlinson wrote:

I didn't understand why he was highlighting "order of object
tear-down", nor why he was implying that only "VERY fine-grained"
knowledge was a problem.


Alex, depending on whether he's speaking with his TAG hat or Google hat 
on, is either trying to figure out whether there is a problem with the 
spec or trying to justify Google shipping a particular behavior.  I'm 
not quite sure which hat he's wearing here.



He does seem to have misunderstood that there is a problem to fix.
But I assume the way forward here is to help the WG find a
solution that works.  What is the advantage of explaining the
situation to Alex?


As a TAG member, he can work with the TAG to explain to the WG that 
their current spec is not acceptable, assuming he's convinced on that.


With his Google hat on, he can make similar arguments internally about 
Chrome's implementation.


So if there is in fact a problem still remaining, convincing Alex that 
it's there is pretty valuable.  Having him convinced it doesn't exist is 
actively harmful as far as getting it fixed goes.



Should specifications instead just focus on observable behavior,
and leave it to implementations to optimize and to reclaim
resources that are no longer required?


Generally speaking, yes.  That said, specifications should be really 
clear on which resources are no longer required, if possible.



Are you aware of any guidance I could reference, if advocating
this?  (The WG has been very keen to make this normative.)


If there is no difference in observable behavior, what would a normative 
requirement mean?  And if there _is_ a difference in observable 
behavior, then of course the actual observable behavior that 
implementors need to implement needs to be specced normatively; this 
doesn't require saying anything about GC.



Perhaps it would be best to just have an informative section
explaining design decisions made for the sake of making resource
reclamation possible, such as lack of graph introspection.


This would definitely be useful.


Perhaps
it would also be helpful to have some informative reminders to
implementations re what GC must not affect.


Yes, that would be helpful.


If the whole normative AudioNode lifetime section were dropped
then this would clearly be an implementation issue rather than a
spec issue.


Assuming there is no observable behavior involved (other than memory 
usage), right?



The history here is:


Thank you for the summary.  That was helpful.  One thing I'm not 100% 
clear on at this point: are there spec issues that can lead to 
observable GC, or are we just talking about implementation bugs that 
make GC observable now?


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

Re: Proposed W3C Charter: Devices and Sensors Working Group

[L. David Baron]

On Thursday 2018-05-03 09:26 -0500, Tom Ritter wrote:
> On Thu, May 3, 2018 at 2:00 AM, Anne van Kesteren  wrote:
> > On Thu, May 3, 2018 at 12:51 AM, L. David Baron  wrote:
> >> Please reply to this thread if you think there's something we should
> >> say as part of this charter review, or if you think we should
> >> support or oppose it.
> >
> > Perhaps I've missed something, but I feel like we never resolved the
> > security question around high-resolution sensors. If I haven't missed
> > anything, I suggest we say we're still skeptical about exposing these
> > to the web.
> 
> Yea, I'm concerned about this as well.

On the flip side, sensor APIs are offered by mobile (and to some
degree desktop) operating systems and widely used by apps running on
them, and there's clear demand for having them on the Web.  So I
think it seems worth having a clear venue for that discussion, which
would suggest that it's good to have the discussion in the scope of
the working group.

I'm inclined to think that if we want to suggest changes to address
this security/privacy issue, we should be suggesting clarifying the
success criteria for the working group so that these issues are
clearly considered, and making it more explicitly OK for the group
to decide not to produce some of its deliverables.

The final paragraph of section "1. Goals" already says a bit here,
as does the third paragraph of "2.1 Success Criteria", but perhaps
there's more to say, perhaps by making not producing a spec
explicitly OK in both "2.1 Success Criteria" and "3. Deliverables"?
And perhaps something in there should also explicitly mention the
difficulty of properly informing the user in order to obtain
informed consent for the real risks underlying the sensors, or
something like that?


Or do you instead think that some of the deliverables should be
removed from the charter because they're not likely to succeed?  If
so, which?

-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: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

[Robert O'Callahan]

I read the threads you referenced and the latest spec, and I think you're
absolutely right about everything :-).

On Fri, May 4, 2018 at 10:21 AM, Karl Tomlinson  wrote:

> Thank you for taking a look, Boris.  I'm quite unclear how any of
> the changes proposed in the [[March F2F resolution]] comment would
> resolve the issue, and so I expect not.
>
> [[March F2F resolution]]
> https://github.com/WebAudio/web-audio-api/issues/1471#
> issuecomment-376223916


I wonder what that resolution entails since the spec changes haven't
happened yet.

However, it sounds like it's heading in the wrong direction. Rather than
trying to fix the description of AudioNode lifetimes, the entire section
should be deleted.

He does seem to have misunderstood that there is a problem to fix.
> But I assume the way forward here is to help the WG find a
> solution that works.  What is the advantage of explaining the
> situation to Alex?
>

AIUI If you can't convince someone on the WG that there is problem to fix,
but you can convince someone on the TAG, then they can require the WG to
fix it.

I'm happy to query the F2F resolution, but I wonder which is the
> best way to resolve this.
>
> Is having web specifications try to describe object lifetimes
> helpful, or is it just over-prescribing?
>

I think it's very dangerous. If those descriptions are normative then it's
easy to accidentally make GC observable. If they're not normative then they
confuse implementors and users into accidentally treating them as normative.

Should specifications instead just focus on observable behavior,
> and leave it to implementations to optimize and to reclaim
> resources that are no longer required?
>

Yes. People need to understand that GC is purely an optimization.

Perhaps it would be best to just have an informative section
> explaining design decisions made for the sake of making resource
> reclamation possible, such as lack of graph introspection.  Perhaps
> it would also be helpful to have some informative reminders to
> implementations re what GC must not affect.
>

Yes.


> If the whole normative AudioNode lifetime section were dropped
> then this would clearly be an implementation issue rather than a
> spec issue.
>

Yes!

Maybe I can help by writing a blog post or something...

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Timed Text Working Group

[L. David Baron]

On Thursday 2018-05-03 08:56 +0200, Anne van Kesteren wrote:
> On Thu, May 3, 2018 at 12:42 AM, L. David Baron  wrote:
> >   Timed Text Working Group
> >   https://www.w3.org/2018/04/proposed-tt-charter-2018.html
> 
> What does
> 
> # The Group is expected to produce annual updates for the Recommendation
> # with previously unspecified features.
> 
> mean?

I think it means that the group is supposed to publish a new
Recommendation each year (i.e., do maintenance work on the spec),
and can add new features to each one, all within the current
charter.  I admit "previously unspecified features" is awkward
wording, though.

-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: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

[L. David Baron]

On Friday 2018-05-04 10:21 +1200, Karl Tomlinson wrote:
> Is having web specifications try to describe object lifetimes
> helpful, or is it just over-prescribing?
> 
> Should specifications instead just focus on observable behavior,
> and leave it to implementations to optimize and to reclaim
> resources that are no longer required?
> 
> Are you aware of any guidance I could reference, if advocating
> this?  (The WG has been very keen to make this normative.)

Without digging too far into this specific case, I can attempt to
offer some answers to the general questions:

There is design guidance here, in a document published by the W3C
Technical Architecture Group:
https://w3ctag.github.io/design-principles/#js-gc
that garbage collection should not be observable.

Ensuring that GC isn't observable sometimes does require normative
descriptions of minimum object lifetimes, such as in
https://github.com/w3c/permissions/issues/170 , but generally
normative descriptions of maximum object lifetimes shouldn't be
needed.

That said, in general it's useful for specifications to give
informative explanations of the design decisions that led to the
current specification (since that helps future maintenance of the
specification, and also likely helps implementors contribute to that
maintenance).

It's also generally useful for specifications to give informative
implementation advice when there are things worth pointing out that
an implementor might not realize immediately.

I'd like to specifications have both sorts of informative sections
substantially more often than they do today.

> Perhaps it would be best to just have an informative section
> explaining design decisions made for the sake of making resource
> reclamation possible, such as lack of graph introspection.  Perhaps
> it would also be helpful to have some informative reminders to
> implementations re what GC must not affect.

These both sound useful, as I mentioned above.

-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

Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

[Karl Tomlinson]

Boris Zbarsky writes:

> On 5/2/18 5:21 AM, Karl Tomlinson wrote:
>> [[AudioNode Lifetime]] https://github.com/WebAudio/web-audio-api/issues/1471
>
> I've read through that thread, but I'm still a little unclear on
> where thing stand.  With the latest proposal, can there be
> observable situations where the output sound depends on GC timing?

Thank you for taking a look, Boris.  I'm quite unclear how any of
the changes proposed in the [[March F2F resolution]] comment would
resolve the issue, and so I expect not.

[[March F2F resolution]]
https://github.com/WebAudio/web-audio-api/issues/1471#issuecomment-376223916

> If so, that doesn't sound acceptable.  It also sounds to me like
> Alex Russell in
> https://github.com/WebAudio/web-audio-api/issues/1471#issuecomment-362604396
> didn't believe there was an observable sound difference possible.
> If one is possible, we should communicate this to him very
> clearly

The spec says that when a node is deleted, it will disconnect
itself from other nodes.  This disconnection definitely can lead
to observable sound differences, if the node can be deleted.  The
spec is unclear on whether a node with observable connections can
be deleted, but there is certainly reason to interpret it in this
way and members of the working group were doing so.  If anything,
the March F2F resolution seems to reinforce this view.

I was also quite unclear as to the point of Alex's comment.
I didn't understand why he was highlighting "order of object
tear-down", nor why he was implying that only "VERY fine-grained"
knowledge was a problem.

I'm not clear as to exactly what he was referring with
"@joeberkovitz's change to cause the spec to not discuss GC", but
changing the spec to not discuss GC would certainly resolve the
issue.  My take-away was that Alex was advocating no behavior
changes on GC.

He does seem to have misunderstood that there is a problem to fix.
But I assume the way forward here is to help the WG find a
solution that works.  What is the advantage of explaining the
situation to Alex?

I'm happy to query the F2F resolution, but I wonder which is the
best way to resolve this.

Is having web specifications try to describe object lifetimes
helpful, or is it just over-prescribing?

Should specifications instead just focus on observable behavior,
and leave it to implementations to optimize and to reclaim
resources that are no longer required?

Are you aware of any guidance I could reference, if advocating
this?  (The WG has been very keen to make this normative.)

Perhaps it would be best to just have an informative section
explaining design decisions made for the sake of making resource
reclamation possible, such as lack of graph introspection.  Perhaps
it would also be helpful to have some informative reminders to
implementations re what GC must not affect.

If the whole normative AudioNode lifetime section were dropped
then this would clearly be an implementation issue rather than a
spec issue.

The history here is:

  Initially the #lifetime-AudioNode section was only informative,
  providing some hints to the implementation re situations when GC
  must not be performed.  These were not a complete list.
  At the same time, implementations had bugs that made GC
  observable, but this was not usually noticed in general Web
  Audio usage.  These implementation bugs were fixable.

  An API/model was designed to support [[dynamic AudioWorkletNode
  lifetime]].  While not directly saying so at the time AFAIK,
  this API/model essentially depends on the implementation bugs to
  work as intended.  This was stated much [[later]].

  WG pressure in response to the [[dynamic AudioWorkletNode
  lifetime]] led to the #lifetime-AudioNode section being made
  [[normative]].  Subsequent additions were made to make it more
  comprehensive.  This made the existing implementation bugs very
  much spec bugs.

  The bugs are now very noticeable in typical AudioWorkletNode
  usage.

[[dynamic AudioWorkletNode lifetime]]
https://github.com/WebAudio/web-audio-api/pull/959#issuecomment-260979231

[[later]]
https://github.com/WebAudio/web-audio-api/issues/1453#issuecomment-349340594

[[normative]]
https://github.com/WebAudio/web-audio-api/pull/1161#issuecomment-284499700
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

[Jonathan Kew]

On 03/05/2018 00:57, Emma Humphries wrote:

To summarize, when you are releasing a feature that "rides behind a 
flag", on the bug for the feature:


* set the behind-pref flag to +
* set the qa-verify flag to ?
* note the bug in the Firefox Feature Trello board

We expect qa-verify to be set to + before enabling prefs on features.


I don't see a flag "qa-verify" in bugzilla; was this possibly a typo for 
"qe-verify"?


Thanks,

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

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

[Robert Helmer]

On Thu, May 3, 2018 at 11:57 AM, Adam Roach  wrote:
> On 5/3/18 12:18 PM, Nicholas Alexander wrote:
>>
>> Not all features are feasible to ship behind feature flags.
>
>
> I'm pretty sure the proposed policy isn't intended to change anything
> regarding features that ship without associated feature flags, nor is it
> trying to get more features to ship behind flags than currently do. It's
> just trying to rationalize a single, more managable process for those that
> *do* ship behind flags.
>
> /a

I agree that not every single feature is appropriate to ship behind a
feature flag, since the cost to maintain parallel implementations can
be huge, and has implications on things like the size of the
application and updates. In addition, if you look at
e10s/stylo/webrender we've set up parallel testing infrastructure,
which needs to be maintained for quite a while even after we've
enabled the feature.

We did however consider the benefits to be worth the complexity for
even the very large and complex projects mentioned above, and there
are many downsides and risks to not using a phased roll-out approach
(which can be done without feature flags), so I'd be interested in
continuing this discussion in a separate thread.

For this specific proposal, the only change I'd suggest is that we
should move away from the term "Pref Flip" in favor of "Feature Flag",
since (as evidenced in this thread so far) the latter is the more
standard industry term.

I also think there's an argument to be made that the pref system on
Firefox Desktop is not the right system for implementing feature flags
in general, but I'll leave that for a separate thread as well.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Announcing MozillaBuild 3.2 Release

[Ryan VanderMeulen]

MozillaBuild 3.2 is a minor update to version 3.1.1 mostly focusing on
updating a few of the bundled components to newer versions.
https://ftp.mozilla.org/pub/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe

Important changes since version 3.1.1:
* Updated Python2 to version 2.7.15 and Python3 to version 3.6.5.
* Updated nodejs to version 8.11.1 & npm version 5.6.0.
* Re-arranged the directory structure so more components live within a
centralized /bin directory, which is particularly useful for additional
tools people may want to easily put somewhere in their PATH.
* Other updates to various included components.
  - Mercurial updated to version 4.5.3.
  - The fsmonitor Mercurial extension is now enabled by default.

Full Release Notes:
https://docs.google.com/document/d/1OIJC7_-Y2xZh7CkXmi0fvz75f4ABP_W9-l0gZrAgJ1g/edit?usp=sharing

Enjoy!

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

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

[Adam Roach]

On 5/3/18 12:18 PM, Nicholas Alexander wrote:

Not all features are feasible to ship behind feature flags.


I'm pretty sure the proposed policy isn't intended to change anything 
regarding features that ship without associated feature flags, nor is it 
trying to get more features to ship behind flags than currently do. It's 
just trying to rationalize a single, more managable process for those 
that *do* ship behind flags.


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

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

[Nicholas Alexander]

On Wed, May 2, 2018 at 4:57 PM, Emma Humphries  wrote:

> Hello,
>
> We control enabling many features and changes to Firefox using preferences.
>
> Program and Release management as well as PI need a better view of this.
>
> We've written a new policy which you can read on our nascent bug-handling
> mini-site:
>
> https://github.com/mozilla/bug-handling/blob/master/
> policy/feature-flags.md
>
> To summarize, when you are releasing a feature that "rides behind a flag",
> on the bug for the feature:
>
> * set the behind-pref flag to +
> * set the qa-verify flag to ?
> * note the bug in the Firefox Feature Trello board
>
> We expect qa-verify to be set to + before enabling prefs on features.
>
> We'll be going over this at two upcoming meetings, with Reese's and JoeH's
> teams.
>
> There are two, known open questions to resolve on the policy:
>
> * Features developed over multiple releases with individual patches not
> verifiable by external testing (passing unit tests, but not integration
> tests) such as Hello and WebRTC
> * Features are often turned on in Nightly, ignoring prefs using compiler
> directives, and kept off in Beta and Release. Is this the right thing to
> do, or should we be flipping prefs from on to off when going from Nightly
> to Beta and forwards?
>

Not all features are feasible to ship behind feature flags.  Fennec
features that interact with the OS directly, in particular, can sometimes
just be all or nothing; and I would anticipate that things that interact
directly with newer App stores (iOS features, say, or Windows Store
features in the future) will become more common.  We can't have a policy
that fights against that trend.

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

Re: Maintenance work on perf-html.io, planned for May 3 at 8am PDT, small downtime planned

[Julien Wajsberg]

hi,

This is now over. Please contact  Markus, Greg or myself if you find 
anything not working properly after the switch.


Have a nice end of day !
--
Julien

Le 02/05/2018 à 16:50, Julien Wajsberg a écrit :

Hi,

Tomorrow we'll move perf-html.io to a new home.

As part of this switch we'll chance the DNS servers so that they point 
to the new hosting at netlify.com. This should be painless.


However as part of the process we also need to generate new TLS 
certificates, and we can do this only once the DNS switch is done. 
That's why we'll have a small downtime until the new certificates are 
set up.


In case of a bigger issue we'll rollback to the old hosting and 
postpone the switch.


Please follow Bug 1455605 to know more.

Have a nice day !


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

Re: Proposed W3C Charter: Devices and Sensors Working Group

[Tom Ritter]

On Thu, May 3, 2018 at 2:00 AM, Anne van Kesteren  wrote:
> On Thu, May 3, 2018 at 12:51 AM, L. David Baron  wrote:
>> Please reply to this thread if you think there's something we should
>> say as part of this charter review, or if you think we should
>> support or oppose it.
>
> Perhaps I've missed something, but I feel like we never resolved the
> security question around high-resolution sensors. If I haven't missed
> anything, I suggest we say we're still skeptical about exposing these
> to the web.

Yea, I'm concerned about this as well.

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

Intent to unship: File.lastModifiedDate

[Andrea Marchesini]

This attribute is not part of the FileAPI spec and it has been marked as
deprecated in bug 1048291 the 31st of May 2016.

It's currently used by the 0.01% of the pages:

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2018-04-30=__none__!__none__!__none___channel_version=nightly%252F61=USE_COUNTER2_DEPRECATED_FileLastModifiedDate_PAGE_channel_version=null=*=Firefox=1_keys=submissions_date=2018-03-12=0=1_submission_date=0

Currently only Chrome and Firefox support this attribute.

Firefox bug: 1458883.
Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=839372
WPT: https://github.com/w3c/web-platform-tests/pull/10821
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to explore: A declarative low level graphics API that has a simple mapping to CSS

[Joe Walker]

We’ve evaluated the Metalhead proposal and decided not to proceed with it.

Metalhead proposed a really interesting architecture that could plug into
existing web frameworks to increase frame rates, however by by-passing the
DOM, the proposal had the potential to be misused to remove more of the
semantic nature of the web than we are happy with, so we think that avenues
like DOM ChangeList are more fruitful avenue right now.

I’d like to thank Victor for his work on thinking though these ideas and
the innovative proposal.

Thanks for your interest.

Joe

On Tue, May 1, 2018 at 11:35 AM Victor Porof  wrote:

> Hello again :)
>
> Appreciate the great feedback so far!
>
> So I'd like to clear a few things up. There are many unknowns here which
> need exploring before moving further. Particularly we want to retain as
> much of the semantic model of the web while still allowing native-like
> frame rates.
>
> I'd like to spend some time breaking the document up and listing things we
> can do to preserve as much of the semantic model as we can, so please hold
> off for a bit while I do that.
>
> Thanks everyone!
> Victor
>
>
> On Mon, Apr 30, 2018 at 7:03 PM, Victor Porof  wrote:
>
>> Hey folks,
>>
>> Last quarter I've been drafting a roadmap to explore the advantages of a
>> new web API, fundamentally different from the DOM. It's aiming to expose
>> similar core web features, but with predictible cost and performance, in a
>> declarative immediate-mode manner.
>>
>> This research was driven by a desire to reconcile the growing set of
>> differences between today's development practices and existing browser
>> APIs. At the very least, "the UI is a function of state" is a preferred
>> abstraction trend, different from what browsers directly provide yet
>> incredibly prevalent among modern frameworks, so it's worth discussing the
>> implications.
>>
>> "Project Metalhead" is a proposed vector to address that disconnect. It's
>> an alternative to canvas 2D and WebGL, which:
>> * retains accessibility and internationalisation
>> * efficiently renders a direct mapping of existing CSS primitives
>> * supports form controls with native look and feel
>> * makes it easier for web apps to live inside web workers
>> * is specifically designed to work well with frameworks employing a
>> virtual DOM (e.g. React)
>> * can give Mozilla the driving seat for the next round of web performance
>> wins
>>
>> The proposed core graphics API is just a subset of the bigger
>> architectural solution. Investigation is required in order to understand
>> exactly how accessibility, layout and other existing browser behaviour can
>> be a concrete part of this new API. Prior research has given possible but
>> not definitive answers towards making sure there's no room for unintended
>> loss of user control.
>>
>> Obviously such a vector takes us into currently unknown territory, which
>> I'd like us to explore before moving further. I've written a document
>> describing the roadmap, along with details about a proof of concept
>> technical implementation in more detail:
>> https://docs.google.com/document/d/1YLM1_jlTKYvNa04rEHWw6RBEFQO5aAd8vd-S3yXJjI8
>> There's a lot of info there, so be sure to check out the FAQ, alternatives
>> and implementation. The document is open to everyone at Mozilla, but if you
>> need access to it let me know.
>>
>> Here's a video showcasing the expected performance improvements in
>> action: https://www.youtube.com/watch?v=kDrUfmXLrIU
>>
>> Among other things, the above demo is showing WebRender rendering content
>> running in browsers other than Firefox, powered by a proof of concept of
>> the proposed API. This approach intends to mimic a real world native
>> implementation across various browsers, instead of just a simple polyfill.
>>
>> I'd love getting some opinions and a roadmap review for this. Even though
>> what we have right now is a technically flawed proof of concept
>> implementation and incomplete solution, is it worth pursuing this further?
>>
>> If anyone's interested, I'd also be happy to have a conversation on vidyo
>> about how everything works in more detail.
>>
>> Thanks!
>> Victor
>>
>> *This proposal has been circulating outside of browser-arch last week; in
>> the hopes of getting broader feedback I'm posting it here instead.
>> Apologies if you've seen it already.*
>>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Devices and Sensors Working Group

[Anne van Kesteren]

On Thu, May 3, 2018 at 12:51 AM, L. David Baron  wrote:
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.

Perhaps I've missed something, but I feel like we never resolved the
security question around high-resolution sensors. If I haven't missed
anything, I suggest we say we're still skeptical about exposing these
to the web.


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

Re: Proposed W3C Charter: Timed Text Working Group

[Anne van Kesteren]

On Thu, May 3, 2018 at 12:42 AM, L. David Baron  wrote:
>   Timed Text Working Group
>   https://www.w3.org/2018/04/proposed-tt-charter-2018.html

What does

# The Group is expected to produce annual updates for the Recommendation
# with previously unspecified features.

mean?


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