Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On Monday, February 25, 2013 4:27:24 AM UTC+1, Boris Zbarsky wrote: I guess the reason I'm suddenly having this problem is https://bugzilla.mozilla.org/show_bug.cgi?id=809652 Seems pretty unlikely. Yes, I misanalyzed this. It appears that the root cause of the problem was that my content scripts (which run in a sandbox) stopped being able to request chrome:// URLs in FF19. I therefore changed to resource:// URLs. Apparently DOMWindowCreated doesn't fire for a resource:// URL in a browser with type == chrome, so this is indeed not a FF19 change. This led me to use type == content (in retrospect a bad idea) and inject my own XHR implementation. Changing back to chrome:// URLs solves all of this (including eliminating the need to muck with the XHR implementation in the background page) except the original problem of accessing them via XHR in the sandbox. But using the system principal in the sandbox appears to fix this (thanks Brian!). Hopefully I'm all good now with respect to FF19. Thanks for the help. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On Monday, February 25, 2013 4:27:24 AM UTC+1, Boris Zbarsky wrote: The DOM returned by responseXML is associated with the origin the XHR was initialized with. As far as how you set this origin, it used to be that you could do this directly from a component, but now it looks like we always use the principal of the associated window, if any. Unfortunately, we also use that window to determine whether this is a system XHR or not, as far as I can tell... I'm not going to need to deal with this for this rev (hopefully) but very useful info nonetheless. Thanks! Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
How to automatically register a PKCS#11 module into firefox?
Hi, I have a pkcs#11 dll library and want it to register it in the firefox browser using a MSI setup. I checked with 'modutil' tool, but unfortunately, it shows me an unexpected error message even when you create new key/certificate database set. It says certificate/key database is in an old unsupported format!!. I use the 18.0.2 version of firefox, which is a very recent version. Does anybody know another affordable and always reliable method to register this module, or at least, can explain how to cope with 'modutil' utility problem? Is it technically possible to use this tool for very old firefox versions (such as 6.0)? Thanks ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to automatically register a PKCS#11 module into firefox?
Have you considered browser's addmodule js function? https://developer.mozilla.org/en/docs/JavaScript_crypto#Loading_PKCS_.2311_modules On Mon, Feb 25, 2013 at 12:26 PM, m.sal...@gmail.com wrote: Hi, I have a pkcs#11 dll library and want it to register it in the firefox browser using a MSI setup. I checked with 'modutil' tool, but unfortunately, it shows me an unexpected error message even when you create new key/certificate database set. It says certificate/key database is in an old unsupported format!!. I use the 18.0.2 version of firefox, which is a very recent version. Does anybody know another affordable and always reliable method to register this module, or at least, can explain how to cope with 'modutil' utility problem? Is it technically possible to use this tool for very old firefox versions (such as 6.0)? Thanks ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: daily build of xulrunner runtime unstable trunk for mac platform broken
On 02/24/13 06:13 PM, allencb...@gmail.com wrote: The daily build of xulrunner runtime for mac in the unstable trunk (21a and 22a) are broken (only 46 bytes). Any idea what the problem is? Filed https://bugzilla.mozilla.org/show_bug.cgi?id=844785 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
GTest has landed
Hello dev.platform, GTest has landed this weekend on mozilla-central[1]. It should now be ready for developers to start writing test. It will appear on tinderbox once it is build off '--enable-tests'. For more details see the documentation: https://developer.mozilla.org/en-US/docs/GTest [1] https://bugzilla.mozilla.org/show_bug.cgi?id=767231 [2] http://benoitgirard.wordpress.com/2013/02/25/gtest-has-landed-start-writing-your-unit-tests/ Benoit Girard ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTest has landed
On Monday 2013-02-25 10:57 -0500, Benoit Girard wrote: GTest has landed this weekend on mozilla-central[1]. It should now be ready for developers to start writing test. It will appear on tinderbox once it is build off '--enable-tests'. For more details see the documentation: https://developer.mozilla.org/en-US/docs/GTest [1] https://bugzilla.mozilla.org/show_bug.cgi?id=767231 [2] http://benoitgirard.wordpress.com/2013/02/25/gtest-has-landed-start-writing-your-unit-tests/ When tests are run in debug builds, are NS_ASSERTIONs fatal, as they are for |make check| tests? They should be, and the fewer tests you currently have, the easier it is to make them fatal. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTest has landed
It's not and it's a great suggestion. I filed bug 844869. On Mon, Feb 25, 2013 at 11:04 AM, L. David Baron dba...@dbaron.org wrote: On Monday 2013-02-25 10:57 -0500, Benoit Girard wrote: GTest has landed this weekend on mozilla-central[1]. It should now be ready for developers to start writing test. It will appear on tinderbox once it is build off '--enable-tests'. For more details see the documentation: https://developer.mozilla.org/en-US/docs/GTest [1] https://bugzilla.mozilla.org/show_bug.cgi?id=767231 [2] http://benoitgirard.wordpress.com/2013/02/25/gtest-has-landed-start-writing-your-unit-tests/ When tests are run in debug builds, are NS_ASSERTIONs fatal, as they are for |make check| tests? They should be, and the fewer tests you currently have, the easier it is to make them fatal. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
DOM Bindings Meeting - Monday @ 12:30 PM PST
Our (ostensibly) weekly DOM bindings meetings continue on Monday February 25th at 12:30 PM PST. Meeting details: * Monday, February 25, 2012, 12:30 PM PST (9:30 PM CET) * Conference room 7-N, San Francisco office, 7th floor. * Dial-in Info: - Vidyo room: SFO-7N - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 95704 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Loading data into browser with type == chrome
On 2/25/13 12:36 PM, matt...@salsitasoft.com wrote: As discussed in https://groups.google.com/d/topic/mozilla.dev.platform/E4MG_hTv6Zw/discussion, I am not getting the DOMWindowCreated message when I use a browser element with type set to chrome Depending on what you're doing, you could just be seeing the about:blank inner window reused. Ideally I would use my own protocol handler to load the document, but I haven't had any success due to the aforementioned problem with DOMWindowCreated. I tried setting the protocolFlags to URI_DANGEROUS_TO_LOAD but that doesn't help. I'm not clear on why the protocol handler would depend on DOMWindowCreated 2) Barring that, can I change the baseURI of the document when DOMWindowCreated is fired (i.e. before the scripts are loaded)? In that case I would load the document from the chrome:// URL but change the baseURI to use my own protocol. You can set your channel's originalURI to whatever you want (which may not match where the data is loaded from, which is the URI), right? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Loading data into browser with type == chrome
On Monday, February 25, 2013 6:58:44 PM UTC+1, Boris Zbarsky wrote: Depending on what you're doing, you could just be seeing the about:blank inner window reused. Specifically, I need to be able to inject properties into the window before any script is run. When I load with a chrome:// URL, DOMWindowCreated is fired so I can inject my stuff there. When I load from a resource:// URL or via my own protocol, it isn't fired. I tried adding properties to the window before the load (under the hypothesis that the inner window is being reused), but they don't seem to be there after the load. If the window is being reused, do I have any opportunity to inject my own properties? I'm not clear on why the protocol handler would depend on DOMWindowCreated See above. You can set your channel's originalURI to whatever you want (which may not match where the data is loaded from, which is the URI), right? So are you suggesting that I create the chrome:// URI channel myself and load from it after changing the originalURI? I could try that. If I can figure out a way to load using my own protocol handler then the problem goes away since I can make myprotocol://foo/bar point to the same location as chrome://foo/content/bar and the relative paths will resolve properly. Matt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OpenVG Azure backend
AIUI, a key goal of our Layers Refactoring is to significantly reduce the cost of standing up new GFx backends (the first new one being D3Dv11.) As that progresses, I'd like to see detailed documentation about how new backends are added. I think we can get an intern or volunteer to stand up experimental backends and come with the perf numbers to inform our decisions. We've long predicted an increase in the number of low-level GFx driver surfaces we'll need to support, given our Android and FirefoxOS commitments. Let's make use of the infrastructure we're building to ensure that we can scale to support that. Re: OpenVG specifically, I have some info to share that's more appropriate for the next Rendering meeting agenda. -- Jet - Original Message - From: George Wright geo...@mozilla.com To: Andreas Gal g...@mozilla.com Cc: dev-platform@lists.mozilla.org Sent: Monday, February 25, 2013 11:22:40 AM Subject: Re: OpenVG Azure backend On 02/23/2013 04:00 PM, Andreas Gal wrote: OpenVG is a Khronos standard API for GPU accelerated 2D rendering. Its very similar to OpenGL in design. In fact, its an alternative API to OpenGL ES on top of EGL. It looks like that OpenVG is supported on most Android devices and is used there by Flash (or well used to be used). B2G devices have OpenVG support as well. There are also a number of open source implementations of OpenVG that use OpenGL to accelerate 2D operations that might be interesting for the desktop. OpenVG is pretty similar to Cairo and Skia when it comes to the actual operations offered. The biggest drawback of OpenVG is that it doesn't mix well with OpenGL. Its possible to render with OpenVG to a texture and then composite that with OpenGL, but its not possible to do mixed rendering with VG and GL to the same surface. That having said, I still think we should consider adding an OpenVG backend. It would potentially significantly speed up rendering on mobile hardware. OpenVG is quite a bit more seasoned t han Skia/SkiaGL, and explicitly targets mobile, whereas SkiaGL seems to be mostly optimized for the desktop (at least so far). A particular advantage of OpenVG is that it can take advantage of dedicated 2D acceleration hardware (Mali and Adreno both have special 2D hardware OpenVG uses). SkiaGL on the other hand is limited to using GLES to accelerate 2D drawing operations. What do people think. Should we add a OpenVG backed? My (very limited) knowledge about OpenVG is that people in the industry at the vendor level tend to not care about it. I think the reason for this is basically that there aren't any significant users of OpenVG (WebKit used to have a VG backend but it only had one user and has now been disowned). As a result of this indifference from the vendors, my understanding is that there aren't any actual hardware accelerated VG implementations. I think Qualcomm used to have one, but if I remember correctly they didn't really want to keep maintaining it. I think we're about 3 or 4 years too late to the OpenVG party and at this point we'd be trying to resurrect it, rather than use it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OpenVG Azure backend
On Tuesday, February 26, 2013 8:34:39 AM UTC+13, Jet Villegas wrote: AIUI, a key goal of our Layers Refactoring is to significantly reduce the cost of standing up new GFx backends (the first new one being D3Dv11.) As that progresses, I'd like to see detailed documentation about how new backends are added. I think we can get an intern or volunteer to stand up experimental backends and come with the perf numbers to inform our decisions. We've long predicted an increase in the number of low-level GFx driver surfaces we'll need to support, given our Android and FirefoxOS commitments. Let's make use of the infrastructure we're building to ensure that we can scale to support that. This would be an Azure backend, not a layers backend, so is not affected by the refactoring. Implementing Azure backends is pretty nice (that was the point of Azure), but that kind of thing is intrinsically quite a large amount of work. Also, in general, implementing the backend is trivial compared to dealing with the driver bugs that are exposed by it and general support costs. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Loading data into browser with type == chrome
On 2/25/13 1:46 PM, matt...@salsitasoft.com wrote: I tried adding properties to the window before the load (under the hypothesis that the inner window is being reused), but they don't seem to be there after the load. Then the inner window is not being reused. You can set your channel's originalURI to whatever you want (which may not match where the data is loaded from, which is the URI), right? So are you suggesting that I create the chrome:// URI channel myself and load from it after changing the originalURI? Yes, I think so. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OpenVG Azure backend
I see what you mean there, and I don't mean to trivialize the driver details. I think you can get past much of that by reducing the number of devices to support (eg. constrain to one B2G partner device initially,) and reducing the cost to stand up the backend. I don't know how far Cairo got to getting it integrated, but that may be sufficient to test if it has potential for Gecko. Vlad wrote it, so we should ask him. If that looks good, we can see about wiring it up in Azure. I'm all for using the cheapest, hackiest way to find out if these *experiments* can bear fruit, before deciding on committing to full-blown implementations. --Jet - Original Message - From: Nicholas Cameron nick.r.came...@gmail.com To: mozilla dev platform mozilla.dev.platf...@googlegroups.com Cc: dev-platform@lists.mozilla.org, Jet Villegas j...@mozilla.com Sent: Monday, February 25, 2013 11:40:40 AM Subject: Re: OpenVG Azure backend On Tuesday, February 26, 2013 8:34:39 AM UTC+13, Jet Villegas wrote: AIUI, a key goal of our Layers Refactoring is to significantly reduce the cost of standing up new GFx backends (the first new one being D3Dv11.) As that progresses, I'd like to see detailed documentation about how new backends are added. I think we can get an intern or volunteer to stand up experimental backends and come with the perf numbers to inform our decisions. We've long predicted an increase in the number of low-level GFx driver surfaces we'll need to support, given our Android and FirefoxOS commitments. Let's make use of the infrastructure we're building to ensure that we can scale to support that. This would be an Azure backend, not a layers backend, so is not affected by the refactoring. Implementing Azure backends is pretty nice (that was the point of Azure), but that kind of thing is intrinsically quite a large amount of work. Also, in general, implementing the backend is trivial compared to dealing with the driver bugs that are exposed by it and general support costs. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soliciting advice on #650960 (replacement for print progress bars)
https://bugzilla.mozilla.org/show_bug.cgi?id=650960 seeks to replace the existing print progress bars with something that isn't app-modal. Ignore musings in the description and first few comments about getting rid of them entirely and/or waiting for bug 629500. The current thinking is that we need *some* indication that a print job is in progress, because we need to prevent the user from closing the tab or window until the print job has been completely handed off to the OS. However, the way this is implemented now is inconvenient (it's been shoehorned into the nsIWebProgressListener interface, which is not really fit for the purpose, and it involves some really icky [that's a technical term] back-and-forth between C++ and JS) and app-modal anything is Just Wrong. The existing patches in the bug have been vetoed because doorhanger notifications aren't even universally available within Firefox, never mind other applications. I am not aware of any universal alternative, and I know very little about XUL. I *think* that the low-level approach in the bug, of firing special chrome events at the window (plus some docshell goo to do the actual close suppression), is still viable, and I think doorhangers are appropriate for this when they're available. But I would like some help figuring out what a good universal-backstop *receiver* of those chrome events would look like, both in UX terms and implementation-wise. Thanks, zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
Do we actually need the tab, or just the document? If its the latter, can we just keep the document around invisibly? Andreas On Feb 25, 2013, at 10:14 PM, Zack Weinberg za...@panix.com wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=650960 seeks to replace the existing print progress bars with something that isn't app-modal. Ignore musings in the description and first few comments about getting rid of them entirely and/or waiting for bug 629500. The current thinking is that we need *some* indication that a print job is in progress, because we need to prevent the user from closing the tab or window until the print job has been completely handed off to the OS. However, the way this is implemented now is inconvenient (it's been shoehorned into the nsIWebProgressListener interface, which is not really fit for the purpose, and it involves some really icky [that's a technical term] back-and-forth between C++ and JS) and app-modal anything is Just Wrong. The existing patches in the bug have been vetoed because doorhanger notifications aren't even universally available within Firefox, never mind other applications. I am not aware of any universal alternative, and I know very little about XUL. I *think* that the low-level approach in the bug, of firing special chrome events at the window (plus some docshell goo to do the actual close suppression), is still viable, and I think doorhangers are appropriate for this when they're available. But I would like some help figuring out what a good universal-backstop *receiver* of those chrome events would look like, both in UX terms and implementation-wise. Thanks, zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On 2/25/2013 4:14 PM, Zack Weinberg wrote: The current thinking is that we need *some* indication that a print job is in progress, because we need to prevent the user from closing the tab or window until the print job has been completely handed off to the OS. Why? Is the user allowed to interact with the tab contents (potentially modifying the DOM)? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On Mon, Feb 25, 2013 at 1:28 PM, Benjamin Smedberg benja...@smedbergs.uswrote: On 2/25/2013 4:14 PM, Zack Weinberg wrote: The current thinking is that we need *some* indication that a print job is in progress, because we need to prevent the user from closing the tab or window until the print job has been completely handed off to the OS. Why? Is the user allowed to interact with the tab contents (potentially modifying the DOM)? We clone static copies of documents for print preview. We could potentially do the same for normal printing, I'd think. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On 02/25/2013 04:57 PM, Bobby Holley wrote: On Mon, Feb 25, 2013 at 1:28 PM, Benjamin Smedbergbenja...@smedbergs.uswrote: On 2/25/2013 4:14 PM, Zack Weinberg wrote: The current thinking is that we need *some* indication that a print job is in progress, because we need to prevent the user from closing the tab or window until the print job has been completely handed off to the OS. Why? Is the user allowed to interact with the tab contents (potentially modifying the DOM)? We clone static copies of documents for print preview. We could potentially do the same for normal printing, I'd think. The work I've already done on printing is at a rather lower level; I don't claim to understand fully how it works at the document/window/ shell level. But as far as I know, we do already clone a static copy of the document for normal printing. The only deep reason I can think of for keeping the tab around is that under some operating systems, closing the last tab triggers application shutdown, and it would probably violate expectations to delay that with no user-visible indication of why. However, I expect that if I tried to remove all the superficial reasons why we need to keep the tab around, I'd discover that it's a giant mess. Independent of all that, printing long documents can take tens of seconds just to complete the handoff to the OS print queue (I've been testing with the one-page HTML5 spec) and so I do think a user-visible indication of progress is desirable. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please upgrade to at least Mercurial 2.5.1
On 02/21/2013 05:41 AM, Justin Lebar wrote: Can guidance be provided as to where to get such things for commonly-run versions of Linux? It's also easy to install hg using pip or easy_install. You can get either of these tools using your distro's package manager. (easy_install is usually called python-setuptools or something like that.) I think pip is the preferred method these days. The advantage of using pip/easy_install is that you'll always get the latest version of hg. The disadvantage, of course, is that you're using an additional package manager. (and to clarify: since python packages and ubuntu/deb/etc package management is disparate, this has implications wrt the OS package manager in that you won't be able to transparently resolve the python installation as installed for purposes of e.g. packages that depend on mercurial or ubuntu package updates.) (I wish I had time to ensure that the distillation of this thread went to the appropriate MDN pages so that when I delete this email thread and someone asks what they need to do they can find the page, but this is probably just the worry-wort in me and other folks on IRC will jump in.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On 02/26/2013 01:18 AM, Daniel Holbert wrote: On 02/25/2013 01:57 PM, Bobby Holley wrote: We clone static copies of documents for print preview. We could potentially do the same for normal printing, I'd think. I'm almost certain that we already do. (smaug would know for sure) We clone documents for printing and print preview. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On 02/25/2013 11:28 PM, Benjamin Smedberg wrote: On 2/25/2013 4:14 PM, Zack Weinberg wrote: The current thinking is that we need *some* indication that a print job is in progress, because we need to prevent the user from closing the tab or window until the print job has been completely handed off to the OS. Why? IIRC we still use plugins from the original page, in case we're printing pages with plugins. Is the user allowed to interact with the tab contents (potentially modifying the DOM)? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
UA Tests
A few weeks ago in the Tuesday platform call, I said I'd look and see if I could find any tests in the tree that would capture us changing our User Agent string. I looked and reviewed many of the tests that do *something* with the UA string, but I didn't find any that would actually fail if we changed the UA string inadvertently. So I filed this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=845100 I'll work on some tests next, but if you have better ideas of how to do this or want to jump on it, be my guest. Thanks, Clint ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
How to automatically register a PKCS#11 module into firefox?
Hi, I have a pkcs#11 dll library and want it to register it in the firefox browser using a MSI setup. I checked with 'modutil' tool, but unfortunately, it shows me an unexpected error message even when you create new key/certificate database set. It says certificate/key database is in an old unsupported format!!. I use the 18.0.2 version of firefox, which is a very recent version. Does anybody know another affordable and always reliable method to register this module, or at least, can explain how to cope with 'modutil' utility problem? Is it technically possible to use this tool for very old firefox versions (such as 6.0)? Thanks ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
