Re: Terminating xulrunner?
As a XULRunner app developer, as long as firefox -app application.ini continues to work I think I could learn to live with this. On Sunday, January 12, 2014 7:34:54 PM UTC-5, Mike Hommey wrote: > Hi, > > > > Let's face it: xulrunner is hardly maintained, we barely build and test > > it on automation, and the result is that it is often broken for long > > periods of time. > > > > I propose that we just stop pretending, and terminate xulrunner, > > considering the following: > > - Xulrunner is lagging behind Firefox: DLL block list, startup telemetry, > > etc. > > - Since bug 755724, running firefox -app application.ini is 99% the same > > as running xulrunner application.ini, except for a few details that > > should be considered bugs. Before that bug, it was quite different, > > as browser-specific files were available to the xul application. > > - There is no reason we can't generate the sdk from firefox instead of > > xulrunner. Moreover that would make firefox-specific interfaces > > available in the sdk that aren't currently (which may or may not be a > > good thing, arguably) > > - We could include the xulrunner and xulrunner-stub executables as part > > of firefox. xulrunner-stub is small and self-contained, and xulrunner > > could be replaced by something that calls firefox -app. Or we could > > make the firefox executable check under what name it's called and act > > accordingly. > > > > Thoughts? > > > > Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Passing output of DOMParser to sandbox
I want to be able to parse XML and expose the resulting document to a sandboxed
script. I do this by first by determining the principal corresponding to a
given URI:
var secMan = Services.scriptSecurityManager;
var uri = Services.io.newURI("http://www.example.com/";, "UTF-8", null);
var principal = secMan.getCodebasePrincipal(uri);
and then initializing a DOMParser and a sandbox with the resulting principal:
var dp = Components.classes["@mozilla.org/xmlextras/domparser;1"]
.createInstance(Components.interfaces.nsIDOMParser);
dp.init(principal, uri, uri);
var sandbox = new Components.utils.Sandbox(principal);
and finally parsing a document and passing it to a sandboxed function:
var doc = dp.parseFromString('', 'text/xml');
Components.utils.evalInSandbox(
'function fn(doc) { return doc.documentElement.tagName; }',
sandbox);
sandbox.fn(doc);
However, this last line yields:
Exception: Permission denied to access property 'documentElement'
Am I doing something wrong, or is this a bug?
Thanks,
Simon
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: setTimeout without a DOM window using Timer.jsm
Now might be a good time to try to bring up https://bugzilla.mozilla.org/show_bug.cgi?id=776798 again. Anything called from an nsITimerCallback from a JSM runs without the method JIT unless you explicitly set Components.utils.methodjit in the callback or use window.setTimeout on the hidden DOM window instead. This still happens in the latest Nightly. I never heard back whether this was intentional or not, and this may not matter most of the time since often there's not much code running in the nsITimerCallback, but in our extension we got a ~30% speedup on some performance-critical code by setting Components.utils.methodjit back to whatever it was outside of the callback. Simon On Mar 2, 7:47 pm, Matt Brubeck wrote: > I noticed a number of places in Mozilla code where setTimeout-like > functionality is needed, but DOM window.setTimeout is not available > because the code runs in a non-DOM context like a JSM. In a few places > we had created pure-JS implementations of window.setTimeout to solve > this problem. > > With Gavin's encouragement, I extracted one of these into a standalone > JSM file, to make it easier to share. If you need to call setTimeout > without a DOM window, you can now use Timer.jsm: > > https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modu... > > This offers two main benefits over just using nsITimer directly: it > makes it easier to re-use code written for use in a DOM window, and it > addresses this common nsITimer garbage collection > problem:http://www.joshmatthews.net/blog/2011/03/nsitimer-anti-pattern/ > > For more details, see bug 840360. Thank you to Chris Jones who wrote > the original code, and to several other people who gave feedback on it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Cycle collection for workers
On Feb 13, 5:25 pm, Benjamin Smedberg wrote: > On 2/13/2013 4:28 PM, Kyle Huey wrote: > > > > > > > > > On Wed, Feb 13, 2013 at 9:20 PM, Benjamin Smedberg > > wrote: > > >> On 2/13/2013 1:39 PM, Kyle Huey wrote: > > >>> On Wed, Feb 13, 2013 at 6:35 PM, Brian Smith wrote: > > >>> At what point during XPCOM shutdown are workers destroyed? > xpcom-shutdown-threads > >> What workers are these? Do workers outlast the page that loaded them? The > >> entire DOM should be torn down at or before we shut down the profile. > >> There's really no way workers should outlive that point either. > > > Web workers for a given window begin to shut down when > > nsGlobalWindow::FreeInnerObjects is called. When exiting that's going to > > get called from nsDocShell::Destroy, presumably when the is > > torn down. Since workers are on another thread the shutdown process is > > asynchronous. Nothing guarantees that they are shutdown before proceeding > > further until we block on them being shutdown during xpcom-shutdown-threads. > > Yes, but the immediately are unable to send messages back, right? So > what could they *do* that would affect anything else? > > --BDS Don't workers have access to XMLHttpRequest? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Xulrunner 16 to 17? (Erro compiling)
On Dec 3, 5:41 am, Felipe Junges wrote: > Em quinta-feira, 29 de novembro de 2012 14h48min56s UTC-3, Jeff Hammel > escreveu: > > > > > > > > > > > Wild guess in the dark here, and assuming `py` == "the python > > > executable", it looks like you're using python 3.x (again wild guess) > > > whereas in python 2.x "print > > > getBuiltinOrNativeTypeName(self.params[0].realtype)" is valid syntax. > > > Again, its hard to guess from the limited information here. > > > Jeff > > > On 11/29/2012 05:41 AM, Felipe Junges wrote: > > > > No, we has using the old .bat with xpidl.exe > > > > It was working until 16. > > > > Is there some change in 17 that needs to use .py? > > > > Anyway... > > > > We have installed python, and running: > > > > py D:\xpcom_info\xulrunner\sdk\bin\header.py --cachedir=D:\ -o > > > D:\xpcom_info\Informatize\comp.h D:\xpcom_info\Informatize\comp.idl > > > > Is giving us this error: > > > > print getBuiltinOrNativeTypeName(self.params[0].realtype) > > > > SyntaxError: invalid syntax > > > > A ^ in the last "e" from getBuiltinOrNativeTypeName > > > > :( > > > > When we tryed to update to 17 and start having those errors, we started > > > thinking that maybe we were doing something wrong from the beggining > > > (like use the EXE), but all tuto's on internet are not updated... > > > > Is there some tutorial that shows the correct way to create a extension, > > > updated to version 17? > > > > Thanks a lot! > > > > Em quarta-feira, 28 de novembro de 2012 20h53min59s UTC-3, Simon > > > Kornblith escreveu: > > > >> Did you rebuild your automatically generated C++ headers using the > > > >> version of pyxpidl shipped with XULRunner 17? Details at > > > >>https://developer.mozilla.org/en-US/docs/XPIDL/pyxpidl > > > >> On Nov 28, 1:48 pm, Felipe Junges wrote: > > > >>> Hi! First, sorry about my poor english =P > > > >>> I'm brazilian... so... I'll give my best =P > > > >>> Where I work, we have a Firefox add-on, what was working perfect until > > >>> xulrunner 16, compiling in Visual Studio 2010. > > > >>> Now, we have updated it to xulrunner 17 and we are getting lots and > > >>> lots of erros, when trying to compile. > > > >>> Like: > > > >>> Code: > > > >>> d:\xpcom_info\informatize\comp.h(25): error C2470: 'ISpecialThing' > > >>> : looks like a function definition, but there is no parameter list; > > >>> skipping apparent body > > > >>> 1>d:\xpcom_info\informatize\comp.h(38): error C2653: > > >>> 'ISpecialThing' : is not a class or namespace name > > > >>> 1>d:\xpcom_info\informatize\comp.h(38): error C2143: syntax error > > >>> : missing ';' before '<' > > > >>> 1>d:\xpcom_info\informatize\comp.h(38): error C2988: > > >>> unrecognizable template declaration/definition > > > >>> 1>d:\xpcom_info\informatize\comp.h(38): error C2059: syntax error > > >>> : '<' > > > >>> >d:\xpcom_info\informatize\comp.h(38): error C2039: 'kIID' : is > > >>> not a member of '`global namespace'' > > > >>> 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(51): error > > >>> C2989: 'nsAString' : class template has already been declared as a > > >>> non-class template > > > >>> 1> d:\xpcom_info\xulrunner\include\nsrootidl.h(18) : see > > >>> declaration of 'nsAString' > > > >>> 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(52): error > > >>> C2989: 'nsACString' : class template has already been declared as a > > >>> non-class template > > > >>> 1> d:\xpcom_info\xulrunner\include\nsrootidl.h(19) : see > > >>> declaration of 'nsACString' > > > >>> 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(160): error > > >>> C2332: 'enum' : missing tag name > > > >>> d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(160): error > > >>> C2989: '' : class templa
Re: Xulrunner 16 to 17? (Erro compiling)
Did you rebuild your automatically generated C++ headers using the version of pyxpidl shipped with XULRunner 17? Details at https://developer.mozilla.org/en-US/docs/XPIDL/pyxpidl On Nov 28, 1:48 pm, Felipe Junges wrote: > Hi! First, sorry about my poor english =P > I'm brazilian... so... I'll give my best =P > > Where I work, we have a Firefox add-on, what was working perfect until > xulrunner 16, compiling in Visual Studio 2010. > > Now, we have updated it to xulrunner 17 and we are getting lots and lots of > erros, when trying to compile. > Like: > > Code: > d:\xpcom_info\informatize\comp.h(25): error C2470: 'ISpecialThing' : > looks like a function definition, but there is no parameter list; skipping > apparent body > 1>d:\xpcom_info\informatize\comp.h(38): error C2653: 'ISpecialThing' : is > not a class or namespace name > 1>d:\xpcom_info\informatize\comp.h(38): error C2143: syntax error : > missing ';' before '<' > 1>d:\xpcom_info\informatize\comp.h(38): error C2988: unrecognizable > template declaration/definition > 1>d:\xpcom_info\informatize\comp.h(38): error C2059: syntax error : '<' > >d:\xpcom_info\informatize\comp.h(38): error C2039: 'kIID' : is not a > member of '`global namespace'' > 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(51): error C2989: > 'nsAString' : class template has already been declared as a non-class template > 1> d:\xpcom_info\xulrunner\include\nsrootidl.h(18) : see > declaration of 'nsAString' > 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(52): error C2989: > 'nsACString' : class template has already been declared as a non-class > template > 1> d:\xpcom_info\xulrunner\include\nsrootidl.h(19) : see > declaration of 'nsACString' > 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(160): error C2332: > 'enum' : missing tag name > d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(160): error C2989: > '' : class template has already been declared as a non-class > template > 1> d:\xpcom_info\xulrunner\include\nsXPCOM.h(252) : see > declaration of '' > 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(367): error C3861: > 'NS_StringSetDataRange': identifier not found > 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(392): error C3861: > 'NS_StringSetDataRange': identifier not found > 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(409): error C3861: > 'NS_StringSetDataRange': identifier not found > 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(465): error C2332: > 'enum' : missing tag name > 1>d:\xpcom_info\xulrunner\include\nsXPCOMStrings.h(465): error C2989: > '' : class template has already been declared as a non-class > template > > And some more! > > We have made no changes in our code, when did the update. > We have noticed that various errors are been reported in nsXPCOMStrings.h, > the others are pointed in our code (that works perfect with xulrunner 16). > > It look like we have to put some "include" somewhere... Can anobody help us > finding what did changed from 16 to 17, what does the programmers has to > change? > Our code is not much different from the XPCOM example: > > https://developer.mozilla.org/samples/x... m-test.zip > That was explained here:https://developer.mozilla.org/en-US/doc... ual_Studio > > Ah! We have downloaded the example from this site and even we, gives the same > erros in xulrunner 17. > > Thanks a lot!!! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XULRunner on OS X, Why is not supported?
On Nov 8, 3:46 pm, richardson.balca...@gmail.com wrote: > I was just reading the effort of installing "open web apps" locally, I'm > assuming the strategy shift that I'm talking about is that Mozilla is betting > on Firefox as their application framework, that would make sense not to > support Xulrunner anymore. > > I would like to see how could one use the native stuff like platform specific > stuff (Cocoa for example) on this "open web apps". Don't get me wrong I love > Web technologies but an HTML TAB is never going to feel the same as the OS > Native TAB. If by TAB you mean the UI element (and not the soft drink, or something else), then I think it's worth pointing out that, on OS X, the tabs in your Firefox window aren't native. They are XUL stylized to look like native tabs (CSS at https://mxr.mozilla.org/mozilla-central/source/browser/themes/pinstripe/browser.css#2113). There's nothing preventing you from stylizing HTML the same way. Simon ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: quick! use lisp! before it's too late!
On Aug 29, 2:17 am, Pedro Bessa wrote: > Design patterns solve a problem, but the problem shouldn't have existed in > the first place. Prototypal OO doesn't have the problems that traditional > OO has. Lua is fast, prototypal, has C interop and was used to create World > of Warcraft, the most financially successful game in history. How about > using Lua without inheritance and visibility, just prototypal OO? How about JavaScript, which is paradigmatically similar to Lua but with the distinct advantage that many components of Firefox are already written in it? :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Object prototypes and the content/chrome barrier
Have you tried:
foo.__exposedProps__ = {"prototype":"r"};
(If this is indeed the issue, you should probably set __exposedProps__
for the prototype as well. Newer Firefox versions warn about missing
__exposedProps__ on objects, although I think it's only required for
functions ATM.)
Simon
On Aug 7, 9:51 am, Matthew Gertner wrote:
> I am using the content-document-global-created observer topic to add a
> function to content windows when they are created. The function is used to
> load a subscript like this:
>
> var foo = window.loadSubscript("spec"); // loadSubscript() uses the subscript
> loader internally
>
> So the subscript should run with chrome privileges (loadSubscript is a
> function defined in chrome). If foo is a function then I can call it from
> content. However, if foo is an object constructor, it's prototype doesn't get
> through to the content page. In other words, imagine that loadSubscript looks
> like this:
>
> function loadSubscript(spec) {
> var context = {};
> var scriptLoader = Cc["@mozilla.org/moz/jssubscript-loader;1"].
> getService(Ci.mozIJSSubScriptLoader);
> scriptLoader.loadSubScript(spec);
> return context;
>
> }
>
> And the subscript is something like:
>
> function foo() {
>
> }
>
> foo.prototype = {
> do_something: function() { return "Hello, world!"; }
>
> };
>
> I would expect to see foo.prototype in the content page script at the
> beginning of this message, but instead I see "undefined". I guess this is a
> security issue but no warnings or errors are displayed when I test in a
> Firefox debug build. Does anyone know what gives?
>
> Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
