Re: Issues with chrome.manifest when installed in path having japanese characters
On 8/14/2014 7:15 AM, bhargava.animes...@gmail.com wrote: I am using gecko SDK 28.0 in my application. When my application is installed in path having japanese/korean characters then in my embedded browser nothing is shown.We found following error in logs Could not read chrome manifest 'file:///C:/Users/an/Elements/main/build/targets/x64/elements2%C3%AF%C2%BE%C5%A0%C3%AF%C2%BD%C2%B7%C3%AF%C2%BE%E2%80%9E%C3%AF%C2%BD%C2%B6%C3%AF%C2%BD%C2%BD%C3%AF%C2%BE%C2%9D%C3%AF%C2%BD%C2%B6%C3%AF%C2%BD%C2%B7.Debug/mozilla/chrome.manifest'. Could not read chrome manifest 'file:///C:/Users/an/Elements/main/build/targets/x64/elements2%EF%BE%8A%EF%BD%B7%EF%BE%84%EF%BD%B6%EF%BD%BD%EF%BE%9D%EF%BD%B6%EF%BD%B7.Debug/chrome.manifest'. The actual path is 'file:///C:/Users/an/Elements/main/build/targets/x64/elements2ﾊｷﾄｶｽﾝｶｷ.Debug/chrome.manifest'. Inside the browser complete white screen is shown. I have components that need to be registered with chrome.manifest. Since i am getting this error , those components would also be not registering . This sounds like a bug, although it's not clear where exactly the bug is without further debugging. Windows is especially hard in this regard because the native codepage is variable and doesn't express the full unicode range, so internally we try to use wide characters or UTF8 to represent windows paths, but occasionally that fails. You should file a bug to track the issue, but unless you can construct a testcase where this bug affects Firefox, it's likely that you will need to do the debugging yourself. cc me on the bug and I can point you to the lines of code you should look at in your debugger. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Issues with chrome.manifest when installed in path having japanese characters
On 8/14/2014 9:08 AM, bhargava.animes...@gmail.com wrote:
In our code , we are having following snippet :
rv = NS_NewNativeLocalFile(nsEmbedCString((char *)filepath), PR_FALSE,
getter_AddRefs(libxul));
if (NS_FAILED(rv))
{
throw BALBrowserException();
}
rv = NS_NewNativeLocalFile( nsEmbedCString((char *)filepath), PR_FALSE,
getter_AddRefs(appDir));
if(NS_FAILED(rv))
{
throw BALBrowserException();
}
rv = XRE_InitEmbedding(libxul, appDir, 0);
rv in each case is NS_OK . After execution of 'XRE_InitEmbedding(libxul,
appDir, 0); ' we are getting the chrome.manifest error. I have checked
filepath ( containing japanese characters) , it is correct.
What character set is filepath, and what charset is the native
filesystem? Note that using narrow char* to store these is inherently
lossy, and you should probably be using char16_t*/WCHAR* for these so
that you don't run into issues with unicode repertoire: then you'd be
using NS_NewLocalFile not NS_NewNativeLocalFile.
--BDS
___
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
Re: Issues with chrome.manifest when installed in path having japanese characters
On 8/14/2014 9:58 AM, g...@novadsp.com wrote: I am not sure if your problem is identical to one I recently had to solve. XRE_InitEmbedding2Type on Windows uses ReadDependentCB() and TS_tfopen() internally (implemented in nsXPCOMGlue.cpp. In the 2 helpers, which both take char* parameters, the MultibyteToWideChar conversion used the CP_UTF8 flag. If your path contains MBCS double byte characters then this conversion will produce garbage. This is correct and intentional: see the comment at http://mxr.mozilla.org/mozilla-central/source/xpcom/build/nsXULAppAPI.h#155 We do this because on Windows the native charset doesn't represent unicode. So we use a wmain entry point and wchar, and convert to UTF8 immediately so that we can use a shared char* interface with all the other platforms. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: firefox 29 libxul.so has less symbols in its dynamic symbol table.
On 4/15/2014 2:16 PM, Tom Hindle wrote: This change means I can no longer use functions like JS_ContextIterator from programs dlopenning or linking libxul.so. On windows I can still use these symbols from xul.dll. Have these symbols been intentionally hidden on Linux, by some mechanism I'm not aware of? Yes, and we intend to hide them on Windows as well, once we solve linker memory issues. See bug 920731. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Registering components under XULRunner 24
On 2/17/2014 11:07 AM, Christian Sell wrote: 3. steal a copy of the missing XPCOMUtils.jsm file and put it into the xulrunner/modules directory This should not be necessary. The correct location for this file is within omni.ja, and it seems to be present in the XR27 release. 3. when building the path for the ComponentRegistrar, dont use AppendRelativePath but rather use one Append call for each path segment AppendRelativePath is supposed to work, but it's possible you ran into issues with Windows path separators: you must use backslashes on Windows and forward slashes on unixy OSes. Lesson learned, though, always check result codes ;-) --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Registering components under XULRunner 24
On 2/13/2014 1:12 PM, Christian Sell wrote: doesnt work. I am creating the file like this: retval = directory-Get(NS_GRE_DIR, NS_GET_IID(nsILocalFile), (void **)greDir); file-InitWithFile(greDir); file-AppendRelativePath(NS_LITERAL_STRING(components/components.manifest)); the contents of the components.manifest file are just one line: interfaces RegionCapture.xpt I still get NS_ERROR_FACTORY_NOT_REGISTERED when trying to access the component. That's because the interfaces line only registers the interfaces, not the component. To register the component you use something like http://mxr.mozilla.org/mozilla-central/source/toolkit/components/downloads/nsDownloadManagerUI.manifest to register the component and contract entries --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Registering components under XULRunner 24
On 2/13/2014 12:31 PM, Christian Sell wrote: Hello, me again ;). We are embedding XULRunner in our Java application, using a thin integration layer written in C++ that provides extended functionality. We also have a XPCOM component written in Javascript, which we previously called though JavaXPCOM, and now need to call from C++. However, no matter what I do, I keep getting a NS_ERROR_FACTORY_NOT_REGISTERED when issuing the following call: nsCOMPtrnsIRegionCapture regionPrinter; retval = servMan-GetServiceByContractID(@mozilla.org/regioncapture;1, NS_GET_IID(nsIRegionCapture), getter_AddRefs(regionPrinter)); I have tried adding the .js and .xpt files to the xulrunner components subdirectory (which I had to create), added chrome.manifest files pointing to the component, and even tried programmatic registration through nsIComponentRegistrar registrar; retval = NS_GetComponentRegistrar(getter_AddRefs(registrar)); retval = registrar-AutoRegister(file); If `file` points to the .manifest file you created, then AutoRegister should work. Are you seeing any errors from nsIConsoleService? When we adopted manifests I tried to make sure that any parsing errors would show up in the Firefox console. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: JavaXPCOM development?
On 7/12/2012 12:11 PM, Blake Binkley wrote: is there anyone who has XulRunner 10+ embedded in java? I have been under the impression that javaXPCOM was no longer being worked on and was a dead project, but in another thread here somone is talking about java and having a new version of XulRunner embedded, if not via javaXPCOM then by what means is it being done? JavaXPCOM does not have a maintainer and is essentially dead, yes. I believe that there are separate projects like an SWT embedding widget which don't use JavaXPCOM. I'm not clear on exactly how all those work. And of course Java still works as a NPAPI plugin in the browser. --BDs ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Undefined simbols moz_xmalloc (et al.) in Gecko 12
On 5/18/2012 4:20 AM, Babele Dunnit wrote: Hi everybody, I am updating our embedding app from Gecko7 to Gecko12. I get linking errors: In function `operator new(unsigned int)': /dist/include/mozilla/mozalloc.h:229: undefined reference to `moz_xmalloc' In function `operator new[](unsigned int)': /dist/include/mozilla/mozalloc.h:241: undefined reference to `moz_xmalloc' In function `operator delete(void*)': /dist/include/mozilla/mozalloc.h:253: undefined reference to `moz_free' In function `operator delete[](void*)': dist/include/mozilla/mozalloc.h:265: undefined reference to `moz_free' I am building xulrunner with a default .mozconfig, with just ac_add_options --enable-cpp-rtti added. Any advice (apart from copying the sources and forcing the compilation/ linking, which I will do now) ? These errors occur while linking your embedding app? Are you using dependent or independent glue? I think you would need to end up linking against mozutil (which contains mozalloc IIRC), but that might depend on how you're linking to begin with. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On 2/25/2012 7:05 AM, luke.leigh...@gmail.com wrote: the first question is this: how the heck is it possible that i could create, in under 3 weeks, an entire port of pyjamas-desktop to use the MSHTML IE engine, *without* requiring access to the proprietary MSHTML Trident Engine? The browser engine provided by Microsoft has a stable COM API. It also does not require the embedder to handle any kind of persistent data access: history/cache/cookie stores are handled via a single operating system store which is shared across processes. the key question is this: what is it about the microsoft technology that makes this possible? this is not a rhetorical question. this is not a sarcastic question. i genuinely require that you actually think, ben, and find out the answer (hint: you already implement one. or used to. until it was pulled). No, we didn't. The ActiveX control provided an emulation layer which satisifed some of the behaviors (allowing gecko to run in a process hidden behind at least the basic set of Microsoft interfaces). But because we don't have any form of cross-process profile sharing, the embedder either had to configure and run their own profile directory (and think about the consequences of only being able to use that datastore from one process at a time) or run without any data store, which is not a well-tested gecko configuration and will cause many websites to fail because cookies and the cache do not behave correctly. In addition, the primary way to access DOM nodes through the MS API is via IDispatch, and the bridge between IDispach and COM typeinfo was never complete and didn't match the Microsoft implementation in key ways. The closest cross-platform equivalent we have to IDispatch is the NPRuntime, which is pretty well tested but isn't efficient and has inherent cycle issues. and if microsoft can do it, why can't the mozilla foundation? We *could* do it. But it would require significant engineering effort to implement shared profile data, solve the IDispatch-or-equivalent problem (especially if we needed it to be safe for object cycles via the cycle collector), and then provide real QA and release resources for the project. Since we are not prepared to do any of that at this time, it's better to be perfectly clear about the situation then string embedders along thinking that they have a better solution than they actually have. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Question Doubts regarding the embedding of Gecko
On 1/9/2012 6:34 AM, Leander Bessa wrote: I'm trying to build an application which'll use html5 and css3 to display its interface and a set of C++ apis to introduce features beyond the scope of html. It sounds like you really want XULRunner, not embedding in the traditional sense. You can write XULRunner apps using HTML (instead of XUL), and this is actually recommended because it will insulate you from any changes we might make to the (unstable) XUL language itself. And most of the special features you need can be implemented as JS modules or XPCOM components. 1) Does embedding gecko only give me access to the html renderer or does it also include the javascript engine? Our platform is a complete platform including layout, JS, networking, and pretty much everything else you need for a complete web experience. 2) Regarding the new embed api with Qt, how does gecko render html? Does it use cairo's or Qt's api? This aspect is important, since rendering performance is a must. I can't answer this question because I don't know what embed API you're discussing. 3) How easy is it to make my c++ apis available to the javascript context? In the case of the Qt port, can i use QObject derived classes such as in QtWebkit? No, you cannot. Typically you interface with C++ code using either XPCOM interfaces declared in XPIDL, or by writing a glue layer in JavaScript and using JS-ctypes. XPCOM is more powerful but you may need to update or recompile your code for each release cycle. JS-ctypes is more stable although it may require additional work and care to get the interface right, especially if you have complex callback mechanisms. 4) How difficult is it to extend/alter Gecko? For instance: adding a c ++ scene graph to the canvas layer or hooking up a driver to support muti-touch input with a touch screen on a desktop pc? Assuming that you can't just translate your scene graph to SVG or some web technology, the best way to implement something like that would probably be as an NPAPI plugin. Gecko already supports multi-touch input natively using DOM events, so that probably doesn't require any additional code on your part except for JS to react to the multitouch events. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Show stopper issue for our GECKO 1.9.2 embedding project and we have expensive business impact
On 12/22/2011 10:45 AM, lord_nemesis wrote:
Hello Benjamin (I am putting the name directly as I got help through
him and now having issue in that area),
This issue is putting us in most discomfort situation in business
line... Please take time and help us out from here
Problem:
We have a page that that is throwing a JS exception when running in
our embedded gecko browser, but working fine in firefox. The page a
javascript function which checks the value of a global though an if
condition. the same is set an initial value in thehead section of
the page. some thing like this
I really have no clue about the correct way to do what you're doing.
Perhaps bholley.
--BDS
test = ;
myfunc()
{
if (test ...) {
}
}
as you can see, test is not a var type. Its a global property. In our
embedded gecko application, we are getting a ReferenceError: test is
undefined exception when trying to check the value of test. This is
however not happening in Firefox browser built from the same
codebase.
After some debugging, we arrived at the conclusion that our own code
to call javascript functions on the page is causing some issue.
our code for the same looks some thing like this. This is used to
invoke custom js functions in some pages, but not on on the particular
one that we are having problem with. can you please see if there is
anything wrong with this code and also help us with solving the
problem.
CallJavaScript(const CString strJSFnName, const CStringArray
paramArray, CString strRetVal)
{
try {
nsresult resultVal = NS_OK;
nsCOMPtrnsIDOMDocument domDoc;
if(nsnull == m_webNavigation ) //null check to avoid crash
show blank page incase of Webnavigation handle null
{
return false;
}
// Get the Document DOM
resultVal = m_webNavigation-
GetDocument(getter_AddRefs(domDoc));
if (NS_FAILED(resultVal))
{
return false;
}
// Get Document from DOM.
nsCOMPtrnsIDocument doc = do_QueryInterface(domDoc,
resultVal);
if (NS_FAILED(resultVal))
{
return false;
}
// Get the Script Global Object from Document
nsCOMPtrnsIScriptGlobalObject scriptGlobalObj(doc-
GetScriptGlobalObject());
if (scriptGlobalObj == nsnull) {
return false;
}
// Get the Script Context
nsCOMPtrnsIScriptContext scriptContext(scriptGlobalObj-
GetContext());
if (scriptContext == nsnull) {
return false;
}
// Get the JSContext.
JSContext *pJSContext =
reinterpret_castJSContext*(scriptContext-GetNativeContext());
JSObject *pJSObject = scriptGlobalObj-GetGlobalJSObject();
{
AutoSetupJSContext setupJSContext(pJSContext);
jsval jsReturnVal = 0;
// Build the Input argument list
int argCount =paramArray.GetSize();
jsval *pJSInputArgs = new jsval[argCount];
for (int argIndex = 0; argIndex argCount; +
+argIndex) {
CString argStr = paramArray.GetAt(argIndex);
jschar *pJSArgChars = (jschar *)
(argStr.GetBuffer(argStr.GetLength()));
JSString *jsArgStr =
JS_NewUCStringCopyZ(pJSContext, pJSArgChars);
argStr.ReleaseBuffer();
pJSInputArgs[argIndex] =
STRING_TO_JSVAL(jsArgStr);
}
int jsFuncNameLen = WideCharToMultiByte(CP_ACP, 0,
(LPCWSTR)(LPCTSTR)strJSFnName, -1, 0, 0, NULL, NULL);
char* pJSFuncName = new char[jsFuncNameLen + 1];
WideCharToMultiByte(CP_ACP, 0, (LPCWSTR)
(LPCTSTR)strJSFnName, -1, pJSFuncName, jsFuncNameLen, NULL, NULL);
JSBool isJSCallSuccess =
JS_CallFunctionName(pJSContext, pJSObject, pJSFuncName, argCount,
pJSInputArgs,jsReturnVal);
class AutoSetupJSContext {
public:
AutoSetupJSContext(JSContext *pJSContext)
: m_JSContextStack(), m_pJSContext(pJSContext)
{
nsresult resultVal = NS_OK;
// Get the JSContext Stack.
m_JSContextStack = do_GetService(@mozilla.org/js/xpc/
ContextStack;1,resultVal);
ASSERT(m_JSContextStack != nsnull);
// Push the JSContext to JSContext Stack.
resultVal = m_JSContextStack-Push(m_pJSContext);
ASSERT(resultVal == NS_OK);
// Set an Error handler on the JSContext. This handler will
get control when ever
// there is an error with executing a JS Function.
JS_SetErrorReporter(pJSContext, JSErrorHandler);
// Begin JS Request. This will ensure that we wait till any
current activity on the
// JSContext is completed
Re: nsString
On 11/28/2011 5:36 AM, philippe wrote: Hello. I built a browser with gecko 1.8 . It worked fine. Now I try to use gecko 1.9.2.23. I get some conversions problems For example: __ nsString attributeName char* attrName=ToNewCString(attributeName); causes an error : cannot convert parameter 1 from 'nsString_external' to 'const nsACString' ___ Is there a doc about such conversions in 1.9.2. The ToNewCString version which took a wide string in and produced a narrow string out didn't have an identified character set, and so was removed at some point along the way. Assuming you want a UTF8 narrow string allocated, you'd need something like: ToNewCString(NS_ConvertUTF16toUTF8(attributeName)); --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Embedding basics
On 11/4/2011 1:25 AM, Sunil Kumar wrote: I dont want to use Any GUI windows( gtk_window/Window), so I wont have the Handle/Pointer to a real window. How can I call BaseWindow.initWindow without having a Handle or Pointer to real window? Currently you cannot, a window is required. For a while Chris Lord was working on a headless (offscreen) version of gecko which did exactly what you want, but as far as I know that version is currently unmaintained, see http://hg.mozilla.org/incubator/offscreen but also see that the last commit was in March 2010. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Embedding basics
On 11/3/2011 9:12 AM, Sunil Kumar wrote: I need to know what all I need to do and in Which order to load a URL in nsWebBrowser instance. It looks like you have not initialize the webbrowser. As far as I know, you cannot use a webbrowser until you've set it up (using nsIBaseWindow.initWindow and nsIBaseWindow.create). But I'm not sure exactly what is necessary for setup. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: How to build JavaXPCOM/XULRunner7.0.x
On 11/3/2011 1:55 AM, Sunil Kumar wrote: I am trying to build JavaXPCOM from XULRunner7.0.1-source. JavaXPCOM has been removed from the main Mozilla tree because nobody was maintaining the code. If somebody would like to take the code and make it a standalone project, that is possible and I'd be happy to help you get started. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: nsIXULAppInfo failing?
On 9/6/2011 9:03 AM, Babele Dunnit wrote: hi there, is there any reason for which a line like nsCOMPtrnsIXULAppInfo appInfo = do_GetService(@mozilla.org/xre/app- info;1); should fail giving back a null ptr? everything works, GRE is correctly loaded etc. BTW: nsCOMPtrnsIXULRuntime runtime(do_GetService(@mozilla.org/xre/app- info;1)); works, the runtime ptr is not null... Are you using the same version of the platform and the SDK? This smells to me like a header mismatch where you're using a different version (and IID) for nsIXULAppInfo than the platform code which implements it. --BDs ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Windows xpcomglue link errors [solved]
On 9/3/2011 11:07 AM, g...@novadsp.com wrote: Apologies if this gets double-posted Why is this defined only when XP_WIN is defined? A bug? Because __fastcall is a Windows-specific annotation. GCC uses a different syntax on x86-Linux. The problem here appears to be that you aren't including xpcom-config.h, which is the file that contains platform-specific #defines necessary for nscore.h and other headers to detect compilers and platforms properly. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Winembed link errors?
On 9/1/2011 6:29 AM, g...@novadsp.com wrote: Attempting to build WinEmbed from a VS2008 project and clearly missing something. Compiler #defines and settings are as make command line, which builds correctly. Does anyone recognize the following? WebBrowserChrome.obj : public: virtual unsigned int __thiscall nsCreateInstanceByContractID::operator()(struct nsID const ,void * *)const WebBrowserChrome.obj : public: unsigned int __thiscall nsQueryInterface::operator()(struct nsID const ,void * *)const winEmbed.obj : public: unsigned int __thiscall nsQueryInterface::operator()(struct nsID const ,void * *)const WindowCreator.obj : unsigned int __cdecl NS_TableDrivenQI(void *,struct QITableEntry const *,struct nsID const ,void * *) winEmbed.obj : public: virtual unsigned int __thiscall nsGetInterface::operator()(struct nsID const ,void * *)const winEmbed.obj : public: unsigned int __thiscall nsGetServiceByContractID::operator()(struct nsID const ,void * *)const Those symbols should be in the XPCOM glue. Are you linking it? --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: How to do embedding now
On 9/1/2011 8:24 AM, Glen Gray wrote: Hey Guys, Now that GtkMozEmbed etc. are gone, is there a documented and supported way to build Gecko based browsers ? If so, what's the url for the docs. Not supported, no. But XRE_InitEmbedding still works and along with nsWebBrowser can be used to load gecko rendering into other apps. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Managing multiple nsIWebBrowser instances
On 5/25/2011 2:12 PM, Messica, Shay wrote: A more problematic case, is when one browser invokes a Javascript function that causes some RPC invoke on the second process. If the native application process needs to open event loop or run some long operation, we have to pump events while waiting for result. This might cause Javascript functions to get called in a nested/re-entrant manner. What APIs are causing this? In general the idea should be that these should be asynchronous APIs, not synchronous calls. As far as I understand, there is no way to have each browser run in a separate thread. Is there a way to emulate that? Like to pause the browser and keep the other browser processing events, and upon result - resume that browser? Or is there some other technique that can help with this? Not really. The answer is to change your APIs which could block and make them asynchronous. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Firefox5: Does WinEmbed still exist?
On 5/16/2011 11:32 PM, Joffrey wrote: Mozilla announced the end of Gecko embedding. No I didn't. I announced that JavaXPCOM, gtkmozembed, and the ActiveX control are not being maintained by the Mozilla project and would be removed from the main tree. Would this terminate embedding gecko in WinEmbed at /mozilla-central/embedding/tests/winEmbed (I would like to use embedding technology in JAVA JNI Applet) Not necessarily. The code still builds, although it has no tests, so there is little guarantee that it actually works. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Replacements for GtkMozEmbed
On 4/20/2011 11:16 AM, Glen Gray wrote: Hey guys, So, further to the discussions about dropping the embedding technologies, I'm interested in learning about what I can do to replace using GtkMozEmbed. Somebody mentioned creating a xulrunner application. I don't really know anything about that so I'm going to look into it. Answers to a couple of questions could help speed up my understanding though. Will a xulrunner application be able to integrate with actions that xulrunner takes like opening uri's etc. ? We use uri's as service tags and some uri's are processed externally by our application stack. The GtkMozEmbed application will get a callback from Gecko for a uri open if someone clicks on a Video button for example, the hasa href=video:SomeVideoFileMovie/a. We'll route execution to a media application passing over the uri. Yes, you can implement a nsIProtocolHandler. Although really, you should be using an x-video URI scheme, if you really need to use a custom URI scheme. If the above is possible then I'm happy. I'm wondering if the pyxpcom wrappers are still valid, we could replace our application with something like http://pyxpcomext.mozdev.org/no_wrap/tutorials/pyxulrunner/python_xulrunner_about.html From the looks of that documentation, I could do all I need with xulrunner and Python. The Python bindings are not part of XULRunner by default, but I believe that they are still being maintained: you need to ask the PyXPCOM group about that: http://listserv.activestate.com/mailman/listinfo/pyxpcom --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On 4/7/11 9:41 AM, CMB wrote: Would this terminate embedding gecko in IDE's (ex eclipse), TopStyle ecc.? Eclipse uses javaxpcom to do embedding. If somebody wishes to maintain that code, they may continue to do so, but it will not be built into XULRunner or available in the main mozilla codebase. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: The future of binary embedding
On 4/7/11 9:29 AM, sdenn...@rocketmail.com wrote: Benjamin, 1) I'm unclear of the impacts of removing gtkmozembed. Can you please clarify which APIs and functionality will be impacted? For example, will XRE_InitEmbedding go away with these near-term changes? gtkmozembed is the code in embedding/browser/gtk and primarily the functions in gtkmozembed.h. XRE_InitEmbedding is not affected. 2) I too rebuild mozilla for a special xulrunner application that plays nicely with legacy gtk+/wx applications to provide an embedded browser. However, I utilize a wrapper for my access - wxWebConnect which is supported by Kirix: http://www.kirix.com/labs/wxwebconnect.html Will the changes you identify here impact that project and the apis/utilities they use? I don't know, that depends on how they do their embedding. But of course, if they use gtkmozembed, they can import that code and continue to use and maintain it. 3) What is the timeframe for these changes? Immediately for Firefox 5. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: how to get a distributable XulRunner for buildin/running embedding application
On 3/30/2011 8:52 AM, Martin Lutken wrote: Simple question. If I follow build instructions found here https://developer.mozilla.org/en/Configuring_Build_Options enabling xulrunner as application. (Building on Ubuntu 10.10 ) I use a MOZ_OBJDIR and everything compiles fine. My problem is how do I get a moveable XulRunner including header files etc. that I can copy to where I need it to be without all the softlinks pointing to the original source files and built binaries ? `make package` should give you tarballs for XULRunner itself and a separate tarball for the SDK. I think they end up in dist/ --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Embedding Gecko/XULRunner
On 2/16/2011 11:28 PM, Peter Tsonev wrote: My understanding of the embedding process (one of the possible ways) is that 1) GRE is found, 2) XPCOMGlue is started up, 3) XUL functions are initialized, 4) XRE_InitEmbedding is called. Yes. Note that I strongly recommend that you never try to use a system XULRunner. Always ship XULRunner with your code (e.g. in a xulrunner/ subdirectory) and look for it in that well-known location. DLL-hell will result otherwise. Is this correct? I am able to execute all of the above correctly. Then I proceed to get nsIWebBrowser via do_CreateInstance and nsIWebNavigation via do_QueryInterface. Then I load a URL through the latter. It is this loading that fails. Please refer to the code below. Everything I described is attempted by the code. You haven't initialized the webbrowser yet. I believe that requires QIing it to nsIBaseWindow and calling create() (and maybe initWindow() before that) on it. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Embedding Gecko/XULRunner
On 2/14/2011 3:05 PM, Peter wrote: However, the documentation on embedding is a bit fuzzy and all over the place. I am not even completely sure with the terminology as it keeps changing and is mixed up in the docs. This is because there is little or no embedding community. The Mozilla community is mainly focused on Firefox development, and embedding is not a priority. Question0: How is embedding Gecko different from embedding XULRunner? Which of the two have I actually done above? They are the same thing. XULRunner is the shipping product which provides the Mozilla web engine, sometimes called gecko. Question1a: My understanding is that I can build upon GtkEmbedMoz (provides a gtk widget for the browser content pane - I think) and TestGtkEmbed (provides the actual window in which GtkEmbedMoz is displayed - I think) instead of working directly with the embedding API (too much work). Is My understanding correct? If not, please correct it. TestGtkEmbed is example code for how you might use GtkEmbedMoz. But in your case, I recommend that you *not* use GtkEmbedMoz except as perhaps a template for embedding, and instead use the embedding API more directly. Question1b: TestGtkEmbed was compiled as part of XULRunner SDK compilation. If I am to build upon it, I would obviously have to compile it as part of my app. However, a lot of stuff goes in TestGtkEmbed, and I cannot find a good makefile or at least guidance as to what flags, libs, and include paths to use. Any advice greatly appreciated. https://developer.mozilla.org/en/XPCOM_Glue Question2: The ultimate goal would be using the mozilla engine in headless mode - therefore I would eventually not need any of the gtk stuff for display. In this case, am I doing an overkill by going through GtkEmbedMoz? Would it be eventually simpler to use the embedding API directly. Please comment. The GtkEmbedMoz code will probably be removed in a future release of Mozilla because it is buggy and unmaintained, and not the direction we want for embedding in general. I would recommend using the low-level API if possible. Also, you might want be aware of the gecko headless rendering branch, which is rather old now but might be useful to you: http://hg.mozilla.org/incubator/offscreen/ --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Old question, Embed javascript extension
On 11/6/10 8:52 AM, Xijing Dai wrote: I have a questions about javascript extension after you embeding the xulrunner. so far, i found that if you want to write a extension to the javascript, u have to create a component, isn't it? Could you perhaps be more specific? By extension to the javascript, do you mean adding some property to the DOM which every web page sees? Also, how are you setting up your application? Are you writing a Firefox extension? Or a XULRunner application? Or using some embedding API which doesn't use XUL? Starting with Firefox 4/Mozilla 2, you can use the content-document-global-created notification to watch and modify the DOM of pages as they load. This is the recommended way to add special properties to the DOM. See https://developer.mozilla.org/en/Observer_Notifications#Windows for details. secondly, i am new to xulrunner, i found it's hard to execute a javascript code from C++, any directions? The normal way to do this is via an XPCOM component. The IDL interface defines a method which can call C++-JS. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: gfxASurface and Win32 friends
On 11/8/10 12:10 PM, g...@novadsp.com wrote: Is there some mozconfig option which stops these classes being included in libraries? The .obj files are definitely in ..\build\gfx\thebes\src but I'm getting linker errors (edited example below) : error LNK2019: unresolved external symbol __declspec(dllimport) public: void * __thiscall gfxASurface::GetData(..) : error LNK2019: unresolved external symbol __declspec(dllimport) public: void __thiscall gfxContext::Paint(double) : error LNK2019: unresolved external symbol __declspec(dllimport) public: void __thiscall gfxContext::SetSource(class gfxASurface : error LNK2019: unresolved external symbol __declspec(dllimport) public: __thiscall gfxWindowsSurface::gfxWindowsSurface(..) What are you linking against? If possible, please include your exact compile and link command-line so that I can check your #defines and import libraries. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: gfxASurface and Win32 friends
On 11/8/10 1:04 PM, g...@novadsp.com wrote: Compiler command line: cl /Od /I U:\mozilla\mozilla-1.9.2\_VS2008\xul-debug\dist\include /D WIN32 /D _WINDOWS /D _DEBUG /D XP_WIN /D XPCOM_GLUE /D _AFXDLL /D _MBCS /FD /EHsc /MDd /Zc:wchar_t- /Yustdafx.h /FpDebug\MozMFC.pch /FoDebug\\ /FdDebug\vc90.pdb /W3 /c /Zi /TP .\BrowserImpl.cpp You are using -DXPCOM_GLUE. The only reason to do this is if you don't want to link against XPCOM directly (because you don't know at application start time where XPCOM is installed). In your case you should remove this flag. /OUT:R:\src\mozilla\MozMFC\Debug\MozMFC.exe /LIBPATH:U:\mozilla\mozilla-1.9.2\_VS2008\xul-debug\dist\lib /MANIFEST /MANIFESTFILE:Debug\MozMFC.exe.intermediate.manifest /MANIFESTUAC:level='asInvoker' uiAccess='false' /DEBUG /PDB:R:\src\mozilla\MozMFC\Debug\MozMFC.pdb /SUBSYSTEM:WINDOWS /DYNAMICBASE /NXCOMPAT /MACHINE:X86 .\Debug\AppDoc.obj Nowhere do I see you linking against *any* mozilla import libraries. Since you're using -DXPCOM_GLUE, I'd expect to see libxpcomglue.lib in your link line. Without -DXPCOM_GLUE, you'd need to link against xpcomglue_s.lib, xpcom.lib. For more details, see the linker information at https://developer.mozilla.org/en/XPCOM_Glue The gfx*Surface symbols are export from libxul, if anywhere, and so you'd also need to link against xul.lib. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Programmer Challenge: Worlds Smallest Gecko Browser DLL for C++ programmers to use in their apps? (programmatically controlled, ultra minimalistic--ultra fast)
On 8/8/10 1:48 PM, Jani Mäkinen wrote: I'm curious, what is the smallest size you guys have gotten the gecko browser fitted into? Why does this matter to you? I'm working on a project right now where I need(and I believe many others will need aswell) a programmatically controlled browser DLL for my windows software and I'm going to create a very very small Gecko browser without using activex's or external executables if I possibly can, and I'd like to challenge you guys also to this, so that we as C+ + programmers can support Mozilla FireFox to get a nice smart fast browser to our use when we function in environments where do not have either the resources or the full capabilities to launch the real Mozilla Firefox or the users default browser. The standard recommendation for this is to use a XULRunner build, which already has things like XRE_InitEmbedding which you can use to hook up browsing within an application. I think this problem has already been mostly solved. See the winEmbed example in the tree. Also, to address your first question, please see http://benjamin.smedbergs.us/blog/2005-07-29/the-testing-matrix/ for why we strongly discourage people from trying to make the smallest possible version of Mozilla, rather than using the standard tested version. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Programmer Challenge: Worlds Smallest Gecko Browser DLL for C++ programmers to use in their apps? (programmatically controlled, ultra minimalistic--ultra fast)
On 8/9/10 11:12 AM, g...@novadsp.com wrote: Whilst the default build settings for Firefox may perfectly suit the needs of the Firefox team, they do not neccessarily fit well with embedding hosts. Shared runtime libraries being a case in point. Surely non-standard builds can be tested in exactly the same way as any standard Mozilla Firefox release? It's not whether they *can* be tested, it's whether they *are* tested. Most of the interesting bugs that are associated with minimal build options and unusual build configurations are not caught by automated tests, but by beta-scale testing in the field. That's why we strongly encourage everyone to use a shared configuration. In any case, you'd be signing yourself/your company up for lots of additional testing work for a goal which isn't shared by the Mozilla community. That makes little sense from an economic perspective. WRT 'why does this matter to you'. Religious issue perhaps. I would always opt for the smallest possible installation footprint. Static linking over dynamic to ensure minimum version hassles, with runtime support files in a single checksummed, versioned, archive. Much simpler installation/removal and much less work to verify when problems are encountered. We are trying to reduce the number of support files we ship using omnijar packaging, but that is an effort to improve performance across the board. But saying that there should be *no* shared libraries is not yet a realistic goal. NSS, for example, requires shared library configurations by default for proper functioning. From the POV of development then a single static library, build configuration controlled by a VS project file, makes it *much* simpler to integrate FF. And let's not even start on debugging/spelunking the code. Could you be more specific? You can certainly use a MSVC project file to build against a prebuilt SDK (downloaded from the Mozilla site, if you want), and the debugging information is available from the Mozilla symbol server. If you mean that you want to build mozilla itself using a MSVC project file, that is not a realistic goal right now and I will not accept patches of that sort. It would require transforming all of our existing build logic using something like gyp or cmake, which is a monumental task. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Programmer Challenge: Worlds Smallest Gecko Browser DLL for C++ programmers to use in their apps? (programmatically controlled, ultra minimalistic--ultra fast)
On 8/9/10 12:00 PM, g...@novadsp.com wrote: My notion is that the standard make-driven build process generates a VS project file. Thus no additional dependencies or maintenance required. In a corporate context I'd expect one dev/make monkey to generate said VSP for use by relevant team members. This would not only offer much better flexibility re VS versions (2005/2008/2010 all now in wide deployment) but means compilation times are slashed compared to bash/make/cl invocations. Have you seen how quickly VS2010 runs on the right kit? Oh. Then we can also use the profiling tools ... Please bear in mind that using VS projects is not just about simplicity/speed of adoption, it also has tremendous rewards in terms of tooling and automation - most notably with tools like Visual Assist. These make code navigation a snap and offer a massive boost to understanding component relationships etc. This, in turn, would/should mean a virtuous circle for Mozilla development too. Easier code navigation plus faster compile times in a highly productive and familiar environment is definitely likely to mean more bug fixes and code optimisations ... I think we're fully off-topic now, so the rest of this discussion should head to mozilla.dev.builds. We could spend significant energy making a system that produces MSVC project files and integrates tightly with tools such as Visual Assist. Or we could spend time solving the same problems in a cross-platform manner that helps all of our developers. I hope it is an obvious decision that we have taken the latter path. With tools such as DXR, you can browse the code in your web browser http://dxr.mozilla.org/. This same static analysis data can be hooked into context-sensitive development environments such as emacs or Komodo. We have also spent significant energy making builds much faster on Windows with pymake and native commands, to the point where soon a windows build will probably faster using pymake than it would be as a native project file. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Programmer Challenge: Worlds Smallest Gecko Browser DLL for C++ programmers to use in their apps? (programmatically controlled, ultra minimalistic--ultra fast)
On 8/9/10 12:00 PM, g...@novadsp.com wrote: On 09/08/2010 16:31, Benjamin Smedberg wrote: In any case, you'd be signing yourself/your company up for lots of additional testing work for a goal which isn't shared by the Mozilla community. That makes little sense from an economic perspective. That's my call. Not yours. The up front build/test cost may be way less than the downside support costs. Sure. I am saying that as owner of the Mozilla embedding code, I believe you are making a mistake, and that I don't think that the mozilla community should spend time implementing your vision. What you do is of course up to you! --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
API Compatibility in Mozilla 2+
This is a followup to presentations which occurred in the development meeting in June, as well as presentations at the Mozilla summit. Please direct questions and followup to the mozilla.dev.platform group. In order to improve performance and maintain the Mozilla codebase, we have decided that now is the right time to make more aggresive changes which break older code in ways which are not backwards-compatible. This is already evident in the changes to XPCOM registration, and will be continued in the future. As part of this decision, we have switched the Gecko version number to 2.0 for the next major release (Firefox 4). The new rules for interface compatibility are written here: https://developer.mozilla.org/En/Developer_Guide/Interface_Compatibility There are different layers of compatibility: * Web content APIs: very stable * Jetpack APIs (when the Jetpack SDK reaches version 1.0). Stable. Compatibility will preserved if at all possible. * Scriptable APIs (JS/XUL/XBL): May change between major versions. Developers should carefully consider the impact of changes, however, and design APIs to be backward- and forward-compatible when appropriate. * Binary APIs (XPCOM interfaces): extensions with XPCOM binaries will need to be recompiled with each major version of the platform (2.0, 2.1, etc). Interfaces formerly marked with @status FROZEN are no longer considered frozen and may change in the future. We have been preparing for this change for a while: the ctypes and jetpack projects are designed so that developers can transition from unstable XPCOM interfaces to stable APIs. Note that the change to Mozilla 2 does not mean that we are switching to GCed XPCOM objects, nor are we switching to C++ exceptions. This is not opening the floodgates to make lots of arbitrary changes to APIs just because they are now unfrozen. All changes should be carefully considered, weighing the potential benefits against the costs both within the Mozilla codebase and to third-party code such as extensions. We are not planning on re-freezing XPCOM interfaces in the future. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Firefox Python bindings
On 7/20/10 11:13 AM, sultan wrote: Hello, Is there anyway to use Firefox or Gecko core from within python e.g. import Firefox or import Gecko? So far for now I am using QtWebKit. There is a project called PyXPCOM, but it is primarily focused on using python within XULRunner applications, rather than using gecko from within python: https://developer.mozilla.org/en/pyxpcom --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Embedding and associated /dist folders
On 7/13/10 9:29 AM, g...@novadsp.com wrote: Is there a mechanism to allow the file resources in /dist/chrome and /dist/components etc to be packed into a shared library (DLL on Windows?) Not currently. With the new 'omnijar' work it may become easier, because you can embed all the mozilla resources into a single JAR and use that. Would creating and registering some custom resource handler do the trick? I would like to reduce the apparent footprint of an embedded installation. I question your motives: the only people who are going to care are people who look up the list of files in Explorer, and I really don't think that's an especially important case (worth spending coding/packaging time). A single file can help speed startup time, which is why we are working on it at all. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Downloading and data mapping from zip-archive
On 7/9/10 6:28 AM, Cyril wrote: Please help me to find a solution of the following problem: there is some zip-archive which contains html, css, js etc. I need a browser calls to my code and then the code takes the data from zip-archive. Is it possible to realize it without the new protocol of OS (a solution should be cross-platform)? Thank you. Mozilla already has a built-in protocol which would let you navigate this data directly, the jar: protocol. A JAR is just a ZIP file served with a specific MIME type. jar:http://www.example.com/foo.jar!/index.html will load /index.html from within foo.jar. foo.jar needs to be served with the application/java-archive MIME type. https://developer.mozilla.org/en/Security_and_the_jar_protocol has a few more details. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Plugin crash protection and GtkMozEmbed
On 6/28/10 8:23 AM, Glen Gray wrote: Hey Guys, I'm wondering if GtkMozEmbed based applications will take advantage of the plugin crash protection offered under the release of FireFox 3.6.4/ xulrunner 1.9.2.4 ? Are there are recommended ways of testing this crash protection ? -- Glen Gray sla...@slaine.org The OOPP (out-of-process plugins) behavior is controlled by preference values. Currently, those preferences are only enabled in the Firefox build, not in other applications. If you like, you can enable them and see what happens in your embedding: it shuold probably work, as long as the directories are set up correctly so that the plugin runtime executable is found. See http://mxr.mozilla.org/mozilla1.9.2/source/browser/app/profile/firefox.js#914 for the preferences that Firefox sets. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Plugin crash protection and GtkMozEmbed
On 6/28/10 10:04 AM, Glen Gray wrote: So to be clear, I can enable this for all plugins via dom.ipc.plugins.enabled.plugin_name true OR, I can enable it for all plugins via dom.ipc.plugins.enabled true Is that correct ? Yes. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
NS_InitEmbedding is gone
The NS_InitEmbedding API, which was replaced by XRE_InitEmbedding several years ago, has finally been removed from the tree and will not be available in the next release. If you are still using this API, please switch to XRE_InitEmbedding (or use NS_InitXPCOM2 directly). This happened in bug 569948, for the record. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Question about gtkmozembed_glue.cpp
On 4/19/10 5:24 PM, n179911 wrote: If browser/gtk/tests uses browser/gtk/src by linking to libxul.so (since you mentioned it is built to a static library as a part of libxul.so), I don't understand why this does not link: The tests use standalone linkage. They do not link directly to libxul.so, but instead find it dynamically at runtime, load it using dlopen, and load the necessary imports. This is why gtkmozembed_glue.cpp exists: to provide stub functions so that the dynamic loading works correctly. --BS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Question about gtkmozembed_glue.cpp
On 4/18/10 4:25 PM, n179911 wrote: In 'gtkmozembed_glue.cpp', it has this comment '// This file is an implementation file, meant to be #included in a // single C++ file of an embedding application. It is called after // XPCOMGlueStartup to glue the gtkmozembed functions.' My question is why it is not compile like the rest of the cpp files in src directory (e.g. EmbedProgress.cpp) and have TestXXX.cpp in test directory linked to the library created in src? Mostly because it would have to be a static library different from the existing files in that directory, and by the limitations of our build system we would have to put it in a different directory, and it wasn't worth the hassle. What do we gain by making it a separate/new static library, instead of just #including it as documented? --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: SpiderMonkey ctypes
On 4/17/10 1:33 PM, Michael I wrote: You're in luck. ctypes was just recently moved into Spidermonkey (js/src), in bug 538324. There is now a function JS_InitCTypesClass which is available if you configure spidermonkey --enable-ctypes. Of course this is only available on bleeding-edge spidermonkey, not any releases. that's great :) We are using little bit older SpiderMonkey (from Firefox 3.5.3) Do you think it would be hard to include ctype in this version, does it use some new features of SpiderMonkey, or is it a matter of changes in includes and makefiles ? I don't know. You'd have to ask in mozilla.dev.tech.js-engine, the spidermonkey newsgroup. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XPCOM and Firefox's thread model
On 4/14/10 4:01 AM, flt...@yahoo.com wrote: For example (again, this is not what I am trying to do, but just an example to illustrate) if I want to periodically clean all the cache in the background, withou user interaction, I would say create a thread that calls nsICacheService's method to do that. But how would I get to make that call in the main thread? There are two possible solutions. The easiest solution here is simply to use nsITimer. It will fire a periodic notification on the main thread. The more complicated solution that I don't recommend unless it's absolutely necessary is to create a separate thread and periodically send the main thread an event (a nsIRunnable) when you want it to do something. See nsIThreadManager/nsIThread for details. The problem with this approach is that you have to be very careful about thread synchronization if there are any shared structures. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XPCOM and Firefox's thread model
On 4/14/10 9:31 AM, Georgios Petasis wrote: Does Mozilla assumes that has the control of the main thread? (And wants to run a message loop on it?) Mozilla assumes that there is a message loop on the main thread, yes. There are slight differences between whether we spin our own event loop (using nsIAppStartup.run or nsIAppShell.run), or whether the embedder does it for us, but in either case gecko can't function without an event loop. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XPCOM and Firefox's thread model
On 4/14/10 10:04 AM, Georgios Petasis wrote: I have written some C++ code, which interfaces Mozilla with Tcl/Tk. Tcl/Tk is the owner of the main thread, and runs a message loop on it. My code somewhat works: I can start Mozilla, load a few pages (~10), and then everything locks. :-) I still have no solution why. At some point, I will call a function from Mozilla, that will never return. Killing the app is the only solution. Any ideas welcomed :-) Presumably you can get a stack trace from the hang in a debugger. That would provide clues! --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XPCOM and Firefox's thread model
On 4/13/10 1:44 PM, hap497 wrote: Is main thread same as 'UI' thread? Yes. For example, if I click a button to submit a form. These will happen: 1. build a query string 2. send the HTTP Post/Get This step may occur on multiple threads. Our network engine internally uses threading so that the main thread is never blocked on network activity. But that threading is entirely internal to necko and isn't visible to the client code (the DOM). 3. get the html data back. 4. relayout the page. Are all these running in the Main Thread? Yes. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XPCOM and Firefox's thread model
On 4/12/10 3:49 AM, flt...@yahoo.com wrote: My question is, how would I ensure my calls are thread safe? Does XPCOM guarantee that I can call the XPCOM interface functions from any thread and internally Firefox will ensure the thread safety? No. Most Mozilla interfaces are *not* thread safe, and you should only call them from the main thread. Why are you trying to use threads? --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Fix for NS_InitEmbedding documentation
On 2/3/10 4:04 PM, Timothy Madden wrote: Follow up to mozilla.dev.embedding please. On this mozilla.org page http://www.mozilla.org/projects/embedding/embedapiref/embedapi2.html#1099700 about Embedding Initialization I think the documentation for NS_InitEmbedding should say the first parameter aMozBinDirectory should be nsnull to indicate the *main executable* directory instead of nsnull to indicate the *working* directory. Yeah, we've had problems in the past where we have a confusing XPCOM working directory parameter which has nothing to do with the OS working directory. The executable directory is clearer. Although, I strongly suggest always passing a value for this item and never passing null. I think the documentation should also say that if user wants to have the entire xulrunner SDK in a different directory, including xpcom.dll and nspr4.dll for the XPCOM architecture, then user should, at least with Visual Studio, also use delayed loading of imports for these libraries and provide a delayed loading hook function as described in MSDN to load this libraries from the given directory with LoadLibraryEx and the ALTERED_SEARCH_PATH flag. This is not the best/good way to do this. Instead, use the standalone XPCOM glue and XPCOMGlueStartup(), which a cross-platform method of dynamically loading the platform from an arbitrary directory without linking against it directly. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XRE_InitEmbedding Fails.
On 11/25/09 4:32 AM, Blaine Monkey wrote: executables, I think this is the correct way, in't it? I saw the code of other examples and is the same. I don't know what can be the problem. Any idea? No, you'll need to actually debug the problem. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XRE_InitEmbedding Fails.
On 11/24/09 9:41 AM, Blaine Monkey wrote: I've a xulrunner C++ embedding example, it compiles and generates the executable, but when I run it, the XRE_InitEmbedding fails. I've xulrunner installed in /opt/xulrunner-1.9.1.4 What am I doing wrong? The code doesn't look bad offhand. I was a bit suspicious of passing null for the second parameter of XRE_InitEmbedding, but the code appears to deal with that: http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsEmbedFunctions.cpp#97 I think your best bet is probably to step through and figure out why it's not working. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: crash by embedding xulrunner 1.9.1.5/firefox 3.5.5
On 11/10/09 8:36 AM, Viktor Tymoshenko wrote: Hi all, it seems that embedding does not work anymore just after the use of TLS(thread local STORAGE) variables was introduced in order to make NS_IsMainThread faster. (see http://hg.mozilla.org/releases/mozilla-1.9.1/log/27d9d4107522/xpcom/threads/nsThreadManager.cpp) bug 526586 --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Help: Newbie needs some TLC Please
On 10/26/09 4:49 AM, graniteglory wrote: 3. I can not find MFCEmbed anywhere including mozilla-1.9.1/embedding/ tests MFCEmbed was very old, unmaintained and broken code and has been removed. 4. Other tests (winEmbed, wxEmbed) do not compile correctly or VC++ project does not convert or work wxEmbed is also unmaintained and broken, and has been removed in later versions. winEmbed does work, last I checked, but I don't know about any VC++ project file: it probably only builds with the standard mozilla makefiles. 6. I searched google and read mozilla developer document. It is confusing and not very up to date. Which document did you read? 1. Do I need to download firefox source code for this task ? Not necessarily, I think you can probably just use the https://developer.mozilla.org/En/Gecko_SDK and prebuilt XULRunner binaries. 2.4 (yes or no) MozillaBuildSetup-Latest.exe (ftp://ftp.mozilla.org/ pub/mozilla.org/mozilla/libraries/win32/) If you are using MSVC projects to build your code, you probably don't need mozillabuild. 3. Is there simple gecko sample application with VC solution/project where I can look how to do ? Is it MFCEmbed or winEmbed ? No, there is not. But you can probably get things working by reading the winEmbed code and copying the bits that are relevant to you and creating your own MSVC project file. See https://developer.mozilla.org/en/XPCOM_Glue for the compile and linker flags you'd need to use. Note that this is not a common usage any more, so there aren't going to be a lot of examples out there to follow. Feel free to ask followup questions in this newsgroup if you get stuck. 4. Is there binary Win32 gecko I can get without compiling firefox myself for embedding task ? Yes, it's called XULRunner. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Missing libgtkembedmoz.so when upgrading XULRunner!
On 8/25/09 1:47 AM, SimOut wrote:
--
static const GREVersionRange greVersion = {1.9a, PR_TRUE, 2,
PR_TRUE };
GRE_GetGREPathWithProperties(greVersion, 1, nsnull, 0, xpcomPath,
sizeof(xpcomPath));
XPCOMGlueStartup(xpcomPath);
GTKEmbedGlueStartup();
GTKEmbedGlueStartupInternal();
gtk_moz_embed_set_path(xpcomPath);
---
And link to the following libraries:
---
-L/usr/lib64/xulrunner-sdk-1.9/sdk/lib
-L/lib64
-lxpcomglue
-lgtk-x11-2.0
-lgdk-x11-2.0
-latk-1.0
-lgdk_pixbuf-2.0
-lm
-lpangocairo-1.0
-lpango-1.0
-lcairo
-lgobject-2.0
-lgmodule-2.0
-ldl
-lglib-2.0
---
This looks correct to me. What errors do you see using this method?
--BDS
___
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
Re: Missing libgtkembedmoz.so when upgrading XULRunner!
On 8/25/09 7:45 AM, SimOut wrote:
Maybe I have specified the incorrect GREVersionRange? Does my current
range include 1.9.0.12:
{1.9a, PR_TRUE, 2, PR_TRUE } ?
That looks ok, although I would probably do {1.9, PR_TRUE, 1.9.0.*, PR_TRUE.
What XULRunner is it actually finding? You can check by printing xpcomPath
after GRE_GetGREPathWithProperties.
--BDS
___
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
Re: Using firefox inplace of XULRUNNER for running XUL application
On 8/24/09 7:16 AM, Mayank wrote: Is it possible to use firefox as XULRUNNER, where I can write a XUL file to make a browser and run it on the existing firefox (using it as gecko and javascript engine), then I can run my application in the new xul browser. Yes, you can use firefox -app to launch a XULRunner application. Note that the Firefox components will still be present and may cause some behavior differences, but this normally doesn't matter in practice. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XPCOMGlueStartup failure in release version
On 3/3/09 5:18 PM, Igor Ulyanov wrote: The problem is in LoadLibraryEx with xul.dll and later xpcom.dll FormatMessage in cpp file nsgluelinkinwin.cpp wprintf with GetLastError prints garbage in console (something like ). If i add any code This is probably a problem with DLL dependencies of some sort. You can use the Profiling tool in Dependency Walker to view DLL loads (and in particular failed DLLs loads). --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XPCOMGlueStartup failure in release version
On 3/2/09 12:37 PM, Igor Ulyanov wrote: Who can help with such problem? Debug version of my embedded program works fine, but release version failes at XPCOMGlueStartup. I have changed some mozilla interfaces but not sure it is the reason. Have you stepped through to figure out what exactly is failing? You should be able to do a release version with debugging symbols. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XPCOMGlueStartup failure in release version
On 3/2/09 2:44 PM, Igor Ulyanov wrote: On 3/2/09 12:37 PM, Igor Ulyanov wrote: Who can help with such problem? Debug version of my embedded program works fine, but release version failes at XPCOMGlueStartup. I have changed some mozilla interfaces but not sure it is the reason. Have you stepped through to figure out what exactly is failing? You should be able to do a release version with debugging symbols. seems XPCOMGlueLoad fails, but only in release version, debug is ok Sure. Did you step through it in the release version? --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: embedding build in firefox-3.* / xulrunner-1.9?
On 2/5/09 7:17 AM, Anna Nachesa wrote: Hi, I have tried to create the embedding build: i.e. after a successful build, I do the following: cd builddir/embedding make cd builddir/embedding/config make Don't do this. It may have been the right thing to do some time long ago in the past. Now XULRunner is the embedding solution, and you should just build it normally. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: GRE binary extension
On 1/15/09 7:10 AM, Dmitry V. Zhulanov wrote: Hello, Developers! I try to implement custom protocol handler. I follow [1] to create VC project, and use chrome protocol handler as base. If I install my handler to firefox its all ok. But If I install it to GRE nothing happened. I try even put application.ini with own settings with BuildID, but it does not help. I can't see my dll loaded in modules list in Process Explorer. Please, help to install my binary extention to GRE, I have *.xpt and *.dll file and application which use GRE. I'm not sure what exactly you're trying to do. By GRE do you mean XULRunner? Why are you putting a component in XULRunner? You should really never do that: keep it as part of your application. In any case, there's a page for debugging component-loading issues: https://developer.mozilla.org/en/Troubleshooting_XPCOM_components_registration --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: need smaller xul.dll
Dmitry V. Zhulanov wrote: I'd like to reduce download size. And I don't need XUL. I want to get html only render, without extensions like address bar or any other XUL widgets. So I want to remove as many as possible. I don't think you will achieve much smaller download size and your embedding app would have to re-implement all kinds of alert/security UI because you can't use the default UI. You can safely remove spellchecking dictionaries if you don't want input spellchecking: with that and good 7zip compression like the Firefox installer uses you can get the download weight below 5 MB (Windows). Asking for less than that is asking for trouble. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Use gtkembedmoz avoiding load-time dependency on xpcom ?
[EMAIL PROTECTED] wrote: When I use embedding glue, a small local html file comes up in 22s, 7 seconds is spent in XPCOMGlueStartup. When I use Dependent glue, the same local html file comes up in 15s seconds. I do not call XPCOMGlueStartup. Now you need to profile the 7 seconds in XPCOMGlueStartup to see where the time is being spent. I suspect that it's almost all in the dynamic linker, loading the .so files off disk and performing relocations, but before going further you should confirm my suspicions. I think you're indeed ;-) Would the use of gcc 4.2 improve start-up time in a significant way ? both in dependent and embedding glue ? If relocation-processing time is the issue, then yes, gcc 4.2 will significantly improve load time of libxul.so in both scenarios. The only difference should be *when* the relocation is performed: 1) dependent glue: loading libxul.so and doing relocations performed at startup time, before main() 2) embedding glue: loading libxul.so and doing relocations performed at XPCOMGlueStartup time --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Use gtkembedmoz avoiding load-time dependency on xpcom ?
[EMAIL PROTECTED] wrote: Hello, I have a written a small web browser based on gtkembedmoz that was working fine with firefox-2. Then I have switched to firefox-3 and I have noticed that i have to use GRE_GetGREPathWithProperties, XPCOMGlueStartup and GTKEmbedGlueStartup to make it usable again with xulrunner-1.9. It works also fine except it spends a lot of time at start-up loading the required libraries. According to this webpage : Can you be specific about where the time is being spent? Loading libraries can be expensive no matter what. Is it possible that the delay is just more noticable to you because rather than taking the hit at startup (the dynamic loader links the libraries before calling main()) the load happens during execution of your program where it's more apparent? http://developer.mozilla.org/en/XPCOM_Glue#Frozen_linkage.3a_dependent_glue_(dependent_on_xpcom.dll) Embedding code which wishes to use only frozen symbols and cannot tolerate a load-time dependency on xpcom.dll should #define XPCOM_GLUE 1 while compiling, and link against xpcomglue.lib. It should not link against xpcomglue_s.lib or xpcom.lib I have tried it, I do not call XPCOMGlueStartup and GTKEmbedGlueStartup any more, but my browser gives me a sigsev as soon as I call gtk_moz_embed_set_path. I think I'm lacking an init or something... You're lacking XPCOMGlueStartup/GTKEmbedGlueStartup. I don't understand why you removed them, since they are the code which initializes everything. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Use gtkembedmoz avoiding load-time dependency on xpcom ?
[EMAIL PROTECTED] wrote: Can you be specific about where the time is being spent? Loading libraries can be expensive no matter what. Is it possible that the delay is just more noticable to you because rather than taking the hit at startup (the dynamic loader links the libraries before calling main()) the load happens during execution of your program where it's more apparent? I'm using a low power ppc cpu and it spends 6seconds in XPCOMGlueStartup. With FF2 libs , my web page comes up in 13s, with xulrunner-1.9 my web page comes up in 22s. Did your startup time change? That is, did loading gecko always cost 9 seconds, but we've moved it to a different place, or is this a completely new 9 second delay? Reading this page http://developer.mozilla.org/en/XPCOM_Glue I would have think that there was a way to start my browser quicker without having to call XPCOMGlueStartup/GTKEmbedGlueStartup. It was what I understood according to the following text: Embedding code which wishes to use only frozen symbols and cannot tolerate a load-time dependency on xpcom.dll should #define XPCOM_GLUE 1 while compiling, and link against xpcomglue.lib. It should not link against xpcomglue_s.lib or xpcom.lib. Your understanding is incorrect. We *always* have to load XPCOM. The difference is how we load it: Dependent glue: you link directly against libxpcom.so (this is called a load-time dependency). The dynamic linker does the loading for you at startup time. Functions are called directly. Embedding glue: you don't link directly against libxpcom.so. Instead, you programmatically load libxpcom.so and populate the functions you want to use as function pointers (using XPCOMGlueStartup and GTKEmbedGlueStartup). You're probably going to need to generate some profiles of the time spent in XPCOMGlueStartup. Providing more details about your setup would also help, for instance: * What OS? * What library model (ELF, Mach-O, etc) * What compiler, and what version? Does that compiler support hidden-visibility pragmas correctly? Proper support for ELF hidden-visibility pragmas was fixed in GCC 4.2... using and older version of GCC will definitely cause increased startup time because the dynamic linker will have to perform thousands of relocations when you load the gecko libraries. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Link Errors with Firefox 3
John Cebasek wrote: We have a plugin and associated dylibs on Mac OS X that works with Firefox 2, which now must be brought up Firefox 3. I've got the code compiling, but I'm having a weird link error. Well, it's not that weird, it's not finding a bunch of symbols. But where did they go? The (beginning) of the errors are as follows: __ZNK9nsAString12BeginReadingEv __ZN9nsAString17DefaultComparatorEPKtS1_j __ZNK9nsAString6EqualsERKS_PFiPKtS3_jE __ZNK10nsACString12BeginReadingEv /build_files/VizibleObjectModelImpl.build/Debug/VizibleObjectModel(STLport).build/Objects There are two versions of nsAString. There is the internal, unstable version, and a frozen/stable version. It appears that you are (correctly) linking to the stable version, but are not linking against the necessary libraries. Please see http://developer.mozilla.org/en/docs/XPCOM_Glue You want the Frozen linkage: dependent glue strategy. When I first compiled Firefox to build the dylibs, I just followed the instructions on mozilla developer page. MinefieldDebug seems to work just fine! Our build script just cd's to the mozilla directory and calls the make -f client.mk build command. Here's our mozconfig: . $topsrcdir/browser/config/mozconfig . $topsrcdir/build/macosx/universal/mozconfig ... ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk mk_add_options [EMAIL PROTECTED]@/../build mk_add_options MOZ_MAKE_FLAGS=-j4 # use parallel make This is the only part of the mozconfig you should have. Please remove all the rest of the options, especially options such as --disable-libxul and --enable-xpcom-obsolete which cause fairly radical changes to the linking strategy used for the app. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Embedding App Link Error
steve lu wrote: Hi, I am linking my embedding app against the FIREFOX_3_0_1_RELEASE and MOZ_CO_PROJECT=xulrunner code base and following libs. nspr4.lib plc4.lib plds4.lib xul.lib xpcomglue.lib profdirserviceprovidersa_s.lib jpeg3250.lib And with XPCOM_GLUE=1 defined, I am getting these link errors: error LNK2019: unresolved external symbol public: int __thiscall nsRect::IntersectRect(struct nsRect const ,struct nsRect const ) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z) referenced in function public: virtual void __thiscall BrowserFrame::threadUpdate(void) ([EMAIL PROTECTED]@@UAEXXZ) There are a bunch of problems here ;-) * it doesn't make sense to link against xul.lib and xpcomglue.lib at the same time. You either need to 1) use standalone linkage. Link only against xpcomglue.lib. Don't link against NSPR/xul.lib at all. Define XPCOM_GLUE 2) use dependent linkage. link against xul.lib, xpcom.lib, and xpcomglue_s.lib. Don't define XPCOM_GLUE * You're trying to link against nsRect. I'm not sure why, but you can't use nsRect. It is an internal API and is not avaialable to you. You should figure out why you're trying to link with these symbols and remove the dependency. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Does 1.9 sources support nsIProfile, or am I missing something?
Alexey 'Spry' Pelykh wrote: The subject is that I want to use some kind of dynamic profile switching, and as far as I understand nsIProfile was used to do that. But the posts I've read are dated back to 2006, and now it seems to be or deprecated or completely out of date. 'Creation' of nsIProfile always return that there is no factory. And in those posts there was a compiler define MOZ_SINGLE_PROFILE, and when it was not defined, Mozilla sources supported multi-profiles. But now there is no usage of such flag. Can someone please explain what am I missing or just explain how it is done in Mozilla 1.9 Firefox has never supported nsIProfile or dynamic profile switching, and that code has been removed from the codebase altogether in the 1.9 cycle. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Does 1.9 sources support nsIProfile, or am I missing something?
Alexey 'Spry' Pelykh wrote: 1) So, now the load of my cookies cache, preferences etc. is made somewhere inside nsr = nsProfileDirProvider-SetProfileDir(nsLocalAppDataDir); ? Not exactly. SetProfileDir just sets up a directory service provider. Then other code can at any time ask what is the profile directory and the provider will respond. 2) So, if the above statement is somehow correct, it means, that a single instance of Mozilla environment(embedding env.) is bindned to some profile directory, where it stores some settings, etc.? Mostly, yes: in order to save any cookies/history/preferences, you have to have a profile directory. You can only have one profile directory per process. 4) If #3 statement is correct, then I have to manually load/store my preferences via nsIPref? I'm not sure I understand the question, but I'll take a guess: The normal way to do keep users preferences is 1) select a profile directory 2) use nsIPrefService/nsIPrefBranch to save named preferences --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Does 1.9 sources support nsIProfile, or am I missing something?
Alexey 'Spry' Pelykh wrote: 2a) savePrefFile(nsIFile aFile); to save, needs to be called manually? 2b) readUserPrefs(nsIFile aFile); to load, also needs to be called No, you should not need to do anything with the pref files. When the prefservice is created it will do all the correct things. So, as far as I understand, only a single call to nsProfileDirProvider- SetProfileDir(nsLocalAppDataDir); is valid? Second will be ignored? Or I can set new profile directory and then work with it? You should not try to calls setProfileDir a second time. There is a lot of code in the project which will get confused if you move things out from under it. Cookies are also stored in my profile directory? Cache also? Yes. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: how to use gecko_sdk?
Brightman wrote: a compile problem . the program can't find GRE_GetGREPathWithProperties in libxpcomglue.a c++ -g -o test -I ../mozilla/dist/include -DDEUBG -DXPCOM_GLUE -I../ mozilla/dist/sdk/include -L../mozilla/dist/bin -Wl,-rpath-link,../ mozilla/dist/bin/ -L../mozilla/dist/sdk/lib ./libxpcomglue.a - lembed_base_s -fno-rtti -fno-exceptions test.cpp /tmp/ccumJrf0.o(.text+0x3f): In function `main': /home/mozilla/test/test.cpp:19: undefined reference to `GRE_GetGREPathWithProperties' /tmp/ccumJrf0.o(.text+0x79):/home/mozilla/test/test.cpp:24: undefined reference to `XPCOMGlueStartup' collect2: ld returned 1 exit status Your compile command is incorrect. You must list test.cpp before libxpcomglue.a, because ordering is important for the linker: unresolved symbols are only searched in libraries listed later in the command line. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Mozillz subdirectory created when I call NS_InitEmbedding
Tom wrote: When I call NS_InitEmbedding there is a Mozilla empty subdirectory created at C:\Documents and Settings\user\Application Data \Mozilla. The call stacks look like the following: ... Is there a way to make it not create the Mozilla subdirectory? Thanks. Not easily, no. You would have to refactor a lot of our code which assumes that directory is in place. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: .manifest file for embed.jar
[EMAIL PROTECTED] wrote: The build does not complain about xulrunner directoy missing. I'm currently building using the following .mozconfig file (obtained from ubrowser), with some modifications (--enable-static and --disable- libxul). Why are you making these modifications? Static builds are not embeddable. I'm building a special purpose application where I only need the rendering engine and http(s) protocol support. I don't need plugin or extension support. I would also replace the cookie handling - implement cookie managment myself. Can you please suggest me a good .mozconfig options to achieve that? I strongly discourage you making changes. See http://benjamin.smedbergs.us/blog/2005-07-29/the-testing-matrix/ for my reasoning. Disabling these feature will not signficantly affect the performance or download weight of your application, but it could cause unexpected failure modes. You have a long list of configure options below. I strongly suggest you remove all of them, and just do --enable-application=xulrunner for a release build and --enable-application=xulrunner --enable-debug --disable-optimize for debugging. The more options you specify, the more likely you are to get something wrong. The only other option you really might need is --disable-javaxpcom if you don't have a JDK installed. ac_add_options --enable-static ac_add_options --disable-libxul You do not want these options. Libxul is faster and better to embed than other build flavors. ac_add_options --disable-profilelocking Not recommended. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: .manifest file for embed.jar
[EMAIL PROTECTED] wrote: Thanks Benjamin. When I try to build xunrunner, the build process stops at looking for a make file under xulrunner directory. I don't see any xulrunner directory under 1.8.1 (firefox 2.0) source trunk. This is because you only have the Firefox sources, you don't have the XULRunner sources... Here is my .mozconfig file for building xulrunner application. mk_add_options MOZ_CO_PROJECT=xulrunner This line should tell client.mk to check out the Firefox sources, *if* you're running `make -f client.mk` or `make -f client.mk checkout` if you're only running `make -f client.mk build` then you won't ever check out new sources. Can you please provide me right instruction to build xulrunner application? I'll also try to build mozilla 1.9. I believe you are referring to firefox 3.0 source trunk - ftp://ftp.mozilla.org/pub/firefox/releases/3.0b5/source/firefox-3.0b5-source.tar.bz2. The best way to get the latest xulrunner 1.9 sources is from CVS: http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Via_CVS --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: .manifest file for embed.jar
Babu Katchapalayam wrote: I followed the instruction as per these articles: http://developer.mozilla.org/en/docs/Mozilla_Embedding_FAQ:Embedding_Gecko#How_do_I_make_an_embedding_build.3F This document is, unfortunately, extremely outdated and should probably be deleted. The correct way to embed Mozilla is to build and ship XULRunner. Most of the other directions for how to embed will remain the same. I also recommend 1) use the mozilla 1.9 codebase, not 1.8.1 2) use winembed as your embedding example... it's much simpler and loads the glue more correctly. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: .manifest file for embed.jar
Babu Katchapalayam wrote: I built Firefox 2.0.0.13 trunk and created an embedding package with out any client.win files. I'm using MSVC 6 and Feb 2003 PSDK as per the build documentation. Following is my .mozconfig file for this build. How did you create an embedding package? The correct way to embed Mozilla is by building and embedding XULRunner. There is no embed.jar in xulrunner. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: multiple instances of Gecko in one process?
fretnoise wrote: Hi, I'd like to embed Gecko in a Java server, which would require multiple instances of Gecko running all in one process. How much is this already supported? What do you mean by instance of gecko? If by instance of gecko you mean multiple calls to NS_InitXPCOM, that is not supported and will not work. If you mean multiple documents, sure, we do that all the time with multiple browser windows. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XRE_InitEmbedding gecko 1.9 c++
[EMAIL PROTECTED] wrote:
Currently I'm only linking to xpcomglue.lib and call XPCOMGlueStartup
instead.
I was basically following this strategy now:
http://developer.mozilla.org/en/docs/XPCOM_Glue
There are three strategies listed on that page... you're using the
standalone form. Are you defining XPCOM_GLUE?
But I'm unsure about the difference of XPCOMGlueStartup and
XRE_InitEmbedding.
Yeah, this is a bit confusing and we need better docs. I will try to
explain, and I hope somebody will turn this into a reasonable page on
developer.mozilla.org:
XPCOMGlueStartup is only for use when using standalone linkage. It
dynamically loads the XPCOM libraries and so that you can call functions
provided from XPCOM: all of the NS_* functions declared in nsXPCOM.h. It
does *not* initialize XPCOM! It does *not* dynamically load the XRE_* functions.
After you have called XPCOMGlueStartup, you could call NS_InitXPCOM2 and
manually initialize everything... but there are a lot of tricks necessary to
get XPCOM started, and XRE_InitEmbedding has most of those tricks already,
so...:
Instead, you should call XRE_InitEmbedding. However, that functions hasn't
been dynamically loaded yet: you need to perform an extra dynamic-linking
step before you can call this function... in code, it would look something
like this:
static const nsDynamicFunctionLoad kXRESymbols[] = {
{ XRE_InitEmbedding, (NSFuncPtr*) XRE_InitEmbedding },
// If you need other XRE_ functions such as XRE_LockProfileDirectory,
// add them to the list here:
{ XRE_LockProfileDirectory, (NSFuncPtr*) XRE_LockProfileDirectory },
{ nsnull, nsnull }
};
XPCOMGlueLoadXULFunctions(kXRESymbols);
// Now you may call XRE_InitEmbedding
In summary, the sequence of functions you want to call is:
* GRE_GetGREPathWithProperties (if you don't know where XULRunner is installed)
* XPCOMGlueStartup
* XPCOMGlueLoadXULFunctions
* XRE_InitEmbedding
--BDS
___
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
Re: XRE_InitEmbedding gecko 1.9 c++
[EMAIL PROTECTED] wrote: Is it still possible to call XRE_InitEmbedding with the mozilla 1.9 branch (xulrunner). It seems there's no public interface anymore for that function(I can not link against it!). Am I right? Is it correct, that as of gecko 1.9 embedding is only possible with the XPComGlue interface? Is NS_InitXPCOM2 an alternative for XRE_InitEmbedding? It should be possible to call XRE_InitEmbedding... what libs are you linking against, and in what linkage configuration? --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: termEmbedding initEmbedding
krithika wrote: On Nov 26, 7:25 pm, Benjamin Smedberg [EMAIL PROTECTED] wrote: krithika wrote: I have embedded gecko in my java application and it works perfectly. After certain point of time i would like to do termEmbedding and again initEmbedding. This is not supported. Mozilla maintains some service state in globals which are not properly reset on shutdown. Any chance it will be fixed in xulrunner1.9. No, this is a design decision that will not be fixed. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: termEmbedding initEmbedding
krithika wrote: I have embedded gecko in my java application and it works perfectly. After certain point of time i would like to do termEmbedding and again initEmbedding. This is not supported. Mozilla maintains some service state in globals which are not properly reset on shutdown. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: profile.dll missing
Florian Winkler wrote: thanks for your reply. I did not fully get it. I thought WinEmbed is the far older sample / test project and that it was rendered obsolete by mfcembed. At least that is what i had read here: http://developer.mozilla.org/en/docs/Roll_your_own_browser_-_An_embedding_HowTo. Ok, the page is outdated, but even in the outdated page winembed was obsolete. Anyway, since you are the one on whose behalf the nice disclaimer at the top of that page was placed ;), I would like to ask you some questions. Question 1: what do you mean by old profile service? Is there a new one? Not really. Back in the days, the Mozilla suite supported dynamically switch profiles in the middle of running and had a profile service which did the dirty work. The new toolkit used by Firefox and Thunderbird (and now all applications) does not support this mode and has removed that profile service. There is a little replacement that allows advanced users to select a profile at startup, but this is not available during normal runtime. Question 2: you pointed out that embedding should be done with a build of XULrunner. Does that mean that XULrunner comes with all the libs and stuff that you need to create applications that include a gecko browser engine? I have difficulties clearly separating the functionality that is provided by e.g. Firefox and XULrunner on the other hand. I thought XULrunner is just a runtime environment for XUL apps. XULRunner is the Mozilla runtime packaged up without the Firefox frontend. It can be used to run XUL applications as well as for embedding. The XULRunner package itself contains only the runtime: it doesn't contain headers or link libraries needed to *create* a XUL/embedding application. These headers and link libraries are contained in the XULRunner SDK package. Question 3: I would actually like to embed a browser that behaves like Firefox, not only in the way it renders pages, but most of all, in such a way, that I can keep using my Firefox extensions and profiles with the embedded browser. I am not talking about the management (update, download, installation, etc.) of extensions, but I need an embedded browser that still reads extensions from a dedicated directory, like Firefox does. So that I could place my extensions there. Is that possible with Gecko? If so, do I have to build in any special way? Or is it even possible to actually embed Firefox, just by stripping off some GUI or so...? Well, that depends on what you mean by embed. Support for extensions is currently limited to apps which use the XRE_main API to start the application, which is typically XUL applications. This is because getting extensions registered properly sometimes requires that the process be restarted. You haven't really stated what you're actually trying to acheive with embedding, so it's hard to answer the question. Do you really just want webrunner or another minimal XUL application, or are you integrating with some external technology? Question 4: There is a lot of information spread all over the Mozilla sites that are related to embedding. However I find it extremely difficult to find a good starting point with the latest consistent information. I read a lot already, about XPCOM, and the many other techs (XPIDL, XPConnect,etc.). I managed to compile Firefox and even got mfcembed to compile and run under Visual Studio 2005. So I know already something, but still feel confused quite often. Do you have any good hint on where to look at first to get properly started with embedding? Nobody is actively maintaining the embedding documentation; it is old and outdated (as you have found out) and is very disorganized. I'd love for somebody to step forward and organize it! --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: profile.dll missing
Florian Winkler wrote: I tried to run mfcembed from the dist\bin directory and every time I select Edit-Profiles, the application crashes. I debuged it and found out that the profileService pointer is null, which means that the profile service was not prpertly retrieved. I also added a result code check, and it was an nsFailed. I checked the components directory in dist\bin and found out that profiles.dll is missing. I also tried to create the embedding distribution by running make in objdir\embedding\config, but in the dist\Embed there is also no trace of profile.dll. Does anyone have an idea, what this problem is? Why is profile.dll not compiled with firefox? profile.xpt is, by the way. The old profile service was part of the Mozilla suite/seamonkey, and is not used by Firefox or any toolkit applications. Incidentally, mfcembed is a really bad starting point for embedding and the code has been removed from the Mozilla trunk codebase. I strongly suggest starting with either winembed or the activex control. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: unresolved external errors - Begging for help!!!
[EMAIL PROTECTED] wrote: I am building Firefox 2.0.0.4 using the mozilla-build with VS 2005 in order to link XPCOM into a multithreaded dll for my application (currently debug). I have to use MOZILLA_INTERNAL_API because some of the non-frozen interfaces I need are not available in the Gecko-SDK (I know this will need to change for Firefox 3, but I need Firefox 2 now). I have built Firefox (numerous times with various options) with no problem. My problem is in building the dll in my application. I am getting the following unresolved external errors building with VS 2005: nsSubstring::Assign(unsigned short const *,unsigned int) (__imp_? [EMAIL PROTECTED]@@[EMAIL PROTECTED]) import.lib(xxx.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) nsCharTraits::EmptyBuffer(unsigned short const *,unsigned int) ([EMAIL PROTECTED]@G@@2PEBGEB) import.lib(xxx.obj) : error LNK2001: unresolved external symbol __declspec(dllimport) That symbol is provided by unicharutils_s.lib --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: MSVC 8.0 : Unresolved external with granparadiso source
Stefano wrote: building my MFC embed component over granparadiso source with MSVC 8.0, I obtain : error LNK2019: unresolved external symbol public: wchar_t const * __thiscall nsAString::BeginReading(void)const ([EMAIL PROTECTED]@@QBEPB_WXZ) referenced in function public: wchar_t const * __thiscall nsString_external::get(void)const ([EMAIL PROTECTED]@@QBEPB_WXZ) what about ? I don't know what sources you're building MFCEmbed was removed several months ago. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: xulrunner license
krithika wrote: Hi, Can someone tell me the license type of xulrunner1.8.1.3.The license bundled says MPL.But i need to modify some parts of source code for my project. Do you mean the license of the source code, or the license of the binary? The source code license is generally listed at the top of each file. Most of the mozilla code is MPL/LGPL/GPL tri-licensed, but some is licensed under more permissive BSD licenses. I don't think we ever really stated what license the binary was under, but there is no EULA, so you can assume it's under the MPL as well. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: embedding issues
Andrew Gough wrote: I have been attempting on and off for (many) weeks to build integrate the gecko/xul rendering engine into an app I am writing. I have been through all the doc I can find on mozilla.org, looked at all the embedding examples in 'mozilla/embedding/tests/', googled til I nearly dropped, and am, quite frankly, stumped as to how to proceed. I'm hoping someone can help - Building on Linux 2.6.18-gentoo-r6 - Mozilla src checked out of CVS HEAD Apr 14 - Built using .mozconfig with . $topsrcdir/browser/config/mozconfig ac_add_options --enable-debug only - Created embedding dist with cd obj../embedding/config make This is not a recommended embedding configuration. Please build XULRunner and use that for all new embedding. You do not need/should not use embedding/config One issue was no 'nsIBaseWindow.idl' or 'nsIDocShellTreeItem.idl' in 'sdk/idl', so I added it manually, ran xpidl on it and got header files. Indeed, the sdk/ directory contains only frozen interfaces that are guaranteed not to break, and those interfaces are not frozen. App links, loads, and succeeds to initialise, but I get the follwoing errors on stderr: Couldn't convert chrome URL: chrome://global/locale/layout/xmlparser.properties -1233578320[826d070]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file /home/goughy/devel/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 812 This may go away automatically when you embed against XULRunner. If not, I can give you some more suggestions (you may need to tell XPCOM where to look for chrome when you initialize it). --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Link problem
KwangYul Seo wrote: error at first. However, after I included a unfrozen API nsPresContext.h, it in turn included old string APIs and caused linkage errors. What library do I need to include to avoid these link errors? I tried string_s.lib, but it caused duplicate linkage errors. It is not possible to mix internal linkage strings and frozen linkage strings. You might be able to hack the nsPresContext.h header to avoid including the internal string headers, and ifdef out the one method (UpdateCharSet) that uses them, but you're really fighting a losing battle. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: XRE_InitEmbedding vs. NS_InitEmbedding
KwangYul Seo wrote: winEmbed uses XRE_InitEmbedding to initialize the gecko engine while other ports (mfcembed, os2Embed, wxEmbed) use NS_InitEmbedding. What is the difference and which one should I use? XRE_InitEmbedding is the new frozen/supported API. It is exposed via dynamic linkage. NS_InitEmbedding should not be used in any new code. --BDS ___ dev-embedding mailing list [EMAIL PROTECTED] https://lists.mozilla.org/listinfo/dev-embedding
Re: GRE_GetGREPathWithProperties returning wrong arch XULRunner
Grant Gayed wrote: I'm living in a setup where I always have the same home directory regardless of which Linux machine I log onto (it's on a shared network). I don't know how common this is. This causes me a problem when my app invokes GRE_GetGREPathWithProperties while I'm on a 64-bit Linux machine because this call returns the path of a 32-bit XULRunner install in my home directory, which of course fails in the subsequent XPCOMGlueStartup call. This is of course a similar problem to an x86-64 machine where you could launch a 32-bit or 64-bit XR on the same machine. Is there any way to ensure that GRE_GetGREPathWithProperties returns a XULRunner path that is appropriate for the current arch? I couldn't find a property that would help with this. We currently don't put the architecture in the .conf registration file. You *could* make the -register-* flag add that information to the registration file: http://lxr.mozilla.org/mozilla/source/xulrunner/app/nsXULRunnerApp.cpp#212 and then ask for the arch you need here: http://lxr.mozilla.org/mozilla/source/xulrunner/stub/nsXULStub.cpp#268 Patches welcome. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Embedder: XULRunner binary equivalent to Firefox binary?
edburns wrote: On Jan 28, 11:59 pm, Tom Clowers [EMAIL PROTECTED] wrote: Ed, You'll need to use a XULRunner for embedding. The necessary libraries are not available to dynamically link to in a Firefox build. Note however, that Firefox 3.0 will be drinking the Kool-Aid soon as well as it is slated to become a XULRunner application itself. Thank you so much for your prompt reply. It looks like the latest version of XULRunner is 1.8.0.4. Is this correct? That is the latest version we have pushed a developer preview for. Obviously you shouldn't be using it in production since there have been security bugs fixed on the 1.8.0 branch since the release. Since XULRunner is still in developer-preview state, Mozilla is not planning on doing regular updates for it (and in fact, we probably won't be doing any more official preview releases). You are of course welcome to build it yourself. Several Linux distributions (SuSE and others) have updated XULRunner packages which are used as the basis for Epiphany and other Mozilla embedders. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: ActiveX control, firefox browser, and cookies..?
Allen wrote: However it looks like embedded browser control and the full blown browser don't use the same cookie store. Is that the case? I can't seem to get cookies from one to be available to the other, in either direction. Yes, that is the case. Cookies are stored in the profile directory, which can only be accessed by one process at a time. So it is basically impossible to share cookies between firefox and embedded apps at this time, because you run the serious risk of corrupting the cookie store altogether. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Command line handlers for embedding application
Srinivasa Raghavan wrote: Dear All, I have an extension, for which i registered for command-line-handler category. I see in the compreg.dat file, where it has the entry for my extension. I given a print in the Handle(nsICommandLine) method implementation but which doesn't seem to be invoked. My module file include following entry, catman-AddCategoryEntry(command-line-handler,nsQEngineImpl,NS_QENGINE_CONTRACTID,PR_TRUE,PR_TRUE,previous); I presume that you have also registered your component correctly under NS_QENGINE_CONTRACTID, and that it implements and QIs to nsICommandLineHandler? The code you've posted, without additional information, looks correct. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: embedding Gecko with the Gecko SDK
Olivier Danes wrote: re, I've found a solution but don't know if it is the good way... I need to call XPCOMGlueStartup() with the full path to libxpcom.so. It also needs libxul.so (not provided with the SDK !). The SDK is only provided to provide headers and import libraries. You actually do need to have the gecko runtime (XULRunner) installed in order for anything to work. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Views on paying for Mozilla feature development
Erik S. Johansen wrote: So, my question is, is there an accepted procedure for this, is there somewhere I can offer this project without breaking any rules? Would it be frowned upon posting such a request here? You could try, and it's not against any protocol. I'd be surprised if you found any takers here. Most of the people who know the code really well and are available for hire have already been hired. You can also try posting to the mozilla.jobs newsgroup. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Error linking to Firefox libraries
jmv wrote: NS_InitEmbedding is indeed an obsolete API; it has been replaced by the much more flexible and dynamically linked XRE_InitEmbedding API. That said, it is still available in a static library for old code which hasn't upgraded yet. Thanks for your answer but I cannot find a single mention of XRE_InitEmbedding in the Firefox 1.5 sources and NS_InitEmbedding is declaring with NS_HIDDEN attribute. As far as I understand, this means that I cannot link to it. What should I do in this situation? As I may have forgotten to mention, XRE_InitEmbedding is only available in XULRunner. However, it should be declared in the Firefox source tarball in mozilla/toolkit/xre/nsXULAppAPI.h Because NS_InitEmbedding is provided by a statically-linked library, it is properly declared with NS_HIDDEN and as long as you link that library (embed_base_s) you should have access to that API. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Error linking to Firefox libraries
jmv wrote: Hello, I'm trying to revive wxMozilla project, fixed most bugs that prevented compiling, but on linking stage I get messages that linker cannot find 'NS_InitEmbedding', 'NS_TermEmbedding' symbols. You don't say what branch you're trying to build from, which is an essential bit of information. Firefox is compiled from source with default flags (--enable-application=browser). XULRunner is the standard embedding framework that should be used from the 1.8 cycle forwards. Do I need to recompile the browser with other flags to enable embedding? Or are NS_InitEmbedding, etc. calls are deprecated? NS_InitEmbedding is indeed an obsolete API; it has been replaced by the much more flexible and dynamically linked XRE_InitEmbedding API. That said, it is still available in a static library for old code which hasn't upgraded yet. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Extensions in embedded Xulrunner
[EMAIL PROTECTED] wrote: Michal Ceresna писал(а): On Friday 07 July 2006 20:07, [EMAIL PROTECTED] wrote: Hello, I know about the NS_XRE_ENABLE_EXTENSION_MANAGER flag for nsXREAppData, but there seems to be no way to pass it to XRE_InitEmbedded. the extension manager can be either enabled programmatic with setting the field 'flags' in nsXREAppData passed to XRE_main or in application.ini: Both ways seem to be available only in xulrunner-as-application deployment (XRE_main or the xulrunner binary), but not in embedded libxul DLL/DSO initialized with XRE_InitEmbedded. Am I wrong? All 'extension management' does is configure directory service providers with a list of extension directories, and restart the application in certain circumstances. If you are using XRE_InitEmbedding you will need to provide the list of extension directories yourself, and manage restarting for extension installation (obviously xulrunner can't know how to restart your embedded application). See http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsXULAppAPI.h#155 and the extension manager logic at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/xre/nsAppRunner.cpprev=1.138mark=2280-2302#227 --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
