Closed Bug 1306327 Opened 8 years ago Closed 7 years ago

Build an XPCOM startup API specifically for the Firefox stub which doesn't need the XPCOM glue

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla53

People

(Reporter: benjamin, Assigned: glandium)

References

(Blocks 2 open bugs)

Details

Attachments

(12 files, 3 obsolete files)

58 bytes, text/x-review-board-request
glandium
: review+
glandium
: checkin+
Details
59 bytes, text/x-review-board-request
cpearce
: review+
Details
59 bytes, text/x-review-board-request
froydnj
: review+
Details
59 bytes, text/x-review-board-request
benjamin
: review+
Details
59 bytes, text/x-review-board-request
benjamin
: review+
Details
59 bytes, text/x-review-board-request
benjamin
: review+
Details
59 bytes, text/x-review-board-request
billm
: review+
Details
59 bytes, text/x-review-board-request
benjamin
: review+
Details
59 bytes, text/x-review-board-request
benjamin
: review+
Details
59 bytes, text/x-review-board-request
benjamin
: review+
Details
59 bytes, text/x-review-board-request
benjamin
: review+
Details
59 bytes, text/x-review-board-request
benjamin
: review+
Details
      No description provided.
Blocks: 1306329
Details: the Firefox stub doesn't need to do very much. And so xul.dll should provide a class that does exactly what the stub needs, and no more. And once the stub gets that class, nobody else can have it.

As part of this, the Firefox stub will stop linking against the XPCOM glue.
FWIW, I think this should happen in two steps:
- Move most of nsBrowserApp.cpp to some glue library (mozglue, probably).
- Then cf. comment 1.

Reason for the first step is that we have essentially a copy of nsBrowserApp.cpp per app, and each of them that is not Firefox's is actually outdated. Moving Firefox's to a glue library would open the door for other apps to use that instead of their own copy of nsBrowserApp.cpp, which would allow comment 1 to happen for them too.
There are two basic functions here:

1) for the stub(s) that don't link directly against libxul, the code to preload/load it; that currently lives in xpcom/glue/standalone/nsXPCOMGlue.cpp
 
2) the actual processing of argv/argc and launching into the main loop, or the xpcshell loop, or the content/plugin loop. My plan is to move this code into libxul itself and expose it via a single C export and a virtual class.
Comment on attachment 8810997 [details]
Bug 1306327 - build a mozilla::Bootstrap API which is used by the various stubs to initialize gecko and run the main loop. Sandboxing init, which is statically linked, still runs in each stub separately.

https://reviewboard.mozilla.org/r/93250/#review94838

This would have been easier to review if unrelated things were done in separate patches. Like adding uses of UniquePtr. There are also some code moves or removals that might be better done separately. The most extreme case, to me is the removal of InitializeBinder. I understand that you don't want to make the effort for b2g/gonk, but that should be done in an entirely separate bug in the dependency tree of bug 1306391.

::: ipc/app/MozillaRuntimeMain.cpp:112
(Diff revision 2)
> +#if defined(XP_WIN) && defined(MOZ_SANDBOX)
> +  // We need to initialize the sandbox TargetServices before InitXPCOMGlue
> +  // because we might need the sandbox broker to give access to some files.
> +  if (IsSandboxedProcess()) {
> +    sandbox::TargetServices* targetServices = sandboxing::GetInitializedTargetServices();
> +    if (!targetServices) {
> +      return 255;
> +    }
> +    bootstrap->SetSandboxTarget(targetServices);
> +    bootstrap->SetSandboxLogger(mozilla::sandboxing::ProvideLogFunction);
> +  }
> +#endif
> +#if !defined(MOZ_WIDGET_ANDROID) && !defined(MOZ_WIDGET_GONK) && defined(MOZ_PLUGIN_CONTAINER)
> +  // On desktop, the GMPLoader lives in plugin-container, so that its
> +  // code can be covered by an EME/GMP vendor's voucher.
> +  bootstrap->SetGMPLoader(mozilla::gmp::CreateGMPLoader(MakeSandboxStarter()));
> +#endif
> +
> +  return bootstrap->ContentProcessMain(argc, argv);

It would be better to do all this initialization from a function in the xpcom glue, avoiding the repetition with nsBrowserApp.cpp.

