Re: Intent to ship: block audible autoplay media intervention

On Wednesday, July 4, 2018 at 11:38:21 AM UTC+12, Chris Pearce wrote: > Intent to ship: block audible autoplay media intervention > > SUMMARY: > > We intend to change the behaviour of HTMLMediaElement to block autoplay of > audible audio and video in Firefox on desktop and mobile. > > We are

Re: C++ standards proposal for a embedding library

Ted wrote: >Honestly I think at this point growth of the C++ standard library is an >anti-feature. The committee should figure out how to get modules specified >(which I understand is a difficult thing, I'm not trying to minimize the >work there) so that tooling can be built to provide a

Re: PSA: Major preference service architecture changes inbound

I have filed bug 1477436: "Preferences::Get* is not threadsafe/is main thread only" https://bugzilla.mozilla.org/show_bug.cgi?id=1477436 On Fri, Jul 20, 2018 at 11:36 AM, Eric Rahm wrote: > We *could* special case prefs with an appropriate data structure that works > in a thread-safe nature; as

Re: PSA: Major preference service architecture changes inbound

Since I have seen several people point out in this thread that there's *probably* code that excessively accesses prefs: You can easily assert the name and amount of different prefs that are read during whatever scenario you'd like to perform by adding to this test (or writing your own version of

Re: PSA: Major preference service architecture changes inbound

On Fri, Jul 20, 2018 at 11:53:22AM -0400, Ehsan Akhgari wrote: On Fri, Jul 20, 2018 at 5:00 AM, Jonathan Kew wrote: +1 to that. Our need for OMT access to prefs is only likely to grow, IMO, and we should just fix it once, so that any code (regardless of which thread(s) it may eventually run

Re: PSA: Major preference service architecture changes inbound

On Fri, Jul 20, 2018 at 10:00:22AM +0100, Jonathan Kew wrote: +1 to that. Our need for OMT access to prefs is only likely to grow, IMO, and we should just fix it once, so that any code (regardless of which thread(s) it may eventually run on) can trivially read prefs. Even if that means we

Re: PSA: Major preference service architecture changes inbound

We *could* special case prefs with an appropriate data structure that works in a thread-safe nature; as far as RWLock's go, we do have one in tree [1]. This has gone off the rails a bit from Kris' original announcement, which I'll reiterate: Watch out for prefs related bustage. Jeff, would you

Re: C++ standards proposal for a embedding library

Reading between the lines, it seems like the committee's aim is to take something that is widely understood and used, broadly capable, and in the big picture relatively well-defined (i.e. the Web), and incorporate it into the C++ standard by reference. The problem is that the *relationship of web

Re: C++ standards proposal for a embedding library

On Thu, Jul 19, 2018 at 5:35 PM, Mike Hommey wrote: > Other than everything that has already been said in this thread, > something bugs me with this proposal: a web view is a very UI thing. > And I don't think there's any proposal to add more basic UI elements > to the standard library. Not that

Re: PSA: Major preference service architecture changes inbound

Hi I believe that this change may be the caused of https://bugzilla.mozilla.org/show_bug.cgi?id=1477254 That is, the pref value set in all.js no longer overrides the default value set in StaticPrefs. The problem occurs mostly with e10s

Re: PSA: Major preference service architecture changes inbound

On Fri, Jul 20, 2018 at 5:00 AM, Jonathan Kew wrote: > On 20/07/2018 03:17, Jeff Gilbert wrote: > >> Using a classic read/write exclusive lock, we would only every contend >> on read+write or write+write, which are /rare/. >> > > Indeed, that's what I envisage we'd want. The -vast- majority of

Re: PSA: Major preference service architecture changes inbound

On 20/07/2018 03:17, Jeff Gilbert wrote: Using a classic read/write exclusive lock, we would only every contend on read+write or write+write, which are /rare/. Indeed, that's what I envisage we'd want. The -vast- majority of prefs access only involves reading values. We should be able to do

Intent to ship: Clear-Site-Data header

I intend to turn Clear-Site-Data header on by default in 63. The last remaining dependency bug is going to land today; we pass all the WPTs. It has been developed behind the dom.clearSiteData.enabled preference. Chrome has this feature enabled since 06-2017. Bug to turn on by default: bug