The first attempt at the fix used XRE_IsE10sParentProcess() to enable the mitigation in child processes and in the main process only when e10s is disabled.
Now I realize using XRE_IsE10sParentProcess() is problematic because 1) it reads prefs and is being called of the main thread, but prefs should only be read on the main thread and 2) it is being called very early in startup (see stack below.).
I've just posted a new fix that doesn't have this problem, but doesn't enable the mitigation for the non-e10s case. Not support e10s seems OK at this time because on Mac, non-e10s is not supported. We did have some ESR60 issues that disabled e10s for screen reader compatibility, but that did not include Mac. I will look into a follow-up fix for the non-e10s case. One solution is to enable the mitigation all the time in the parent process, but I think we should make sure the perf difference is negligible first.
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
* frame #0 XUL`mozilla::BrowserTabsRemoteAutostart() at nsAppRunner.cpp:4929
frame #1 XUL`XRE_IsE10sParentProcess() at nsAppRunner.cpp:4865
frame #2 XUL`mozilla::CycleCollectedJSRuntime::CycleCollectedJSRuntime() at CycleCollectedJSRuntime.cpp:493
frame #3 XUL`XPCJSRuntime::XPCJSRuntime() at XPCJSRuntime.cpp:2948
frame #4 XUL`XPCJSRuntime::XPCJSRuntime() at XPCJSRuntime.cpp:2963
frame #5 XUL`XPCJSContext::CreateRuntime() at XPCJSContext.cpp:1067
frame #6 XUL`mozilla::CycleCollectedJSContext::Initialize() at CycleCollectedJSContext.cpp:156
frame #7 XUL`XPCJSContext::Initialize() at XPCJSContext.cpp:1075
frame #8 XUL`XPCJSContext::NewXPCJSContext() at XPCJSContext.cpp:1269
frame #9 XUL`nsXPConnect::nsXPConnect() at nsXPConnect.cpp:75
frame #10 XUL`nsXPConnect::nsXPConnect() at nsXPConnect.cpp:67
frame #11 XUL`nsXPConnect::InitStatics() at nsXPConnect.cpp:127
frame #12 XUL`xpcModuleCtor() at XPCModule.cpp:11
frame #13 XUL`nsLayoutModuleInitialize() at nsLayoutModule.cpp:108
frame #14 XUL`nsComponentManagerImpl::Init() at nsComponentManager.cpp:493
frame #15 XUL`::NS_InitXPCOM(nsIServiceManager **, nsIFile *, nsIDirectoryServiceProvider *)() at XPCOMInit.cpp:446
frame #16 XUL`ScopedXPCOMStartup::Initialize() at nsAppRunner.cpp:1282
frame #17 XUL`XREMain::XRE_main() at nsAppRunner.cpp:4682
frame #18 XUL`XRE_main() at nsAppRunner.cpp:4767
frame #19 XUL`mozilla::BootstrapImpl::XRE_main() at Bootstrap.cpp:45
frame #20 firefox`do_main() at nsBrowserApp.cpp:212
frame #21 firefox`main() at nsBrowserApp.cpp:291
frame #22 libdyld.dylib`start()
Bug 1546544 Comment 50 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The first attempt at the fix used XRE_IsE10sParentProcess() to enable the mitigation in child processes and in the main process only when e10s is disabled.
Now I realize using XRE_IsE10sParentProcess() is problematic because 1) it reads prefs and is being called of the main thread, but prefs should only be read on the main thread and 2) it is being called very early in startup (see stack below.).
I've just posted a new fix that doesn't have this problem, but doesn't enable the mitigation for the non-e10s case. Not support e10s seems OK at this time because on Mac, non-e10s is not supported. We did have some ESR60 issues that disabled e10s for screen reader compatibility, but that did not include Mac. I will look into a follow-up fix for the non-e10s case. One solution is to enable the mitigation all the time in the parent process, but I think we should make sure the perf difference is negligible first.
````
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
* frame #0 XUL`mozilla::BrowserTabsRemoteAutostart() at nsAppRunner.cpp:4929
frame #1 XUL`XRE_IsE10sParentProcess() at nsAppRunner.cpp:4865
frame #2 XUL`mozilla::CycleCollectedJSRuntime::CycleCollectedJSRuntime() at CycleCollectedJSRuntime.cpp:493
frame #3 XUL`XPCJSRuntime::XPCJSRuntime() at XPCJSRuntime.cpp:2948
frame #4 XUL`XPCJSRuntime::XPCJSRuntime() at XPCJSRuntime.cpp:2963
frame #5 XUL`XPCJSContext::CreateRuntime() at XPCJSContext.cpp:1067
frame #6 XUL`mozilla::CycleCollectedJSContext::Initialize() at CycleCollectedJSContext.cpp:156
frame #7 XUL`XPCJSContext::Initialize() at XPCJSContext.cpp:1075
frame #8 XUL`XPCJSContext::NewXPCJSContext() at XPCJSContext.cpp:1269
frame #9 XUL`nsXPConnect::nsXPConnect() at nsXPConnect.cpp:75
frame #10 XUL`nsXPConnect::nsXPConnect() at nsXPConnect.cpp:67
frame #11 XUL`nsXPConnect::InitStatics() at nsXPConnect.cpp:127
frame #12 XUL`xpcModuleCtor() at XPCModule.cpp:11
frame #13 XUL`nsLayoutModuleInitialize() at nsLayoutModule.cpp:108
frame #14 XUL`nsComponentManagerImpl::Init() at nsComponentManager.cpp:493
frame #15 XUL`::NS_InitXPCOM(nsIServiceManager **, nsIFile *, nsIDirectoryServiceProvider *)() at XPCOMInit.cpp:446
frame #16 XUL`ScopedXPCOMStartup::Initialize() at nsAppRunner.cpp:1282
frame #17 XUL`XREMain::XRE_main() at nsAppRunner.cpp:4682
frame #18 XUL`XRE_main() at nsAppRunner.cpp:4767
frame #19 XUL`mozilla::BootstrapImpl::XRE_main() at Bootstrap.cpp:45
frame #20 firefox`do_main() at nsBrowserApp.cpp:212
frame #21 firefox`main() at nsBrowserApp.cpp:291
frame #22 libdyld.dylib`start()
````
The first attempt at the fix used XRE_IsE10sParentProcess() to enable the mitigation in child processes and in the main process only when e10s is disabled.
Now I realize using XRE_IsE10sParentProcess() is problematic because 1) it reads prefs and is being called of the main thread, but prefs should only be read on the main thread and 2) it is being called very early in startup (see stack below.).
I've just posted a new fix that doesn't have this problem, but doesn't enable the mitigation for the non-e10s case. Not supporting e10s seems OK at this time because, on Mac, non-e10s is not supported. We did have some ESR60 issues that disabled e10s for screen reader compatibility, but that did not include Mac. I will look into a follow-up fix for the non-e10s case. One solution is to enable the mitigation all the time in the parent process, but I think we should make sure the perf difference is negligible first.
````
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
* frame #0 XUL`mozilla::BrowserTabsRemoteAutostart() at nsAppRunner.cpp:4929
frame #1 XUL`XRE_IsE10sParentProcess() at nsAppRunner.cpp:4865
frame #2 XUL`mozilla::CycleCollectedJSRuntime::CycleCollectedJSRuntime() at CycleCollectedJSRuntime.cpp:493
frame #3 XUL`XPCJSRuntime::XPCJSRuntime() at XPCJSRuntime.cpp:2948
frame #4 XUL`XPCJSRuntime::XPCJSRuntime() at XPCJSRuntime.cpp:2963
frame #5 XUL`XPCJSContext::CreateRuntime() at XPCJSContext.cpp:1067
frame #6 XUL`mozilla::CycleCollectedJSContext::Initialize() at CycleCollectedJSContext.cpp:156
frame #7 XUL`XPCJSContext::Initialize() at XPCJSContext.cpp:1075
frame #8 XUL`XPCJSContext::NewXPCJSContext() at XPCJSContext.cpp:1269
frame #9 XUL`nsXPConnect::nsXPConnect() at nsXPConnect.cpp:75
frame #10 XUL`nsXPConnect::nsXPConnect() at nsXPConnect.cpp:67
frame #11 XUL`nsXPConnect::InitStatics() at nsXPConnect.cpp:127
frame #12 XUL`xpcModuleCtor() at XPCModule.cpp:11
frame #13 XUL`nsLayoutModuleInitialize() at nsLayoutModule.cpp:108
frame #14 XUL`nsComponentManagerImpl::Init() at nsComponentManager.cpp:493
frame #15 XUL`::NS_InitXPCOM(nsIServiceManager **, nsIFile *, nsIDirectoryServiceProvider *)() at XPCOMInit.cpp:446
frame #16 XUL`ScopedXPCOMStartup::Initialize() at nsAppRunner.cpp:1282
frame #17 XUL`XREMain::XRE_main() at nsAppRunner.cpp:4682
frame #18 XUL`XRE_main() at nsAppRunner.cpp:4767
frame #19 XUL`mozilla::BootstrapImpl::XRE_main() at Bootstrap.cpp:45
frame #20 firefox`do_main() at nsBrowserApp.cpp:212
frame #21 firefox`main() at nsBrowserApp.cpp:291
frame #22 libdyld.dylib`start()
````