::: toolkit/xre/Bootstrap.cpp:77
(Diff revision 2)
> +  }
> +
> +  virtual void SetXREDirectory(const char* directory) override;
> +  virtual void SetBlocklistEnabled(bool enabled) override
> +  {
> +    mBlocklistEnabled = enabled;

It seems to me this should only do something if HAS_DLL_BLOCKLIST.

::: toolkit/xre/Bootstrap.cpp:214
(Diff revision 2)
> +#if defined(XP_WIN) && defined(MOZ_SANDBOX)
> +    appData->sandboxBrokerServices = mSandboxBroker;
> +#endif

You're fixing a separate bug here, which is that -app doesn't initialize the sandbox, but you're also not erroring out if the broker services weren't initialized.

On the long term, I think both -app and no -app should use the same code path, with a bool keeping track of whether appData needs to be XRE_FreeAppData'ed or not. Or you could do that in a (separate) preparation patch.

::: toolkit/xre/Bootstrap.cpp:252
(Diff revision 2)
> +
> +#if defined(XP_WIN) && defined(MOZ_SANDBOX)
> +  appData.sandboxBrokerServices = mSandboxBroker;
> +#endif
> +
> +#if defined(XP_WIN) && defined(MOZ_SANDBOX) && defined(MOZ_CONTENT_SANDBOX)

This could be a #if defined(MOZ_CONTENT_SANDBOX) enclosed in the #if defined(XP_WIN) && defined(MOZ_SANDBOX) above.

::: toolkit/xre/Bootstrap.cpp:310
(Diff revision 2)
> +  shellData.sandboxBrokerServices = mSandboxBroker;
> +#endif
> +  return XRE_XPCShellMain(argc, argv, envp, &shellData);
> +}
> +
> +static bool gBootstrapInitialized;

You could move this static variable inside the function.

::: xpcom/glue/standalone/nsXPCOMGlue.cpp:34
(Diff revision 2)
> +#include <glib.h>
> +#endif
> +
> +namespace mozilla {
> +
> +typedef void (*NSFuncPtr)();

Since there's only one function you load now, and it has its own type, there's no real need for this generic type anymore.

::: xpcom/glue/standalone/nsXPCOMGlue.cpp
(Diff revision 2)
> -  ~GSliceInit() {
> -#if MOZ_WIDGET_GTK == 2
> -    if (sTop) {
> -      auto XRE_GlibInit = (void (*)(void)) GetSymbol(sTop->libHandle,
> -        "XRE_GlibInit");
> -      // Initialize glib enough for G_SLICE to have an effect before it is unset.
> -      // unset.
> -      XRE_GlibInit();
> -    }
> -#endif
> -    if (!mHadGSlice) {
> -      unsetenv("G_SLICE");
> -    }
> -  }

Why are you removing this? It's pretty much needed.

Overall, this is going in the right direction. However, while I understand what you're trying to do with Firefox, I don't feel like we need to break comm-central and b2g straight ahead. By which I mean that the XPCOM glue code should stay for now. Firefox just wouldn't use it, and use the new function(s) instead.
As per comment 2, things would go smoother for comm-central and b2g if the nsBrowserApp.cpp patch essentially removed most of it and called a couple functions. What currently remains in nsBrowserApp.cpp is still too large to my taste, and will bitrot in everything that is not Firefox. I can be convinced this could be deferred to a followup, but I'm also afraid it would just mean it won't happen.
Attachment #8810997 - Flags: review?(mh+mozilla)
Comment on attachment 8812597 [details]
Bug 1306327 part B - build a mozilla::Bootstrap API which is used by the various stubs to initialize gecko and run the main loop. Sandboxing init, which is statically linked, still runs in each stub separately.

https://reviewboard.mozilla.org/r/94272/#review95154

::: mozglue/android/APKOpen.h:11
(Diff revision 1)
>  #define APKOpen_h
>  
>  #include <jni.h>
>  #include <pthread.h>
>  
> -#ifndef NS_EXPORT
> +#ifndef APKOPEN_EXPORT

s/NS_EXPORT/APKOPEN_EXPORT/ should be its own separate patch.

::: mozglue/android/APKOpen.cpp:498
(Diff revision 1)
>    }
>    if (loadGeckoLibs(argv[i]) != SUCCESS) {
>      return FAILURE;
>    }
>  
> -  void (*fXRE_SetProcessType)(char*);
> +  bootstrap->AndroidChildMain(0, 0, argc, argv);

you want -1, -1 here instead of 0, 0. It might be better to change the arguments order, making the fds last, and use default values.
Attachment #8812597 - Flags: review?(mh+mozilla)
> ::: ipc/app/MozillaRuntimeMain.cpp:112

