Decision owner for Rust usage in Gecko.

[Johnny Stenback]

Hey all,

Over the coming weeks/months/years we'll be adding more and more Rust code
into Gecko. As that work progresses (it's already in full swing in case you
haven't been paying attention) it'll become more and more important that we
collectively help ensure that we're being intentional in how this all rolls
into the code base. We want to ensure we end up with good ergonomics,
consistency, etc. IOW, we want the best possible end result out of this. To
help make that happen we now have a single decision maker for things
relating to Rust. That person is Ehsan Akhgari, who is also the module
owner of the recently created "C++/Rust usage, tools, and style" module [1].

IOW, going forward if you're working on using Rust code in more places,
doing build system changes around Rust (compiler versions, shared crates,
locations, etc), please get Ehsan to sign off on such changes.

Thanks,
Johnny

1:
https://wiki.mozilla.org/Modules/Core#C.2B.2B.2FRust_usage.2C_tools.2C_and_style

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

Re: Multiple content processes in Nightly

[Johnny Stenback]

WOOT! Very exciting to see this in nightly!


- jst

On Tue, Jan 24, 2017 at 2:48 AM, Gabor Krizsanits 
wrote:

> Hello everyone,
>
> After quite a few attempts and some more bug fixing the patch finally seem
> to stuck. Thanks for all the help! \o/
>
> Gabor
>
> On Thu, Nov 10, 2016 at 11:46 AM, Gabor Krizsanits <
> gkrizsan...@mozilla.com>
> wrote:
>
> > The patch has been backed out because of the merge. To be continued on
> > next Monday.
> > More info about the back-out: https://bugzilla.mozilla.org/
> > show_bug.cgi?id=1303113#c9
> >
> > -Gabor
> >
> > On Thu, Nov 10, 2016 at 1:29 AM, Blake Kaplan 
> wrote:
> >
> >> Hello everyone,
> >>
> >> We've been working on the e10s-multi project for a while now and are
> >> looking at turning on multiple content processes in Nightly. Our plan
> >> is to start with two content processes (compared to the single content
> >> process we currently use) and if that goes well, we'll start ramping
> >> up the number of content processes we use as well as playing with more
> >> exciting process allocation strategies. We are not yet planning to
> >> ride the trains.
> >>
> >> In order to turn on in Nightly, Gabor Krizsanits has been doing a ton
> >> of work to make sure our tests are green. We've had to disable a
> >> couple of them in e10s mode and for others we've been forcing them to
> >> use a single content process (to be clear, the tests themselves are
> >> broken with multiple content processes and the underlying code is
> >> not). We will be working on fixing the tests as we can as well as
> >> turning the disabled tests back on [1].
> >>
> >> We have two known bugs that we're enabling with:
> >>   * Service workers for the same origin can run simultaneously in
> >> multiple processes [2]. We expect the user-visible aspects of this bug
> >> to be limited to desktop notifications being duplicated (for each
> >> content process that has a bogus service worker running in it). bkelly
> >> is leading a team to fix this.
> >>
> >>   * DOM storage doesn't properly propagate changes to other processes
> >> [3]. This could cause web sites to misbehave. janv is working on
> >> fixing this.
> >>
> >> Let Gabor or me know if you have any concerns or comments and needinfo
> >> us on bugs that you run into.
> >>
> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1315042
> >> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1231208
> >> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=666724
> >> --
> >> Blake
> >> ___
> >> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Who loves multiple selection feature in editor?

[Johnny Stenback]

Unless we get clear buy-in from other browsers to support this I would vote
for removing this complexity out of Gecko.


- jst

On Mon, Dec 19, 2016 at 10:36 AM, Frederik Braun  wrote:

> On 19.12.2016 17:19, glazou wrote:
> > Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :
> >
> >> So, it might be better to stop supporting multiple selection only in
> >> editor if the feature is not so loved by users.
> >
> > We were already discussing this issue at Netscape 15 years ago but could
> not come up with a good solution at that time. Thanks for bringing it back,
> this could be the right time to finally solve it.
> >
> > Some existing use cases:
> >
> > 1. this is absolutely needed for table cell selection. Everyone
> extensively using tables uses multiple selection at some point.
> >
>
> I'm generally all for removing complexity and I hate to be a spoilsport.
>  But table cell selection is pretty useful (e.g., a full row, a full
> column and the possibility of removing a few here and there)
>
>
> > 2. Microsoft Word on all platforms and in general all commercial
> Whysiwyg Text editors allow multiple selection.
> >
> > 3. multiple selection is really cool if you think of images representing
> videoframes you select to edit/crop a video.
> >
> > 4. "search a text" often ends with a multiple selection of all
> occurrences of the pattern in the document
> >
> > On another hand, I think selection would benefit from a boolean
> attribute saying if the rendering engine allows or not multiple selection
> and if it does not, having shortcut mechanisms allowing to get rid of the
> onmipresent and painful getRangeAt(0). We do quite equivalent things when
> the selection is collapsed.
> >
> > 
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Johnny Stenback]

