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
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
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
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
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
5 matches
Mail list logo