mozilla
/
gecko-dev
зеркало из https://github.com/mozilla/gecko-dev.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
gecko-dev/layout/build/nsLayoutModule.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

51 строка
2.2 KiB
C
Исходник Обычный вид История

Bug 1492584, part 1 - Eagerly initialize nsLayoutModule in the component manager. r=froydnj nsLayoutModule must be initialized in order to call into JS, but I don't want to have to rely on calling a service in that module. Instead, always initialize the module very early in component manager initialization. This also makes initialization more consistent, so things like errors in manifests won't affect when it happens, which can result in different behavior in different builds. I also made nsLayoutModule initialization infallible, because I can't imagine that we can do much that is useful without it. Another change I made is that gInitialized is set to true even in a GPU process. This simplifies checking whether initialization has happened already when we start up the layout module. Differential Revision: https://phabricator.services.mozilla.com/D9583 --HG-- extra : moz-landing-system : lando
2018-10-24 19:10:29 +03:00
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef nsLayoutModule_h
#define nsLayoutModule_h
#include "nscore.h"
Bug 1544897: Add includes, forward declarations, and namespaces to address non-unified build bustage in layout/{base,build,generic}. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D27782 --HG-- extra : moz-landing-system : lando
2019-04-17 00:18:30 +03:00
#include "nsID.h"
#include "mozilla/AlreadyAddRefed.h"
Bug 1492584, part 1 - Eagerly initialize nsLayoutModule in the component manager. r=froydnj nsLayoutModule must be initialized in order to call into JS, but I don't want to have to rely on calling a service in that module. Instead, always initialize the module very early in component manager initialization. This also makes initialization more consistent, so things like errors in manifests won't affect when it happens, which can result in different behavior in different builds. I also made nsLayoutModule initialization infallible, because I can't imagine that we can do much that is useful without it. Another change I made is that gInitialized is set to true even in a GPU process. This simplifies checking whether initialization has happened already when we start up the layout module. Differential Revision: https://phabricator.services.mozilla.com/D9583 --HG-- extra : moz-landing-system : lando
2018-10-24 19:10:29 +03:00
Bug 1478124: Part 8c - Update Layout module to use a static component manifest. r=Ehsan Differential Revision: https://phabricator.services.mozilla.com/D15041 --HG-- extra : rebase_source : 479e50e210f21888c841fec5742df68f33f5f80f extra : source : 21f4fda0315963e42bae8784c63116f00ee0fa92
2019-01-24 02:45:56 +03:00
class nsIPresentationService;
Bug 1544897: Add includes, forward declarations, and namespaces to address non-unified build bustage in layout/{base,build,generic}. r=TYLin Differential Revision: https://phabricator.services.mozilla.com/D27782 --HG-- extra : moz-landing-system : lando
2019-04-17 00:18:30 +03:00
class nsISupports;
Bug 1478124: Part 8c - Update Layout module to use a static component manifest. r=Ehsan Differential Revision: https://phabricator.services.mozilla.com/D15041 --HG-- extra : rebase_source : 479e50e210f21888c841fec5742df68f33f5f80f extra : source : 21f4fda0315963e42bae8784c63116f00ee0fa92
2019-01-24 02:45:56 +03:00
Bug 1492584, part 1 - Eagerly initialize nsLayoutModule in the component manager. r=froydnj nsLayoutModule must be initialized in order to call into JS, but I don't want to have to rely on calling a service in that module. Instead, always initialize the module very early in component manager initialization. This also makes initialization more consistent, so things like errors in manifests won't affect when it happens, which can result in different behavior in different builds. I also made nsLayoutModule initialization infallible, because I can't imagine that we can do much that is useful without it. Another change I made is that gInitialized is set to true even in a GPU process. This simplifies checking whether initialization has happened already when we start up the layout module. Differential Revision: https://phabricator.services.mozilla.com/D9583 --HG-- extra : moz-landing-system : lando
2018-10-24 19:10:29 +03:00
// This function initializes various layout statics, as well as XPConnect.
// It should be called only once, and before the first time any XPCOM module in
// nsLayoutModule is used.
void nsLayoutModuleInitialize();
Bug 1478124: Part 8c - Update Layout module to use a static component manifest. r=Ehsan Differential Revision: https://phabricator.services.mozilla.com/D15041 --HG-- extra : rebase_source : 479e50e210f21888c841fec5742df68f33f5f80f extra : source : 21f4fda0315963e42bae8784c63116f00ee0fa92
2019-01-24 02:45:56 +03:00
void nsLayoutModuleDtor();
nsresult CreateXMLContentSerializer(nsISupports* aOuter, const nsID& aIID,
void** aResult);
nsresult CreateHTMLContentSerializer(nsISupports* aOuter, const nsID& aIID,
void** aResult);
nsresult CreateXHTMLContentSerializer(nsISupports* aOuter, const nsID& aIID,
void** aResult);
nsresult CreatePlainTextSerializer(nsISupports* aOuter, const nsID& aIID,
void** aResult);
nsresult CreateContentPolicy(nsISupports* aOuter, const nsID& aIID,
void** aResult);
nsresult CreateGlobalMessageManager(nsISupports* aOuter, const nsID& aIID,
void** aResult);
nsresult CreateParentMessageManager(nsISupports* aOuter, const nsID& aIID,
void** aResult);
nsresult CreateChildMessageManager(nsISupports* aOuter, const nsID& aIID,
void** aResult);
nsresult Construct_nsIScriptSecurityManager(nsISupports* aOuter,
const nsIID& aIID, void** aResult);
nsresult LocalStorageManagerConstructor(nsISupports* aOuter, const nsIID& aIID,
void** aResult);
Bug 1558420 - Part 1: Add an API for creating a sessionstorage manager and a cache object; r=baku Differential Revision: https://phabricator.services.mozilla.com/D51325 --HG-- extra : moz-landing-system : lando
2019-11-12 18:40:02 +03:00
nsresult SessionStorageManagerConstructor(nsISupports* aOuter,
const nsIID& aIID, void** aResult);
Bug 1478124: Part 8c - Update Layout module to use a static component manifest. r=Ehsan Differential Revision: https://phabricator.services.mozilla.com/D15041 --HG-- extra : rebase_source : 479e50e210f21888c841fec5742df68f33f5f80f extra : source : 21f4fda0315963e42bae8784c63116f00ee0fa92
2019-01-24 02:45:56 +03:00
already_AddRefed<nsIPresentationService> NS_CreatePresentationService();
Bug 1492584, part 1 - Eagerly initialize nsLayoutModule in the component manager. r=froydnj nsLayoutModule must be initialized in order to call into JS, but I don't want to have to rely on calling a service in that module. Instead, always initialize the module very early in component manager initialization. This also makes initialization more consistent, so things like errors in manifests won't affect when it happens, which can result in different behavior in different builds. I also made nsLayoutModule initialization infallible, because I can't imagine that we can do much that is useful without it. Another change I made is that gInitialized is set to true even in a GPU process. This simplifies checking whether initialization has happened already when we start up the layout module. Differential Revision: https://phabricator.services.mozilla.com/D9583 --HG-- extra : moz-landing-system : lando
2018-10-24 19:10:29 +03:00
#endif // nsLayoutModule_h