Excellent, thank you!


- jst

On Fri, Dec 2, 2016 at 7:28 AM, Andrew McCreight 
wrote:

> On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky  wrote:
>
> > If you want to get started before that, please make sure to
> >> file a bug on what you're doing before you start. That should avoid
> >> duplicating work.
> >>
> >
> > Is there an overall tracking bug people could check to see which things
> > are already filed or in-progress?
> >
>
> I filed bug 1321812 just now to use as a meta bug.
>
>
>
> >
> > -Boris
> >
> > P.S.  This is awesome.  ;)
> >
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Johnny Stenback]

Double indeed! Very cool to see this happening!

On a logistical note, do we have a meta bug that could track all the bugs
about labeling etc, so that we can hang individual bugs off of that one to
help avoid multiple bugs being filed and worked on for the same thing?

Thanks!


- jst

On Thu, Dec 1, 2016 at 8:31 PM, Kyle Huey  wrote:

> On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky  wrote:
> > P.S.  This is awesome.  ;)
>
> Indeed.  So glad this is finally happening.
>
> - Kyle
> ___
> 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: Proposed change to Commit Access Policy Level 3

[Johnny Stenback]

SGTM!

- jst


On Thu, Aug 4, 2016 at 8:57 AM, David Burns  wrote:
> Looks great to me!
>
> David
>
> On 4 August 2016 at 06:20, Mitchell Baker  wrote:
>
>> Over time we've made a series of exceptions to the level 3 requirements
>> for Sheriffs and this proposal addresses that.
>>
>>
>> The current Policy for level 3 is:
>>
>> Level 3 - Core Product Access
>>
>> Requirements: two vouchers - module owners or peers of code stored
>> at this level
>>
>>
>> The issue is that Sheriffs typically need level 3 access to fulfill their
>> roles.  But they aren't chosen based on number and quality of patches, so
>> often don't meet the current requirements.  Today we go through an
>> exception process.  The thinking is that this process is unneeded for a set
>> of people to whom we've delegated Sheriff authority.
>>
>>
>> The proposal is to change the text as follows:
>>
>> from:"module owners or peers of code stored at this level"
>> to:  "module owners or peers of code stored at this level or owners or
>> peers of the 'Tree Sheriffs' module."
>>
>>
>>
>> Mitchell
>> ___
>> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: e10s-multi is under way

[Johnny Stenback]

Super exciting to see this work officially kicked off! Can't wait to
see this ship to the masses!

Thanks,
Johnny

- jst


