Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-29 Thread Boris Zbarsky
On 5/29/16 6:21 PM, Boris Zbarsky wrote: I wanted to make it clear that we're getting something that's OK to use without synchronization, but maybe that's redundant and we can just have a dom::GetJSContext() or something. dom::JSContext() would have ambiguity issues, of course. I don't have sup

Re: Intent to deprecate: MacOS 10.6-10.8 support

2016-05-29 Thread Chris Pearce
So, given that users won't be able to install Firefox on unsupported versions of MacOSX, and unsupported users won't be upgraded, can we proceed to remove all the nsCocoaFeatures::On[Mountain]LionOrLater() calls in Firefox 49 and just assume everywhere that MacOSX specific Gecko code is running on

Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-29 Thread Boris Zbarsky
On 5/29/16 6:17 PM, Kyle Huey wrote: Do we really need the ForThread part? I wanted to make it clear that we're getting something that's OK to use without synchronization, but maybe that's redundant and we can just have a dom::GetJSContext() or something. dom::JSContext() would have ambigui

Re: How to name our JSContext getter(s): let the bikeshed begin

2016-05-29 Thread Kyle Huey
Do we really need the ForThread part? Is the long term plan to merge JSRuntime and JSContext, or are they going to remain distinct indefinitely? - Kyle On Sun, May 29, 2016 at 6:10 PM, Boris Zbarsky wrote: > We currently have the following functions in nsContentUtils for getting > various JSCon

How to name our JSContext getter(s): let the bikeshed begin

2016-05-29 Thread Boris Zbarsky
We currently have the following functions in nsContentUtils for getting various JSContexts: GetSafeJSContext() GetDefaultJSContextForThread() RootingCx() RootingCxForThread() We also have workers::GetCurrentThreadJSContext() for use on workers only. Now that we're about to move to only having