Re: How to access(calling) external addon's javascript functions in XUL applicataion.
On 8/1/14 7:45 AM, Yonggang Luo wrote: I am installed Tiny Javascript Debugger into my own XUL application, (by setting the ID to thunderbird), How to start the Tiny Javascript Debugger by calling it's own functions? You should take a look at this extension, it should do everything you need: https://addons.mozilla.org/en-US/firefox/addon/remote-developer-tools-server/ Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Continued support for ESR
Can we at least adjust the ESR release length so that they fall on even numbered Geckos? Then they'll never end up on a version that is not shared with a b2g branch. - Kyle On Thu, Jul 31, 2014 at 10:18 PM, Lukas Blakk lsbl...@mozilla.com wrote: Hello, When the ESR branch was initially created it was done so in a manner of intentional impermanence, the thinking being that consumers of this channel would eventually establish a way to switch over onto our 6 week rapid release mainline builds. With last week’s ESR31 we are pushing the limits of the original timeframe and it’s time to make a call on how to proceed with this population of users with an intent of creating permanence. In its present state, a strong community has built up around this channel and pacing of major version bumps. The enterprise mailing list is active but not high-volume. There are two community contributors who took on the work of administrating the mailing list and they provide support as well on how to customize deployments. Since this branch/channel was created with the intention of killing it off down the road, we do not do any external marketing of the ESR. The user base can be generally distributed into three buckets: large organizations with over 100K instances, 2-10K organizations, and then ones under 1K. There are over 5500 members on the mailing list, and in order to get details about use a query was sent to the list in order to collect information on the value of continue providing this channel. About 80 responses were received in 2 weeks. Given: * we have a strong, self-supporting community * building and maintaining ESR has become a smooth process which uses very few resources (one channel, minimal builds on checkins, single QA sign off every 6 weeks) * Chrome is now providing enterprise support (http://www.google.com/intl/en/chrome/business/browser/) * there are at least 2M users on this channel and we estimate there to be more if we factor in Linux distributions The approach going forward is to: * continue providing ESR builds as a permanent channel dedicated to the criteria we laid out in its creation * plan a marketing push around the existence of ESR (update docs, revamp the org web page, promote the channel externally) * commit to iterating on the processes built around of this channel and explore potential improvements to pacing, packaging, and other customizations * make a project of getting FHR/Telemetry data from these deployments where permitted so that we have information on long-term usage that could be missing from mainline For that last point, many of the respondents to the questions I raised on the list said they already could do, or would look into doing, Telemetry/FHR reports if they had more visibility into what the data collected was and also some expressed interest in having access to that collected data. Data from long term support build users might unlock stability and security information that we do not currently discover in our rapid releases. There is value to this channel both in loyalty of users, reaching people at work where they likely spend more of their online time, and maintaining a share of desktop browser usage. Let’s take this already strong community, and look at how we can grow it for the benefit of the users and our products. Cheers, Lukas ___ dev-planning mailing list dev-plann...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-planning ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: TOOL_DIRS, TEST_TOOL_DIRS and PARALLEL_DIRS are no more
On Thu, Jul 31, 2014 at 04:49:21PM +0100, Neil wrote: Mike Hommey wrote: - TOOL_DIRS Does that mean that the tools tier is no more? How do you get something done after jar.mn processing? It's almost no more. If you have a tools rule in a Makefile, it's still going to be run as part of the slim tools tier. browser/app/Makefile.in has such a rule, for instance. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Introducing mozilla::UniquePtr and mozilla::MakeUnique for |new T| and |new T[]| resources
Jeff Walden wrote: Additionally, UniquePtr is best used by threading it through interfaces, beyond just immediate use sites. Rather than returning a raw pointer, code should return UniquePtr instead. Rather than extracting a raw pointer to pass to a method, code should pass Move(ptr) instead, and that argument should be a UniquePtr. Only UniquePtr's own copy and assignment operators should take UniquePtr. Other call sites should either take const UniquePtr (if they will not take ownership of the pointer), UniquePtr (if they may or may not need to take ownership of the pointer) or UniquePtr (if they will take ownership of the pointer). -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Continued support for ESR
On 01/08/2014 07:18, Lukas Blakk wrote: Hello, When the ESR branch was initially created it was done so in a manner of intentional impermanence, the thinking being that consumers of this channel would eventually establish a way to switch over onto our 6 week rapid release mainline builds. With last week’s ESR31 we are pushing the limits of the original timeframe and it’s time to make a call on how to proceed with this population of users with an intent of creating permanence. In its present state, a strong community has built up around this channel and pacing of major version bumps. The enterprise mailing list is active but not high-volume. There are two community contributors who took on the work of administrating the mailing list and they provide support as well on how to customize deployments. Since this branch/channel was created with the intention of killing it off down the road, we do not do any external marketing of the ESR. The user base can be generally distributed into three buckets: large organizations with over 100K instances, 2-10K organizations, and then ones under 1K. There are over 5500 members on the mailing list, and in order to get details about use a query was sent to the list in order to collect information on the value of continue providing this channel. About 80 responses were received in 2 weeks. Given: * we have a strong, self-supporting community * building and maintaining ESR has become a smooth process which uses very few resources (one channel, minimal builds on checkins, single QA sign off every 6 weeks) * Chrome is now providing enterprise support (http://www.google.com/intl/en/chrome/business/browser/) * there are at least 2M users on this channel and we estimate there to be more if we factor in Linux distributions You also forgot to mention that Thunderbird releases were based on ESR that's a bunch more users. Ludo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: I want to implement a ListBox that contains one million(1,000,000) custom vbox, how to speed it up.
Yonggang Luo wrote: The vbox's content comes from a large database. Is there any standard way to implement it A xul listbox? You probably want to use a treeview. It's designed for such use cases. https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Custom_Tree_Views -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement/ship: Support for msApplication-TileImage/Color
Summary: In Firefox 33 we shipped support for msApplication-TileImage/Color meta tags in pages. These are meant to be shown on our homescreen in place of thumbnails when they are available. See http://digdug2k.wordpress.com/2014/07/30/better-tiles-in-fennec/ for a screenshot. These allow the site to provide images/background colors for tiles in our homescreen, hopefully resulting in a better user experience for users than the thumbnails (or favicons if the site has Cache-Control headers set) that we currently show. Bug: bug 1014712 - https://bugzilla.mozilla.org/show_bug.cgi?id=1014712 Link to standard: There is no public standard in place for these meta-tags and none in progress either. Microsoft's implementation blog post is here http://blogs.msdn.com/b/ie/archive/2012/06/08/high-quality-visuals-for-pinned-sites-in-windows-8.aspx. AFAIK, these aren't supported on any other platforms/browsers. Opera at one point supported the view-mode media query (https://bugzilla.mozilla.org/show_bug.cgi?id=678173) for generating these types of thumbnails (http://www.w3.org/TR/view-mode/#dfn-minimized). Not sure if that carried over when they moved to blink. Implementing support for view-mode is bug 678173. Platform coverage: This is Android only. Estimated or target release: 33 Preference behind which this will be implemented: There is no pref for this feature. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mac OS X 10.7 SDK or later now required for Mac builds
On 2014-07-31 11:42 AM, Bob Clary wrote: Actually I had been building on 10.6 up until this morning. I've switched my builders to 10.9 where it appears all is well and I am able to run the builds on 10.6+. Just out of curiousity, are you building against the 10.7 sdk on 10.9, or against the native libraries, and having it work on 10.6+? Would be nice to know if 10.9 builds still work on 10.6. -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Fwd: David Keeler is now the module owner of PSM
-- Forwarded message -- From: Brian Smith br...@briansmith.org Date: Fri, Aug 1, 2014 at 9:24 AM Subject: David Keeler is now the module owner of PSM To: mozilla-governa...@lists.mozilla.org, mozilla's crypto code discussion list dev-tech-cry...@lists.mozilla.org, David Keeler dkee...@mozilla.com Hi, Amogst other things, PSM is the part of Gecko (Firefox) that connects Gecko to NSS and other crypto bits. David Keeler has taken on most of the responsibility for keeping things in PSM running smoothly and so it makes sense to have him be the module owner. After asking the other PSM module peers, I went ahead and made that change: https://wiki.mozilla.org/Modules/Core#Security_-_Mozilla_PSM_Glue Congratulations David! Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mac OS X 10.7 SDK or later now required for Mac builds
On 08/01/2014 09:27 AM, Ralph Giles wrote: On 2014-07-31 11:42 AM, Bob Clary wrote: Actually I had been building on 10.6 up until this morning. I've switched my builders to 10.9 where it appears all is well and I am able to run the builds on 10.6+. Just out of curiousity, are you building against the 10.7 sdk on 10.9, or against the native libraries, and having it work on 10.6+? Would be nice to know if 10.9 builds still work on 10.6. I didn't specify --with-macos-sdk when building on 10.6 previously nor when building on 10.9, so native libraries? Xcode 5.0.2 is installed on the 10.9 machine with the 10.8 and 10.9 sdks, but I didn't specifically select either. These builds do run on 10.6. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: I want to implement a ListBox that contains one million(1, 000, 000) custom vbox, how to speed it up.
Paul Rouget wrote: Yonggang Luo wrote: The vbox's content comes from a large database. Is there any standard way to implement it A xul listbox? You probably want to use a treeview. It's designed for such use cases. Doesn't help if he needs a custom vbox. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Promise syntax in .webidl files now requires the resolution type
As of today, any Web IDL using Promise needs to specify the type the promise will be resolved with. For example, an API that used to be written like this: Promise getLength(); would now be written like this: Promiseunsigned long getLength(); If you don't put in the type, you will get invalid syntax errors from the Web IDL parser. If you have no idea what you'll resolve the Promise with, use Promiseany as a last resort: it bypasses some sanity-checking codegen can otherwise do on Promise-returning functions. If you plan to resolve with undefined, use Promisevoid. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mac OS X 10.7 SDK or later now required for Mac builds
On 2014-08-01 9:47 AM, Bob Clary wrote: I didn't specify --with-macos-sdk when building on 10.6 previously nor when building on 10.9, so native libraries? I *think* the default isysroot is '/' so not passing --with-macos-sdk would build against the system's native libraries, headers and frameworks. Xcode 5.0.2 is installed on the 10.9 machine with the 10.8 and 10.9 sdks, but I didn't specifically select either. These builds do run on 10.6. Great, thanks for confirming! -r ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: Element.matches
Summary: This is an unprefixed form of Element.mozMatchesSelector, which we've been shipping for a long time. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=886308 Link to standard: http://dom.spec.whatwg.org/#dom-element-matches (though note http://lists.w3.org/Archives/Public/www-dom/2014JulSep./0062.html, which is more internal standard bookkeeping than issues about how the method _should_ behave). Platform coverage: All platforms. Estimated or target release: Firefox 34. Preference behind which this will be implemented: Just going to ship this. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Introducing mozilla::UniquePtr and mozilla::MakeUnique for |new T| and |new T[]| resources
On 08/01/2014 03:48 AM, Neil wrote: Only UniquePtr's own copy and assignment operators should take UniquePtr. Other call sites should either take const UniquePtr (if they will not take ownership of the pointer), UniquePtr (if they may or may not need to take ownership of the pointer) or UniquePtr (if they will take ownership of the pointer). Oops, you're largely right. There are perhaps rare cases where it might make sense to accept UniquePtr, but it's pretty uncommon. I somewhat meant to elaborate on this in the blog post, then forgot. Probably I won't bother at this point. But, largely what I would have said is encapsulated in this Stack Overflow question/answer: http://stackoverflow.com/questions/8114276/how-do-i-pass-a-unique-ptr-argument-to-a-constructor-or-a-function This discussion is much less intricate and technical than the rvalue reference series I linked in the post as subtle, so it's worth a read if you're interested and won't take up that much time to digest. At the same time, it's largely an expansion of what NeilAway said, so feel free not to read it if you read his post. :-) Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