On Tue, Jun 28, 2016 at 4:39 PM, Blake Kaplan  wrote:
> Hello everybody,
>
> We're officially starting on the e10s-multi project to enable multiple child
> processes in Firefox. You can find more about the project (including our
> roadmap) at [1].
>
> Our first milestone is to fix bugs related to multiple content processes
> (we know, for example, that view source doesn't currently work). The list of
> bugs can be found by searching bugzilla for the whiteboard marking
> [e10s-multi:M1] [2]. If you know of a bug that should be considered, please
> mark its whiteboard with [e10s-multi:?] and we will triage it appropriately.
>
> Additionally, if there are components or features that need specific testing
> with a multiple content-process model, please file bugs and mark them for
> triage.
>
> Feel free to ask me or Gabor Krizsanits any questions.
>
> Thanks.
>
> [1] https://wiki.mozilla.org/Electrolysis/Multiple_content_processes
> [2] https://mzl.la/297iqN4
> --
> Blake Kaplan
> ___
> 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 remove:

[Johnny Stenback]

Agreed.

- jst


On Tue, Apr 26, 2016 at 7:42 AM, Boris Zbarsky  wrote:
> I think removing this is reasonable at this point
>
> -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: Are we in favour of implementing the client hints header?

[Johnny Stenback]

Based on what I know I'm not opposed to implementing this feature from
the point of view of whether this would be good for the web or not.
What I'd question is whether this is good use of our time given the
platform team's current focus on quality.

- jst


On Tue, Mar 8, 2016 at 3:21 PM, Martin Thomson  wrote:
> On Wed, Mar 9, 2016 at 6:42 AM, Jonas Sicking  wrote:
>> I know there's some concern that always sending CH with all requests
>> would generate too much header traffic which would be wasteful.
>
>
> We could limit the feature to h2.  (Which would also address the other
> request, which is to limit this to https://)
>
> I'm surprised that the CORS interaction hasn't been raised:
> https://github.com/httpwg/http-extensions/issues/141
> ___
> 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: Update on WebKit prefix support in Gecko.

[Johnny Stenback]

While maybe not super quick, this is a great update. Thanks Mike for
all the hard work you and your team have done on pushing hard on this,
and likewise a big thanks to those who have helped implement the
various aspects of this!

- jst


On Wed, Feb 17, 2016 at 9:11 PM, Mike Taylor  wrote:
> Howdy dev-platform (cross-posting fx-team for maximum synergy),
>
> A quick update on our progress of implementing the WebKit related deps of
> Bug 1170774.
>
> In Bug 1213126 we set layout.css.prefixes.webkit to true by default to let
> it ride the trains and see if anything exploded. Not surprisingly, some
> stuff blew up.
>
> So since Bug 1238827, we're restricting layout.css.prefixes.webkit=true to
> non-Release builds.
>
> (If you want to learn what layout.css.prefixes.webkit enables, check out Bug
> 1170789 and its CSS deps. One other DOM interface is behind the pref,
>
> Bug 717722: implement WebKitCSSMatrix
>
> This fixes a ton of mobile sites. The Compat Spec stuff was moved into the
> Geometry spec making WebKitCSSMatrix an alias of DOMMatrix (after changing a
> few things to make it compatible). Apple and Google have bugs on file to do
> this, which is cool.)
>
> The following are things that we discovered we needed to be compatible with
> the web once you support some WebKit prefixed stuff since turning on
> layout.css.prefixes.webkit.
>
> - Bug 1239799: Add support for "@media (-webkit-transform-3d)" as a media
> query for 3d transform support.
>
> Turns out some sites using older versions of Modernizr will only do 3d
> transforms if you support this. So now we do, and we've specced it:
> https://compat.spec.whatwg.org/#css-media-queries-webkit-transform-3d
>
> - Bug 1236979: send 'webkitTransitionEnd', 'webkitAnimationEnd', etc. events
> instead of their standard equivalents, if listeners only exist for prefixed
> event name.
>
> Lots of (mapping) sites break if you don't do this. And probably more things
> we don't know about. Edge, Safari, and Blink all do this, so now we do too.
> (Yes, it's gross and weird.) A PR is in progress to get this specced in DOM.
>
> - Bug 1241021: Support camel-cased and webkit-cased CSSStyleDeclaration
> attributes for getting & setting WebKit prefixed styles
>
> Some sites do things like $(foo).css('-webkit-bar', 'baz'). We found a lot
> of image sliders break if you don't support this. In order for that to work,
> you have to support setting/getting elm.style['WebkitTransition'] in
> addition to elm.style['webkitTransition'].
>
> But wait, there's more.
>
> - Bug 1246796: Add support for elm.style['-webkit-foo'] style CSSOM
> getters/setters.
>
> Yeah. Apparently every single browser except us supports this (for their own
> prefixes too). Fun.
>
> - Bug 1248444: Allow writing to cross origin style sheets
>
> All non-Gecko browsers will let you write to a 3rd party stylesheet via
> insertRule (even though CSSOM says this is a SecurityError). We need to do
> some careful research here to make sure we can safely do the same.
>
> - Bug 759568:  Implement -webkit-background-clip: text;
> - Bug 124: Implement -webkit-text-fill-color
> - Bug 1248708: Implement -webkit-text-stroke
>
> These three are all related to fancy typography effects that sites use with
> -webkit- prefixed gradients. If you support gradients but not these, you're
> gonna have a bad time™: https://cloudup.com/cVP9AppLMAv
>
> dholbert has a good proposal to ignore webkit-prefixed gradients if you find
> -webkit-background-clip: text in the same rule. That should allow us to ship
> enable our webkit support without being blocked on these three bugs (and
> without regressing Release's behavior for this typography gradient
> clipping). See Bug 1248785 for that.
>
> The following things have been disabled:
>
> - Bug 1249134: disable -webkit-appearance alias for now.
>
> The behavior between -moz-appearance and -webkit-appearance is too different
> to be useful. We have https://github.com/whatwg/compat/issues/6 filed to
> spec the way -webkit-appearance is used (and how designers rely on it for
> fancy forms), and once we're there we'll be following up with bugs against
> Gecko.
>
> - Bug 1237720: put "-webkit-min-device-pixel-ratio" behind it's own pref and
> disable it.
>
> Supporting this fixed a number of mobile sites, but unfortunately broke
> Google Docs on HiDPI devices. :( So it's disabled for now. Maybe it will
> come back one day.
>
> Things we've already shipped, or are riding the trains:
>
> - Bug 920734: window.orientation / orientationchange event support (44)
> - Bug 264412: element.innerText (45)
> - Bug 823483: Percentage max-width does not seem to affect contributions to
> intrinsic min-width (46)
>
> Lots and lots of sites are fixed as a result. \o/
>
> If you only use Release or Beta, consider using Nightly Fennec to see a lot
> of improvements. And please keep reporting strange bustage you see in Dev
> Edition or Nightly Desktop that is fixed by toggling
> 

Re: Splitting inner and outer windows

[Johnny Stenback]

\o/ This is a big deal, excellent to see this coming, and it's been a
long time coming (since ~2004 when we first created the notion of
inner and outer windows. Thanks for taking this on Kyle!

- jst


On Sat, Jan 30, 2016 at 4:04 PM, Kyle Huey  wrote:
> This has landed (and stuck) on inbound.
>
> - Kyle
>
> On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey  wrote:
>
>> Early in the next release cycle I plan to land a patch that will remove
>> nsPIDOMWindow in favor of two separate types for inner and outer windows
>> (fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter)  I'll also make
>> changes to the XPIDL interface hierarchy (effectively removing nsIDOMWindow
>> and introducing two new base interfaces for inner and outer windows) to
>> support this.  When the dust settles places that today use nsPIDOMWindow or
>> nsIDOMWindow will instead use a type that specifies, at compile time,
>> whether we have an inner or outer window.
>>
>> The actual methods exposed on nsPIDOMWindow will be carried over in almost
>> all cases.  Splitting the interface itself, or nsGlobalWindow, apart will
>> happen later.
>>
>> You can follow along in bug 1241764.
>>
>> - Kyle
>>
> ___
> 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: Thanks for all the great teamwork with the Sheriffs in 2015!

[Johnny Stenback]

Indeed, well done all around, thank you to all the sheriffs and
everyone who worked with the sheriffs, directly or indirectly, in
2015! Looking forward to a great 2016!

- jst


On Wed, Dec 30, 2015 at 8:32 AM, Lawrence Mandel  wrote:
> hear, hear! Thank you.
>
> Lawrence
>
> On Wed, Dec 30, 2015 at 9:27 AM, Kartikaya Gupta  wrote:
>
>> Yes, thank you to all the sheriffs for all their hard work!
>>
>> On Wed, Dec 30, 2015 at 9:19 AM, Carsten Book  wrote:
>> > Hi,
>> >
>> > Sheriffing is not just about Checkins, Uplifts and Backouts - its also a
>> > lot of teamwork with different Groups and our Community like Developers,
>> IT
>> > Teams and Release Engineering and a lot more to keep the trees up and
>> > running. And without this great teamwork our job would be nearly
>> impossible!
>> >
>> > So far in 2015 we had around:
>> >
>> > 56471 changesets with 336218 changes to 70807 files in mozilla-central
>> > and 4391 Bugs filed for intermittent failures (and a lot of them fixed).
>> >
>> > So thanks a lot for the great teamwork with YOU in 2015 - especially
>> also a
>> > great thanks to our Community Sheriffs like philor, nigelb and Aryx who
>> > done great work!
>> >
>> > I hope we can continue this great teamwork in 2016 and also the monthly
>> > sheriff report with interesting news from the sheriffs and how you can
>> > contribute will continue then :)
>> >
>> > Have a great start into 2016!
>> >
>> > Tomcat
>> > on behalf of the Sheriffs-Team
>> > ___
>> > 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: unowned orange by team

[Johnny Stenback]

On Wed, Dec 23, 2015 at 6:58 AM, James Graham  wrote:
> On 23/12/15 01:15, Ben Kelly wrote:
[...]
>> 10) https://bugzilla.mozilla.org/show_bug.cgi?id=1231798
>
>
> This is a web-platform-tests test which is an interesting case. De-facto I
> am on point for all problems in these tests, which is fine, but in practice
> there's a limited amount I can do. If the test is broken in some obvious way
> I can fix it, or I can disable it. In some cases I know the feature under
> test well enough to do something a bit more clever. But, in order to get the
> right fix, it would be better to loop in the people in the team responsible
> for the feature under test rather than just considering all wpt failures to
> ateam's responsibility.

I would certainly not expect the ateam or yourself to be responsible
for fixing all wpt failures. You should feel empowered to reach out to
engineering leads for areas where you've identified the underlying
implementation most likely being the cause of the failure as opposed
to the test itself or the harness!

And thanks for helping shepherd all these tests, highly valuable work!

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

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Johnny Stenback]

While deciding how much resources are available to complex
applications is far from an easy task, and one for which there's no
obvious best answer, at least not yet, I agree that giving developers
this bit of information is critical to enable exploring this space and
bring out the any remaining issues I too think we should do this.
Thanks for writing this up Luke!

- jst


On Tue, Sep 8, 2015 at 2:22 PM, Ben Kelly  wrote:
> FWIW, I also think we should implement this.  The clamping seems like a
> reasonable way to be conservative given the fingerprinting concerns.
>
> On Tue, Sep 8, 2015 at 3:21 PM, Luke Wagner  wrote:
>
>> Since the original m.d.p thread on hardwareConcurrency last year:
>>
>> https://groups.google.com/d/topic/mozilla.dev.platform/QnhfUVw9jCI/discussion
>> the landscape has shifted (as always) and I think we should reevaluate
>> and implement this feature.
>>
>> What hasn't changed are the arguments, made in the original thread,
>> that hardwareConcurrency is a clumsy way to decide how many workers to
>> create and can lead to the creation of too many workers in various
>> scenarios (e.g., multiple tabs all attempting to saturate all the cores,
>> cores vs. hyperthreads).
>>
>> What has changed is the appearance of more compelling use cases.  In
>> particular, the upcoming support for SharedArrayBuffer [1][2] allows
>> Emscripten to compile pthreads [3] applications, which has been the #1
>> compile-to-web feature request over the last few years. Specifically,
>> native
>> game engines find the number of logical cores on the machine (using APIs
>> present in C++11, etc.), and use a number of threads based on that (often
>> adjusted, and they have a lot of experience tuning this). They would like
>> to
>> do the same on the web, and Chrome and Safari already let them. In the
>> absence of hardwareConcurrency, developers are forced to resort to either
>> hardcoding a constant number of workers or using a polyfill library [4]
>> that
>> estimates the number of cores. Unfortunately, the polyfill takes a few
>> seconds (hurting startup time) and produces inaccurate results (based on
>> evaluations from multiple parties) [5]. Thus, while hardwareConcurrency
>> isn't ideal, it's strictly better than what developers have now in Firefox.
>>
>> Moreover, I don't think the applicability of hardwareConcurrency is
>> limited to compile-to-web uses.  I think all the use cases we're
>> seeing now from compiled native apps will manifest in JS apps further
>> down the line as worker usage becomes more commonplace and
>> applications grow more demanding.  As in many other cases, I think
>> games are serving as a catalyst here, proving what's possible and
>> paving the way for fleets of non-game applications.
>>
>> But will the existence of hardwareConcurrency encourage bad behavior
>> in every-day web browsing?  I don't think so.  First of all,
>> hardwareConcurrency is meant to help good actors who want to
>> ensure a good experience for their users.  Bad actors can already
>> saturate all your cores with Workers. Thus, as Worker (mis)use
>> becomes more widespread on the Web, it seems inevitable we'll need
>> to do some form of Worker throttling (via thread priority or
>> SuspendThread/pthread_kill) of background/invisible windows *anyway*;
>> it seems like the only reason we haven't had to do this already is
>> because Workers just aren't used that much in normal web apps.  For
>> good actors, though, it is possible to mitigate some of the clumsiness
>> of hardwareConcurrency: using SharedWorkers to detect the "same
>> app open in many tabs" case; using the PageVisibility API to pause
>> work when not visible (which will likely happen anyway in frame-driven
>> applications based on requestAnimationFrame throttling of background
>> tabs).  Lastly, for neither good nor bad actors, I think the hazard of
>> casual/widespread use is more limited by the hurdles of using workers
>> at all (w/ or w/o SharedArrayBuffer).
>>
>> Will we get stuck with hardwareConcurrency forever?  I don't think
>> so.  Farther down the line, as more web apps take advantage of workers
>> and we find real examples of CPU contention for which throttling
>> mitigations aren't sufficient, we will be motivated to improve and
>> propose a more responsive API.  However, I don't think we can design
>> that API now: we don't have the use cases to evaluate the API against.
>> This is the basic Web evolutionary strategy.
>>
>> On the subject of fingerprinting: as stated above, core count can
>> already be roughly measured [4].  While the extra precision and speed
>> of hardwareConcurrency does make fingerprinting somewhat easier, as
>> we've done with other features, we need to weigh the value to users
>> against information revealed.  In this case, it seems like the ratio
>> is pretty heavily weighted toward the value.
>>
>> On a more technical detail: WebKit and Chromium have both shipped,
>> 

Re: PSA: multipart/x-mixed-replace images will soon be restricted to MJPEG

[Johnny Stenback]

I'd say this is far enough out towards extreme edge case land that we
can be a bit more aggressive here compared to general feature
removals. So agreed.

On Fri, Jan 2, 2015 at 1:52 PM, Seth Fowler s...@mozilla.com wrote:

 On Jan 2, 2015, at 7:16 AM, L. David Baron dba...@dbaron.org wrote:
 IMHO, I haven't seen is a weak argument. When we remove features
 that are exposed to the web in some form, it's always a good idea to
 gather some telemetry first so that we know what the actual impact
 will probably be (there is some bias to the Telemetry audience
 already, of course). Let's see that we have data instead of
 assumptions and do not run into surprises. People have been known to
 do crazy things in some corners of the web.

 I don't think that' necessary for features that aren't supported
 across other browser engines, which I believe is the case here.

 That is true. IE does not support this feature at all.

 I completely concur that in general we should gather telemetry before 
 removing a feature that’s exposed to the web, but I just don’t see it as 
 adding much value for this *particular* case.

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



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

Re: Intent to implement: Sub-resource Integrity (SRI)

[Johnny Stenback]

LGTM, what's the status wrt other browsers supporting this?

Thanks,
Johnny

On Tue, Dec 30, 2014 at 9:40 PM, Francois Marier franc...@mozilla.com wrote:
 Summary: Allow web authors to add integrity checks to sub-resources.

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

 Spec: http://www.w3.org/TR/SRI/

 Platforms: all

 Estimated or target release: Q1 of 2015

 Preference behind which this will be implemented:
 security.subResourceIntegrity.enable

 Background:

 The best way to explain this is through an example. If you have the
 following:

 script src=https://code.jquery.com/jquery-1.10.2.min.js;

 integrity=ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=application/javascript

 then the browser will refuse to execute the script if someone has gained
 access to the jQuery servers and has replaced the script with a
 malicious one (the hash won't match the expected one).

 Our initial implementation will be limited to integrity checks for
 script tags and stylesheets. While the spec is still evolving, we expect
 to cover everything that ends up in level 1 of the spec.

 Feel free to contact me if you have any questions.

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



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

Re: What are the most important new APIs to document in Q3/Q4?

[Johnny Stenback]

ServiceWorkers! We're in the midst of implementing right now, current
plan being to have all the pieces done and in m-c by end of Q3, with
further work happening on refinement and performance work etc after
that. The spec is still in flux, but I would expect it to be in a
documentable form later this quarter or in Q4.

Thanks,
Johnny

On 06/26/2014 06:09 AM, Eric Shepherd wrote:
 Hi! The docs team is trying to build our schedule for the next quarter
 or two, and part of that is deciding which APIs to spend lots of our
 time writing about. I'd like to know what y'all think the most important
 APIs are for docs attention in the next few months.
 
 Here are a few possibilities we've heard of. I'd like your opinions on
 which of these are the most important -- for Mozilla, the open Web, and
 of course for Firefox OS. PLEASE feel free to suggest others. I'm sure
 there are APIs we don't know about at all, or aren't on this list.
 
 DO NOT ASSUME WE KNOW YOUR API EXISTS. Not even if it should be obvious.
 Especially not then. :)
 
 * WebRTC
 * WebGL (our current docs are very weak and out of date)
 * Service Workers
 * Shared Workers
 * Web Activities
 * ??
 
 What are your top five APIs that you think need documentation attention?
 For the purposes of this discussion, consider any that you know aren't
 already documented (you don't have to search MDN -- if there happen to
 be any you're annoyed by lack of/sucky docs, list 'em). Also consider
 any that will land in Q3 or Q4.
 
 We will collate the input we get to build our plan for the next quarter
 and to start a rough sketch for Q4!
 
 Thanks in advance!
 

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

Re: XPIDL Promises

[Johnny Stenback]

Maybe, but also, generally speaking we shouldn't be using .idl files for
b2g any more, at least not writing new ones. We should be implementing
things with WebIDL. What's the case where we need/want this here?

On 7/30/2013 7:51 AM, Andreas Gal wrote:
 
 Yeah, I just saw that grepping through the tree. Both completely
 independent, too. On the upside, this might solve Jan's problem.
 
 Andreas
 
 Boris Zbarsky wrote:
 On 7/30/13 7:36 AM, Andreas Gal wrote:
 For that we would have to implement Promise via IDL. Definitely
 possible. All you need is a bit IDL and some JS that implements it. It
 would be a lot slower than the jsm since it wraps into C++ objects that
 call into JS, but in most cases that doesn't really matter.

 Wait.  Why do we have multiple Promise implementations now?  :(

 -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

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