> > +  return bootstrap->ContentProcessMain(argc, argv);
> 
> It would be better to do all this initialization from a function in the
> xpcom glue, avoiding the repetition with nsBrowserApp.cpp.

I started on this (sharing with plugin-container code) and gave up because the decision-making about what type of process to launch and what sandboxing to start was very type-specific. I'm skeptical that I can do better right now.

> ::: xpcom/glue/standalone/nsXPCOMGlue.cpp
> (Diff revision 2)
> > -  ~GSliceInit() {
> > -#if MOZ_WIDGET_GTK == 2
> > -    if (sTop) {
> > -      auto XRE_GlibInit = (void (*)(void)) GetSymbol(sTop->libHandle,
> > -        "XRE_GlibInit");
> > -      // Initialize glib enough for G_SLICE to have an effect before it is unset.
> > -      // unset.
> > -      XRE_GlibInit();
> > -    }
> > -#endif
> > -    if (!mHadGSlice) {
> > -      unsetenv("G_SLICE");
> > -    }
> > -  }
> 
> Why are you removing this? It's pretty much needed.

Would it be ok to remove this completely? It's a performance optimization that only affects the GTK2 config that we no longer ship (I guess we still support it for various Linux distros LTS?). If we need to keep it, what's the right flag to build a GTK2 build so I can test this?

glandium, froydnj, and I emailed about the comm-central/B2G situation and since we believe that porting comm-central will not be onerous we're not going to attempt a transition period/build flag since that would make this very difficult to test and land.
Flags: needinfo?(mh+mozilla)
Depends on: 1321593
(In reply to Benjamin Smedberg [:bsmedberg] from comment #9)
> Would it be ok to remove this completely? It's a performance optimization
> that only affects the GTK2 config that we no longer ship (I guess we still
> support it for various Linux distros LTS?).

Only a part of the code you're removing is GTK2-specific. Unsetting G_SLICE thing is still necessary even on GTK3. However, as you say, LTS distros still build the GTK2 code, but I don't know how long that will keep working (gfx people would know).

> If we need to keep it, what's the right flag to build a GTK2 build so I can test this?

--enable-default-toolkit=cairo-gtk2
Flags: needinfo?(mh+mozilla)
Attachment #8810997 - Attachment is obsolete: true
Comment on attachment 8816925 [details]
Bug 1306327 part A - NS_EXPORT macro in APKOpen.h can conflict with nscore.h: rename it to APKOPEN_EXPORT to avoid build issues,

https://reviewboard.mozilla.org/r/97412/#review98028
Attachment #8816925 - Flags: review?(mh+mozilla) → review+
Keywords: leave-open
Pushed by bsmedberg@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bd67a0d056e4
part A - NS_EXPORT macro in APKOpen.h can conflict with nscore.h: rename it to APKOPEN_EXPORT to avoid build issues on a CLOSED TREE, r=glandium
Depends on: 1323313
No longer depends on: 1323313
Depends on: 1329932
Comment on attachment 8812597 [details]
Bug 1306327 part B - build a mozilla::Bootstrap API which is used by the various stubs to initialize gecko and run the main loop. Sandboxing init, which is statically linked, still runs in each stub separately.

https://reviewboard.mozilla.org/r/94272/#review98094

Following is what I had written before the holidays as a review, before I started to dissect this large patch into smaller parts to make sense of it. Then I started to do some preliminary cleanup, and since I wanted to strip down nsBrowserApp.cpp much more than you did, I also started doing that.
I'm not there yet, but since we're getting close to merge day, let's already go with a minimalist change that allows to remove most of the XPCOM glue. It doesn't go as far as you did on the bootstrap API, but on the other hand, it should allow to remove the same amount of glue, while being much comprehensible to review (because it essentially keeps the same API, significantly reducing the size of the patch)
This doesn't touch B2G and iOS ; I was waiting to actually finish a real bootstrap API before finalizing that.
However, fuzzing should be kept working with my patches (this patch breaks it).

FWIW, this patch also failed to build on most platforms.

Anyways, patch queue incoming.

::: ipc/app/MozillaRuntimeMain.cpp:91
(Diff revision 2)
> +  if (!bootstrap) {
> +    return 1;
> +  }
> +
> +#if defined(XP_WIN) && defined(MOZ_SANDBOX)
> +  // We need to initialize the sandbox TargetServices before InitXPCOMGlue

There is no InitXPCOMGlue call in this function, making the comment weird.

::: mozglue/android/APKOpen.cpp:251
(Diff revision 2)
> +  XRE_GetBootstrap(b);
> +  if (!b) {
> +    __android_log_print(ANDROID_LOG_ERROR, "GeckoLibLoad", "XRE_GetBootstrap failed");
> +    return FAILURE;
> +  }
> +  bootstrap = b.release();

You could just make bootstrap a Bootstrap::UniquePtr, use swap() here, and use reset() later instead of Dispose() followed by assigning nullptr. That would even allow making Dispose() private/protected.

::: toolkit/xre/Bootstrap.h:1
(Diff revision 2)
> +/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */

Both this file and Bootstrap.cpp contain CRLF line endings.

::: toolkit/xre/Bootstrap.cpp:283
(Diff revision 2)
> +    appData.directory = appSubdir;
> +  }
> +
> +#ifdef LIBFUZZER
> +  if (getenv("LIBFUZZER"))
> +    XRE_LibFuzzerSetMain(argc, argv, libfuzzer_main);

The libfuzzer_main function is in nsBrowserApp.cpp, so this obviously will fail to build.

::: toolkit/xre/nsEmbedFunctions.cpp:325
(Diff revision 2)
>  namespace {
>  class LinuxSandboxStarter : public mozilla::gmp::SandboxStarter {
> -  LinuxSandboxStarter() { }
>  public:
> -  static SandboxStarter* Make() {
> +  LinuxSandboxStarter() { }
> +  static UniquePtr<LinuxSandboxStarter> Make() {

s/LinuxSandboxStart/SandboxStart/

::: xpcom/glue/standalone/nsXPCOMGlue.h:27
(Diff revision 2)
>  
>  /**
>   * Initialize the XPCOM glue by dynamically linking against the XPCOM
>   * shared library indicated by xpcomFile.
>   */
> -extern "C" NS_HIDDEN_(nsresult) XPCOMGlueStartup(const char* aXPCOMFile);
> +Bootstrap::UniquePtr XPCOMGlueStartup(const char* aXPCOMFile);

NS_HIDDEN_(Bootstrap::UniquePtr)

::: xpcom/glue/standalone/nsXPCOMGlue.cpp:76
(Diff revision 2)
> -static NSFuncPtr
> +static GetBootstrapType
>  GetSymbol(LibHandleType aLibHandle, const char* aSymbol)

This should either stay a generic GetSymbol function returning a generic function type based on a libhandle and symbol name, or this should be a specific GetBootstrap (or some other name) function returning a GetBootstrapType based on a libhandle and no symbol name.

::: xpcom/glue/standalone/nsXPCOMGlue.cpp:349
(Diff revision 2)
>  
> -nsresult
> +Bootstrap::UniquePtr
>  XPCOMGlueStartup(const char* aXPCOMFile)
>  {
>  #ifdef MOZ_GSLICE_INIT
> -  GSliceInit gSliceInit;
> +  GSliceInit();

This will run both the constructor and destructor on this line, which defeats the whole point of using RAII here to keep the G_SLICE env variable while loading libraries and unsetting it once done.
Attachment #8812597 - Flags: review?(mh+mozilla)
Comment on attachment 8816926 [details]
Bug 1306327 part C - Make the IPDL unit tests use the new Bootstrap API,

https://reviewboard.mozilla.org/r/97414/#review104144
Attachment #8816926 - Flags: review?(mh+mozilla)
Assignee: nobody → mh+mozilla
Attachment #8816925 - Flags: checkin+
Attachment #8812597 - Attachment is obsolete: true
Attachment #8816926 - Attachment is obsolete: true
Comment on attachment 8825365 [details]
Bug 1306327 - Use UniquePtr for CreateGMPLoader.

https://reviewboard.mozilla.org/r/103526/#review104154

::: toolkit/xre/nsEmbedFunctions.cpp:335
(Diff revision 1)
>  #if defined (XP_LINUX) && defined(MOZ_GMP_SANDBOX)
>  namespace {
>  class LinuxSandboxStarter : public mozilla::gmp::SandboxStarter {
> -  LinuxSandboxStarter() { }
>  public:
> -  static SandboxStarter* Make() {
> +  LinuxSandboxStarter() { }

Can the constructor not remain private, so that callers are forced to use the Make() function to construct?
Attachment #8825365 - Flags: review?(cpearce) → review+
Comment on attachment 8825366 [details]
Bug 1306327 - Remove XPCOMGlueEnablePreload.

https://reviewboard.mozilla.org/r/103528/#review104160
Attachment #8825366 - Flags: review?(nfroyd) → review+
Comment on attachment 8825365 [details]
Bug 1306327 - Use UniquePtr for CreateGMPLoader.

I guess you meant making it private, which works, but requires an overly long friend definition.
Attachment #8825365 - Flags: review+ → review?(cpearce)
Comment on attachment 8825370 [details]
Bug 1306327 - Avoid call to NS_DebugBreak from content_process_main().

https://reviewboard.mozilla.org/r/103536/#review104374
Attachment #8825370 - Flags: review?(wmccloskey) → review+
Comment on attachment 8825365 [details]
Bug 1306327 - Use UniquePtr for CreateGMPLoader.

https://reviewboard.mozilla.org/r/103526/#review104382

Ah, so MakeUnique<> calls the public constructor, which is why it needed to be made public in the previous iteration.
Attachment #8825365 - Flags: review?(cpearce) → review+
(In reply to Chris Pearce (:cpearce) from comment #45)
> Comment on attachment 8825365 [details]
> Bug 1306327 - Use UniquePtr for CreateGMPLoader.
> 
> https://reviewboard.mozilla.org/r/103526/#review104382
> 
> Ah, so MakeUnique<> calls the public constructor, which is why it needed to
> be made public in the previous iteration.

It turns out the static analysis builds don't like the friend declaration, so we'll have to go with keeping it public.

https://treeherder.mozilla.org/logviewer.html#?job_id=67753321&repo=try&lineNumber=7547
(In reply to Mike Hommey [:glandium] from comment #46)
> (In reply to Chris Pearce (:cpearce) from comment #45)
> > Comment on attachment 8825365 [details]
> > Bug 1306327 - Use UniquePtr for CreateGMPLoader.
> > 
> > https://reviewboard.mozilla.org/r/103526/#review104382
> > 
> > Ah, so MakeUnique<> calls the public constructor, which is why it needed to
> > be made public in the previous iteration.
> 
> It turns out the static analysis builds don't like the friend declaration,
> so we'll have to go with keeping it public.
> 
> https://treeherder.mozilla.org/logviewer.
> html#?job_id=67753321&repo=try&lineNumber=7547

Apparently, what's happening is that clang has a hard time figuring namespaces, and prefixing MakeUnique with mozilla:: fixes it.
Comment on attachment 8825367 [details]
Bug 1306327 - Don't set XREAppData.xreDirectory from nsBrowserApp.cpp.

https://reviewboard.mozilla.org/r/103530/#review104696
Attachment #8825367 - Flags: review?(benjamin) → review+
Comment on attachment 8825368 [details]
Bug 1306327 - Remove the flags argument to XRE_main.

https://reviewboard.mozilla.org/r/103532/#review104698
Attachment #8825368 - Flags: review?(benjamin) → review+
Comment on attachment 8825369 [details]
Bug 1306327 - Remove NS_XRE_DLL_BLOCKLIST_ENABLED.

https://reviewboard.mozilla.org/r/103534/#review104702
Attachment #8825369 - Flags: review?(benjamin) → review+
Comment on attachment 8825371 [details]
Bug 1306327 - Add a new XRE Bootstrap API that wraps all the XRE methods.

https://reviewboard.mozilla.org/r/103538/#review105180

::: toolkit/xre/Bootstrap.h:112
(Diff revision 3)
> + * Creates and returns the singleton instnace of the bootstrap object.
> + * @param `b` is an outparam. We use a parameter and not a return value
> + *        because MSVC doesn't let us return a c++ class from a function with
> + *        "C" linkage. On failure this will be null.
> + * @note This function may only be called once and will crash if called again.
> + * @note this function will initialize logging and set the XPCOM "main thread".

This doesn't appear to be true in this patch.

::: toolkit/xre/Bootstrap.h:113
(Diff revision 3)
> + * @param `b` is an outparam. We use a parameter and not a return value
> + *        because MSVC doesn't let us return a c++ class from a function with
> + *        "C" linkage. On failure this will be null.
> + * @note This function may only be called once and will crash if called again.
> + * @note this function will initialize logging and set the XPCOM "main thread".
> + * @note Use the virtual destructor on the returned object before exiting

This comment doesn't seem to match the UniquePtr behavior, which still uses Dispose, and the destructor is protected.
Attachment #8825371 - Flags: review?(benjamin)
Comment on attachment 8825372 [details]
Bug 1306327 - Use the new XRE Bootstrap API in Desktop Firefox.

https://reviewboard.mozilla.org/r/103540/#review105190

::: browser/app/nsBrowserApp.cpp:164
(Diff revision 3)
>  #endif
>  
>    return false;
>  }
>  
> -XRE_GetFileFromPathType XRE_GetFileFromPath;
> +Bootstrap::UniquePtr bootstrap;

Haven't read the rest of the patch series yet, but if this stays a global it should really be gBootstrap here. r=me with that change or ping me if you disagree or it's irrelevant because it's fixed later in the patch series.
Attachment #8825372 - Flags: review?(benjamin) → review+
Comment on attachment 8825373 [details]
Bug 1306327 - Use the new XRE Bootstrap API in Firefox for Android.

https://reviewboard.mozilla.org/r/103542/#review105194

::: mozglue/android/APKOpen.cpp:171
(Diff revision 3)
>  Java_org_mozilla_gecko_GeckoThread_registerUiThread(JNIEnv*, jclass)
>  {
>      sJavaUiThread = pthread_self();
>  }
>  
> -static void * xul_handle = nullptr;
> +Bootstrap::UniquePtr bootstrap;

gBootstrap, similar to desktop.
Attachment #8825373 - Flags: review?(benjamin) → review+
Comment on attachment 8825374 [details]
Bug 1306327 - Move reading application.ini to XRE_main.

https://reviewboard.mozilla.org/r/103544/#review105272

::: browser/app/nsBrowserApp.cpp:219
(Diff revision 3)
> -      return 255;
> -    }
> -
> -    appini->GetParent(getter_AddRefs(appData.directory));
>    } else {
> -    // no -app flag so we use the compiled-in app data
> +    config.appData = &sAppData;

I think this comment is helpful and I'd like to keep it.
Attachment #8825374 - Flags: review?(benjamin) → review+
Comment on attachment 8825375 [details]
Bug 1306327 - Remove everything related to frozen functions from the XPCOM glue.

https://reviewboard.mozilla.org/r/103546/#review105274
Attachment #8825375 - Flags: review?(benjamin) → review+
(In reply to Benjamin Smedberg [:bsmedberg] from comment #62)
> > + * @note this function will initialize logging and set the XPCOM "main thread".
> 
> This doesn't appear to be true in this patch.
> 
> > + * @note Use the virtual destructor on the returned object before exiting
> 
> This comment doesn't seem to match the UniquePtr behavior, which still uses
> Dispose, and the destructor is protected.

It turns out I just forgot to remove those comments. They came from your original patch. They don't apply anymore.
Comment on attachment 8825371 [details]
Bug 1306327 - Add a new XRE Bootstrap API that wraps all the XRE methods.

https://reviewboard.mozilla.org/r/103538/#review105924

Whoops sorry about that!
Attachment #8825371 - Flags: review?(benjamin) → review+
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/64dcf6b92394
Use UniquePtr for CreateGMPLoader. r=cpearce
https://hg.mozilla.org/integration/autoland/rev/b92d791582e5
Remove XPCOMGlueEnablePreload. r=froydnj
https://hg.mozilla.org/integration/autoland/rev/398e907e9a9c
Don't set XREAppData.xreDirectory from nsBrowserApp.cpp. r=bsmedberg
https://hg.mozilla.org/integration/autoland/rev/d6d7a6e9a3d9
Remove the flags argument to XRE_main. r=bsmedberg
https://hg.mozilla.org/integration/autoland/rev/8e583d30ce98
Remove NS_XRE_DLL_BLOCKLIST_ENABLED. r=bsmedberg
https://hg.mozilla.org/integration/autoland/rev/be999ce0e4fe
Avoid call to NS_DebugBreak from content_process_main(). r=billm
https://hg.mozilla.org/integration/autoland/rev/a7dac14f91df
Add a new XRE Bootstrap API that wraps all the XRE methods. r=bsmedberg
https://hg.mozilla.org/integration/autoland/rev/2a0edcbaebee
Use the new XRE Bootstrap API in Desktop Firefox. r=bsmedberg
https://hg.mozilla.org/integration/autoland/rev/517720b458ce
Use the new XRE Bootstrap API in Firefox for Android. r=bsmedberg
https://hg.mozilla.org/integration/autoland/rev/908c2d41eeaa
Move reading application.ini to XRE_main. r=bsmedberg
https://hg.mozilla.org/integration/autoland/rev/6b46b8d889df
Remove everything related to frozen functions from the XPCOM glue. r=bsmedberg
Blocks: 1331863
Status: NEW → RESOLVED
Closed: 7 years ago
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Blocks: 658847
You need to log in before you can comment on or make changes to this bug.