Re: One Firefox repository to rule them all

On 04/15/2016 11:29 PM, Gregory Szorc wrote: On Thu, Apr 14, 2016 at 6:45 PM, Dave Townsend wrote: On Thu, Apr 14, 2016 at 5:22 PM, Gregory Szorc wrote: I'm pleased to announce the immediate availability of some *experimental* read-only Mercurial repositories containing the combined, useful

Intent to ship: Document.scrollingElement

Hi, I'm planning to enable Document.scrollingElement in release builds (FF48) https://bugzilla.mozilla.org/show_bug.cgi?id=1265032 Implementation bug https://bugzilla.mozilla.org/show_bug.cgi?id=1153322: Document.scrollingElement is designed to be a trivial API to hide inconsistencies in browse

Re: Intent to ship: Element.animate

On 04/18/2016 05:12 AM, Brian Birtles wrote: In Firefox 48 I intend to turn Element.animate on by default. We have been developing the Web Animations API behind the dom.animations-api.core.enabled preference and have introduced the dom.animations-api.element-api.enabled preference for the subse

Re: Intent to ship: ParentNode.prepend(), ParentNode.append(), ChildNode.before(), ChildNode.after(), ChildNode.replaceWith()

OK from me. Need to still carefully look for any possible regressions. -Olli On 04/18/2016 08:11 PM, Jocelyn Liu wrote: As of Firefox 48 I intend to ship ParentNode.prepend(), ParentNode.append(), ChildNode.before(), ChildNode.after(), and ChildNode.replaceWith() on all platforms. These met

Re: Intent to ship: Element.animate

On 04/19/2016 03:29 AM, bbirt...@mozilla.com wrote: On Tuesday, 19 April 2016 02:23:54 UTC+9, smaug wrote: On 04/18/2016 05:12 AM, Brian Birtles wrote: In Firefox 48 I intend to turn Element.animate on by default. We have been developing the Web Animations API behind the dom.animations

Re: Intent to ship: Element.animate

On 04/19/2016 04:03 PM, smaug wrote: On 04/19/2016 03:29 AM, bbirt...@mozilla.com wrote: On Tuesday, 19 April 2016 02:23:54 UTC+9, smaug wrote: On 04/18/2016 05:12 AM, Brian Birtles wrote: In Firefox 48 I intend to turn Element.animate on by default. We have been developing the Web

Clarifications needed to 'Intent to ship' process

Hi all, based on couple of conversations we need some clarifications to 'intent to ship'. First, we aren't yet consistent enough to send 'intent to ship' emails. I think that takes just some time for patch authors and reviewers to get used to the process, that whenever there is some larger t

Re: Clarifications needed to 'Intent to ship' process

On 04/26/2016 10:31 AM, Ehsan Akhgari wrote: On 2016-04-25 10:58 PM, Boris Zbarsky wrote: That said, note that a bunch of the items above lie somewhat out of a specific module, so it's not clear to me that we want intent-to-ship OKs to be module-specific. Yeah, a bunch of stuff definitely cros

Re: Clarifications needed to 'Intent to ship' process

On 04/26/2016 01:47 PM, Ehsan Akhgari wrote: On 2016-04-26 1:02 PM, Mike Hommey wrote: On Mon, Apr 25, 2016 at 10:52:02PM -0400, Boris Zbarsky wrote: On 4/25/16 10:34 PM, Mike Hommey wrote: Don't we already have that with superreviewers? Kinda, sorta. (How outdated is that list, btw?) Qu

Re: Static analysis for "use-after-move"?

On 04/28/2016 08:00 AM, Gerald Squelart wrote: Because sometimes the function will choose not to actually move from an rvalue-ref FWIW, this is the reason why I think Move is broken by definition. Move doesn't move anything. It should have been designed differently, so that a temporary objec

Re: Can we remove nsIEntityConverter?

On 04/30/2016 06:25 PM, Henri Sivonen wrote: We ship data tables for converting from Unicode to HTML entities. These tables obviously take space. (They are not optimized for space usage, either.) As far as I can tell, these tables are not used at all in Fennec. In desktop Firefox, these data tabl

Re: Intent to implement and ship: DOMTokenList.prototype.supports

Ok to me, given that adding the API to the platform is supported by other browser vendors too. (Though it is a bit mystery to me why DOMTokenList.supports is considered fine when it is pretty much similar feature to Node.isSupported and that one was considered harmful to the platform. But I'm

Re: Intent to unship: HTML microdata API

On 05/19/2016 08:55 PM, Boris Zbarsky wrote: Summary: The HTML Microdata API was removed from the spec due to lack of implementor interest. See . Our implementation of it breaks some pages (due to the itemId attributes it adds) and is a bu

Re: Redesigning the docshell/loadgroup/document interaction

On 05/20/2016 05:56 PM, Boris Zbarsky wrote: Background: We have a problem right now where the thing representing a "collection of loads" (a loadgroup) is attached to a docshell, not an individual document. This causes issues like loads started from unload events being blamed on the new page a

Re: Intent to implement and ship: spec changes to the .form property and "form" attribute on elements

On 05/23/2016 10:17 PM, Boris Zbarsky wrote: Summary: The "form" content attribute on elements no longer means anything. .form returns the .form of the labeled control, or null if nothing is labeled or the labeled thing has no .form. In particular, you can no longer associate a label with on

Re: Intent to enable scrollbars by default for windows opened by window.open()

On 05/23/2016 09:55 AM, Anne van Kesteren wrote: On Mon, May 23, 2016 at 8:25 AM, Ben Tian wrote: Chrome and Safari don't provide a way to disable scrollbar, according to https://bugzilla.mozilla.org/show_bug.cgi?id=1257887#c0 If you have any concern or know of regression on pages relying on

Re: How to name our JSContext getter(s): let the bikeshed begin

On 05/30/2016 05:46 AM, Boris Zbarsky wrote: On 5/29/16 6:21 PM, Boris Zbarsky wrote: I wanted to make it clear that we're getting something that's OK to use without synchronization, but maybe that's redundant and we can just have a dom::GetJSContext() or something. dom::JSContext() would have

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

On 06/03/2016 06:41 PM, Boris Zbarsky wrote: Summary: The current IDL spec says that Object.prototype.toString() on a DOM prototype object for interface Foo is "[object FooPrototype]", whereas for instances of the interface it's "[object Foo]", and that's what we implement. However, as we try

Re: Changes under /storage

On 06/06/2016 02:25 PM, Jan Varga wrote: I landed a fix for bug 1195930 ( Use origin in QuotaManager) today, it's now on m-c. We had to do backwards-incompatible changes under /storage directory, so once a profile is used with newest nigthly, then any storage API controlled by Quota Manager (I

Re: Changes under /storage

On 06/06/2016 09:24 PM, Jan Varga wrote: On 06/06/16 17:30, smaug wrote: On 06/06/2016 02:25 PM, Jan Varga wrote: I landed a fix for bug 1195930 ( Use origin in QuotaManager) today, it's now on m-c. We had to do backwards-incompatible changes under /storage directory, so once a profi

Re: Searchfox (new code search tool)

On 06/07/2016 10:37 AM, Gabor Krizsanits wrote: Wow, this is amazing. Million thanks for this, especially for the speed, the easy blame walk and the highlight. I always wanted to have a tool for the traversing history like that. Indeed. So much better than what dxr/mxr gives, and finally I migh

Re: Questions about bindings for L20n

On 06/10/2016 12:49 PM, Gijs Kruitbosch wrote: On 10/06/2016 09:51, zbranie...@mozilla.com wrote: While working on the new localization API (See Intent to Implement post from yesterday), we're developing bindings into UI languages used by Firefox and we have some decisions to make that could be

Re: Return-value-optimization when return type is RefPtr

On 05/24/2016 08:33 AM, jww...@mozilla.com wrote: For RefPtr GetFoo() { RefPtr foo; // ... } should we: 1. return foo and expect RVO to kick in to eliminate additional AddRef/Release 2. return foo.forget() 3. return Move(foo) Which one is preferred? ps: I find gcc is able to apply RVO

Re: Return-value-optimization when return type is RefPtr

On 06/16/2016 06:40 PM, smaug wrote: On 05/24/2016 08:33 AM, jww...@mozilla.com wrote: For RefPtr GetFoo() { RefPtr foo; // ... } should we: 1. return foo and expect RVO to kick in to eliminate additional AddRef/Release 2. return foo.forget() 3. return Move(foo) Which one is preferred

Re: Return-value-optimization when return type is RefPtr

On 06/17/2016 04:01 PM, Gerald Squelart wrote: On Friday, June 17, 2016 at 3:57:01 PM UTC+1, Gerald Squelart wrote: On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote: On 06/16/2016 06:40 PM, smaug wrote: On 05/24/2016 08:33 AM, jw...@mozilla.com wrote: For RefPtr GetFoo

Re: MXR permanently offline, please transition to DXR

On 06/23/2016 03:49 PM, Ms2ger wrote: On 22/06/16 20:30, Lawrence Mandel wrote: Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), was taken offline on June 13, 2016, to investigate a potential security issue. After careful review of the codebase, we have decided to accelera

Re: Gecko shutdown (London session)

On 06/30/2016 11:49 AM, Nicolas Silva wrote: Hi dev-platform, We had a session about shutdown problems during the London workweek. I did a writeup of what was discussed and as it grew into a large-ish piece, I put it in a wiki page (instead of the email I intended to send initially) [1]. There's

Re: KeyboardEvent question for docs update

On 07/12/2016 07:24 AM, Eric Shepherd wrote: Currently, our docs for KeyboardEvent.key and KeyboardEvent.code try to provide direct maps of each major OS's keycodes to the values that result from pressing them. This makes for lots of tables with a lot of repetitive information. I'm looking to si

Re: Intent to Implement and Ship: AddEventListenerOptions.once

+1 For Devtools nsIEventListenerInfo need to be updated. On 07/20/2016 03:53 PM, Xidorn Quan wrote: Summary: "once" is a new option for EventTarget.addEventListener (as a member of AddEventListenerOptions dictionary), which means that the added listener should only be invoked once. It is

Intent to ship fileinput.webkitdirectory and Blink's Entries API

Hi all, the implementation of and Entries API[1] (dragEvent.dataTransfer.items[].webkitGetAsEntry()) is close to be ready. Just couple of patches to land, I hope. Dnd directories to Google Drive works etc. The original idea was to ship so called Upload proposal, but MS decided to implement we

Re: Intent to implement and ship: Iterable declarations on NodeList and DOMTokenList

+1 On 07/30/2016 05:41 AM, Boris Zbarsky wrote: Summary: The idea is to have keys/entries/values/forEach methods on these two interfaces, so you can do things like: document.querySelectorAll("whatever").forEach(someFunc) and document.body.classList.forEach(someFunc) Bug: https://bugz

Re: Intent to ship: minlength attribute and tooShort validityState.

looks good -Olli (and we should still figure out some more formal process how to react to Intent-to emails. Though, at least the .webidl changes will get a DOM peer review) On 08/19/2016 05:21 PM, Thomas Wisniewski wrote: Summary: We already ship the HTML maxlength attribute with its ass

Re: Intent to unship: WorkerGlobalScope.onclose

On 08/22/2016 02:27 PM, Ms2ger wrote: On 22/08/16 10:03, Andrea Marchesini wrote: I'm planning to remove |partial interface WorkerGlobalScope { attribute EventHandler onclose; }|. This EventHandler has been in our code base since ever but it's not part of the Workers spec and no other browses i

Re: Intent to ship: Storage API estimate method

What is the implementation status in other browsers? On 09/21/2016 04:42 AM, Shawn Huang wrote: Summary: ​The Storage Standard defines an API for persistent storage and quota estimates. ​The estimate() method can be used to determine

Re: Intent to ship: Storage API estimate method

On 09/22/2016 02:57 AM, Andrew Overholt wrote: On Thu, Sep 22, 2016 at 2:03 AM, smaug wrote: On 09/21/2016 04:42 AM, Shawn Huang wrote: ​Because ​Storage API needs to have SecureContext support, but currently not having isSecureContext available in Workers (bug 1269052) is problematic

Re: Intent to ship: TouchEvents (Windows), touch-action (all platforms), accessible caret

Sounds great! -Olli On 10/04/2016 11:58 PM, Kartikaya Gupta wrote: In Firefox 52 I intend to ship support for TouchEvents on Windows e10s. TouchEvent support has already been enabled on Android for a long time and has been enabled on Linux e10s as well (if you have MOZ_USE_XINPUT2=1 in your en

Re: Intent to restrict to secure contexts: navigator.geolocation

On 10/22/2016 03:59 AM, Chris Peterson wrote: On 10/21/2016 3:11 PM, Tantek Çelik wrote: > Does this mean that we'd be breaking one in 5 geolocation requests as a > result of this? That seems super high. :( Agreed. For example, my understanding is that this will break http://www.nextbus.com/

Re: Intent to ship: requestIdleCallback

On 11/04/2016 04:55 PM, Ben Kelly wrote: I think we need to fix this issue as well. I think it could probably be uplifted before requestIdleCallback() hits release, though. https://bugzilla.mozilla.org/show_bug.cgi?id=1315260 I think also https://bugzilla.mozilla.org/show_bug.cgi?id=1313989

Re: HTML spec changes about data: URIs and origins

Just to get some idea how many tests would be broken: https://treeherder.mozilla.org/#/jobs?repo=try&revision=28735d0f2e5516c5a6d1f7805a065a6edbd8f28b On 09/13/2016 03:31 PM, Frederik Braun wrote: Firefox treats iframes pointing to a data URL as same-origin. This is all well-known, was part of

Re: HTML spec changes about data: URIs and origins

On 11/07/2016 10:41 PM, smaug wrote: Just to get some idea how many tests would be broken: https://treeherder.mozilla.org/#/jobs?repo=try&revision=28735d0f2e5516c5a6d1f7805a065a6edbd8f28b The results show that quite a few tests need to be fixed, if we want to change data: handling. Shoul

[e10s] Higher priority handling for vsync in child processes

Hi, the latest nightly has higher priority for vsync/refreshDriver/requestAnimationFrame handling in child processes [1], which should make rendering updates smoother, at least in some cases. If you see any unexpected behavior, please file bugs and CC me, :smaug. And if there are cases when

Re: [e10s] Higher priority handling for vsync in child processes

wrote: On 10/11/2016 00:22, smaug wrote: Parent process doesn't yet have higher priority handling [2]. Need to fix racy tests first. Locally using higher priority also in parent process seems to make tab throbber smoother. We have an ad-hoc mechanism for scheduling memory pressure event ahe

Re: Intent to ship: NetworkInformation

On 12/15/2016 09:53 PM, Boris Zbarsky wrote: On 12/15/16 2:39 PM, Ehsan Akhgari wrote: FWIW I was one of the people who were involved in the discussions around this for Firefox OS. From what I remember, the argument for shipping this API was that web developers have been asking for this for yea

Re: Intent to unship: BeforeAftereKeyboardEvent

On 12/16/2016 10:36 AM, Masayuki Nakano wrote: Due to the end of B2G platform, I'd like to remove mozbrowserbeforekeydown, mozbrowserbeforekeyup, mozbrowserafterkeydown and mozbrowserafterkeyup events and its event classes. They were implemented by bug 989198 [1] for allowing embedded browser e

Re: Introducing mozilla::Result for better error handling

On 12/22/2016 08:14 PM, Bobby Holley wrote: We've had this debate several times already, culminating in the attempt to ban NS_ENSURE_* macros. It didn't work. This is a bit different. One of the most common NS_ENSURE_ macros is SUCCESS variant which explicitly has the return value. MOZ_TRY doe

Re: Introducing mozilla::Result for better error handling

On 12/20/2016 03:46 PM, Jan de Mooij wrote: Hi all, A few weeks ago we added mozilla::Result to MFBT [0][1]. I was asked to inform dev-platform about this, so here's a quick overview. mozilla::Result is based on Rust's Result type [2]. It contains either a success value of type V or an error val

Re: Intent to Experiment: CSS Houdini Paint API Level 1

On 01/05/2017 06:00 PM, Jet Villegas wrote: Spec: https://drafts.css-houdini.org/css-paint-api/ Summary: The CSS Paint API is the first of several Web Rendering proposals from the CSS Houdini Task Force. The CSS Paint API allows Web authors to define and register a custom Paint method to be exec

Re: Report about the NetworkInformation meeting

On 01/07/2017 02:55 AM, Andrea Marchesini wrote: Today we had a meeting about the next steps for NetworkInformation API. The results of this meeting are: 1. we want to keep what we have in m-c. It means NetworkInformation enabled on fennec, main-thread and workers. It stays disabled on desktop.

Re: Deprecating XUL in new UI

On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the application as much as possible. The benefits for doing this are varied, some obvious examples: * XUL is a proprietary standard and we ba

Re: Deprecating XUL in new UI

On 01/17/2017 12:05 AM, Dave Townsend wrote: Trees! I knew I was forgetting something, thank you. Yeah those are things we're going to need some sane replacements for. AS far as XBL goes, while I suspect it works from HTML documents I think we want to be phasing out use of XBL too for pretty muc

Re: Deprecating XUL in new UI

On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote: On Mon, Jan 16, 2017 at 3:08 PM, smaug wrote: On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL from the application as much as possible

Re: Deprecating XUL in new UI

On 01/18/2017 08:28 AM, smaug wrote: On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote: On Mon, Jan 16, 2017 at 3:08 PM, smaug wrote: On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the things I've been investigating since moving back to the desktop team is how we can remove XUL fro

Re: Intent to implement and ship: URLSearchParams from array or object

So we'll get support for object too in FF53, not only array? On 01/17/2017 07:11 PM, Andrea Marchesini wrote: Summary: URLSearchParams constructor is changed in the latest URL spec. Now it's possible to create URLSearchParams objects starting from a string, an array and from an object. Bugs: ht

Re: Deprecating XUL in new UI

Ryan On Wed, Jan 18, 2017 at 12:50 AM, smaug wrote: On 01/18/2017 08:28 AM, smaug wrote: On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote: On Mon, Jan 16, 2017 at 3:08 PM, smaug wrote: On 01/16/2017 10:43 PM, Dave Townsend wrote: One of the things I've been investigating since movi

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)

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

Re: Firing events at the window vs. firing them at the chrome event handler

On 03/04/2013 08:20 PM, Boris Zbarsky wrote: On 3/4/13 1:08 PM, Zack Weinberg wrote: It only needs to be certain of seeing the event despite anything content can do, In that case, a capturing handler on the chrome event listener will work fine. -Boris or capturing or bubbling event listene

Re: Revamping touch input on Windows

On 04/18/2013 03:50 PM, Jim Mathies wrote: We have quite a few issues with touch enabled sites on Windows. [1] Our support for touch stretches back to when we first implemented MozTouch events which over time has morphed into a weird combination of W3C touch / simple gestures support. It is rat

Re: Accelerating exact rooting work

On 04/23/2013 04:07 PM, Tom Schuster wrote: At the moment it's really just Jono working full time on this, and terrence and other people reviewing. This stuff is actually quite easy and you can expect really fast review times from our side. In some parts of the code rooting could literally just

Re: Accelerating exact rooting work

On 04/23/2013 06:23 PM, Ehsan Akhgari wrote: Hmm, another question. Your list includes a bunch of stuff under tools/profiler, and I took a quick look and picked JSObjectBuilder.cpp. Changing the JS::Value's there to JS::RootedValue's cause compiler errors about conversion from jsvals when us

Re: We should drop MathML

On 05/06/2013 05:46 AM, Benoit Jacob wrote: Let me just reply to a few points to keep this conversation manageable: 2013/5/5 Here are a couple of reasons why dropping MathML would be a bad idea. (While I wrote this others made some of the points as well.) * MathML is part of HTML5 and epub3.

Re: review stop-energy (was 24hour review)

On 07/09/2013 03:14 PM, Taras Glek wrote: Hi, Browsers are a competitive field. We need to move faster. Eliminating review lag is an obvious step in the right direction. I believe good code review is essential for shipping a good browser. Conversely, poor code review practices hold us back. I

Re: Is it necessary to remove message listeners?

On 07/27/2013 06:06 AM, Mark Hammond wrote: On 27/07/2013 2:53 AM, Justin Lebar wrote: ... > Whether or not we totally succeed in this endeavor is another question entirely. You could instrument your build to count the number of live nsFrameMessageManager objects and report the number of messa

Re: Refcounting threadsafety assertions are now fatal in opt builds.

On 08/30/2013 10:48 PM, Kyle Huey wrote: The assertions that we have to catch refcounting objects on the wrong thread are now fatal in opt builds. This change is scoped to the nightly channel to avoid performance penalties on builds that are widely used, and will not propagate to aurora. See bu

Re: DevTools: how to get list of mutation observers for an element

a bug for this? Yes, please. CC me -Olli :smaug Honza ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: proposal to use JS GC Handle/Rooted typedefs everywhere

On 09/18/2013 10:55 PM, Luke Wagner wrote: To save typing, the JS engine has typedefs like typedef Handle HandleObject; typedef Rooted RootedValue; and the official style is to prefer the HandleX/RootedX typedefs when there is no need to use the Handle/Rooted template-ids directly. This issue

Re: Poll: What do you need in MXR/DXR?

- Clicking on macros seem to lead to some results, but definitely not the one I'd expect - the definition of the macro. - Trying to find files is hard. (Still haven't figured out how to get easily from the main page to Navigator.cpp on dom/base) - "cycleCollection" on the right side may or m

Re: Killing the Moz Audio Data API

On 10/17/2013 12:09 AM, Ehsan Akhgari wrote: I'd like to write a patch to kill Moz Audio Data in Firefox 28 in favor of Web Audio. We added a deprecation warning for this API in Firefox 23 (bug 855570). I'm not sure what our usual process for this kind of thing is, should we just take the patch

Re: Closure of trunk trees - owners for bugs needed

On 11/01/2013 07:55 AM, Nicholas Nethercote wrote: I have (slightly optimistically) started writing a post-mortem of this closure, analyzing what went wrong and why, and how we might avoid it in the future: https://etherpad.mozilla.org/mEB0H50ZjX FWIW, I added the following TL;DR to the doc

How to reduce the time m-i is closed?

Hi all, the recent OOM cases have been really annoying. They have slowed down development, even for those who haven't been dealing with the actual issue(s). Could we handle this kind of cases differently. Perhaps clone the bad state of m-i to some other repository we're tracking using tbpl, b

Re: Is there any reason not to shut down bonsai?

On 11/21/2013 09:43 PM, Laura Thomson wrote: I'll keep it short and to the point. Are there any objections to shutting down http://bonsai.mozilla.org/cvsqueryform.cgi ? If you don't know what that is--and few people do, which is even more reason to shut it off--it's a search engine for some of

Re: Is there any reason not to shut down bonsai?

On 11/21/2013 10:15 PM, Gavin Sharp wrote: It would be good to explore alternatives to Bonsai. https://github.com/mozilla/mozilla-central is supposed to have full CVS history, right? Some concerns with that alternative: - I think that repo misses some history from some branches of CVS - I'm not

unified build mode and memory consumption

Hi all and FYI unified build mode has increased memory usage of building with gcc significantly. On my laptop (8 gig mem) I started to see some swapping, and because of that build times with unified mode weren't that much better than before. But now, finally there is a use case for clang - it

Removing favor-perf-mode

user input or paint requests). I do expect some tp regressions but significant tp_responsiveness improvements. (I'll need to still fix few racy tests before landing) -smaug [1] https://bugzilla.mozilla.org/show_bug.cgi?id=930793 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=7

Re: Can we start using C++ STL containers in Mozilla code?

On 12/10/2013 11:28 AM, Chris Pearce wrote: Hi All, Can we start using C++ STL containers like std::set, std::map, std::queue in Mozilla code please? Many of the STL containers are more convenient to use than our equivalents, and more familiar to new contributors. I understand that we used to

Re: On the usefulness of style guides (Was: style guide proposal)

On 12/20/2013 12:11 AM, Ehsan Akhgari wrote: On 12/19/2013, 12:57 PM, Till Schneidereit wrote: I think we should do more than encourage: we should back out for all style guide violations. Period. We could even enforce that during upload to a review tool, perhaps. However. This has to be done on

Re: A proposal to reduce the number of styles in Mozilla code

Sounds good, and I'd include also js/* so that we had consistent style everywhere. It is rather painful to hack various non-js/* and js/* (xpconnect in my case) in the same patch. (I also happen to think that Mozilla coding style is inherently better than js style, since it has clear rules for n

Re: A proposal to reduce the number of styles in Mozilla code

le. I could perhaps be persuaded at some point if someone wants to do the leg work. bholley On Mon, Jan 6, 2014 at 6:07 AM, smaug wrote: Sounds good, and I'd include also js/* so that we had consistent style everywhere. It is rather painful to hack various non-js/* and js/* (xpconnect in

Re: List of deprecated constructs [was Re: A proposal to reduce the number of styles in Mozilla code]

On 01/07/2014 01:38 AM, Joshua Cranmer 🐧 wrote: On 1/6/2014 4:27 PM, Robert O'Callahan wrote: That's just not true, sorry. If some module owner decides to keep using NULL or PRUnichar, or invent their own string class, they will be corrected. Maybe. But we also have a very large number of dep

Re: Please use NS_WARN_IF instead of NS_ENSURE_SUCCESS

On 11/22/2013 10:18 PM, Benjamin Smedberg wrote: With the landing of bug 672843, the NS_ENSURE_* macros are now considered deprecated. If you are writing code that wants to issue warnings when methods fail, please either use NS_WARNING directly or use the new NS_WARN_IF macro. if (NS_WARN_IF(s

Re: Please use NS_WARN_IF instead of NS_ENSURE_SUCCESS

On 01/07/2014 02:58 AM, Karl Tomlinson wrote: smaug writes: Why this deprecation? NS_ENSURE_ macros hid return paths. Also many people didn't understand that they issued warnings, and so used the macros for expected return paths. Was there some useful functionality that is not provid

Re: Mozilla style guide issues, from a JS point of view

On 01/07/2014 02:46 AM, Jeff Walden wrote: I'm writing this list, so obviously I'm choosing what I think is on it. But I think there's rough consensus on most of these among JS hackers. JS widely uses 99ch line lengths (allows a line-wrap character in 100ch terminals). Given C++ symbol names

Re: Please use NS_WARN_IF instead of NS_ENSURE_SUCCESS

On 01/07/2014 05:14 PM, smaug wrote: On 01/07/2014 08:46 AM, Bobby Holley wrote: On Mon, Jan 6, 2014 at 5:04 PM, smaug wrote: no, since it is always possible to expand those macros. However if (NS_WARN_IF(NS_FAILED(rv)) { return rv; } is super ugly. Note that there in a explicit

Re: Please use NS_WARN_IF instead of NS_ENSURE_SUCCESS

On 01/07/2014 08:46 AM, Bobby Holley wrote: On Mon, Jan 6, 2014 at 5:04 PM, smaug wrote: no, since it is always possible to expand those macros. However if (NS_WARN_IF(NS_FAILED(rv)) { return rv; } is super ugly. Note that there in a explicit stylistic exception that NS_WARN_IF

Re: Tracking Docshells

On 02/13/2014 12:53 PM, Girish Sharma wrote: Thank you everyone for your inputs. Since there is no current method of precisely tracking window creation and removal, how should I proceed and add such functionality ? What I basically want is that despite of BFCache or anything, I should be able to

Re: ISomething, nsISomething or mozISomething?

On 02/17/2014 11:18 PM, Justin Dolske wrote: On 2/17/14 12:41 PM, Ehsan Akhgari wrote: On 2/17/2014, 9:15 AM, David Rajchenbach-Teller wrote: Do we have naming conventions for new xpcom interfaces? I believe that I have seen all three forms on the tree. I need to pick one for my new bug. Which

Re: Please do not add new web-exposed XPCOM objects

On 03/14/2014 11:20 PM, Boris Zbarsky wrote: We're at a point where we are actively trying to eliminate xpconnect usage on the web. I'm happy to enumerate the reasons we're doing that if people care, but the practical upshot is: 1) Do not add new objects with classinfo to nsDOMClassInfo.cpp

Re: DXR gets multi-line highlighting

On 03/19/2014 12:10 AM, Karl Tomlinson wrote: On Thu, 13 Mar 2014 12:46:14 -0400, Erik Rose wrote: A lot of you have asked for the ability to select and share ranges within source files. Now, thanks to contributor Jamon Carmisso, you can: http://dxr.mozilla.org/mozilla-central/source/content/m

Re: Intent to ship: CSS Variables

On 03/18/2014 11:26 AM, Cameron McCormack wrote: CSS Variables is a feature that allows authors to define custom properties that cascade and inherit in the same way that regular properties do, and to reference the values of these custom properties in the values of regular properties (and other

Re: Memory management in features implemented in JS

On 03/20/2014 01:39 AM, Kyle Huey wrote: Followup to dev-platform please. We are discovering a lot of leaks in JS implemented DOM objects. The general pattern seems to be that we have a DOM object that also needs to listen to events from the message manager or notifications from the observer se

Re: Memory management in features implemented in JS

On 03/20/2014 01:58 AM, smaug wrote: On 03/20/2014 01:39 AM, Kyle Huey wrote: Followup to dev-platform please. We are discovering a lot of leaks in JS implemented DOM objects. The general pattern seems to be that we have a DOM object that also needs to listen to events from the message

Re: Memory management in features implemented in JS

On 03/20/2014 02:25 AM, smaug wrote: On 03/20/2014 01:58 AM, smaug wrote: On 03/20/2014 01:39 AM, Kyle Huey wrote: Followup to dev-platform please. We are discovering a lot of leaks in JS implemented DOM objects. The general pattern seems to be that we have a DOM object that also needs to

Re: Memory management in features implemented in JS

ovides no guarantees about cycles, but if this is necessary, I could rework it in something a bit faster/more robust. Cheers, David On 3/20/14 1:25 AM, smaug wrote: And we could add a flag to WrappedJS so that it would call some callback when it is about to go away. That would let cleanup of Wea

Re: Graceful Platform Degradation

On 03/27/2014 10:26 AM, Nicholas Nethercote wrote: This sounds like a worthy and interesting idea, but also a very difficult one. PC games allow the user to turn certain features (mostly graphics related ones) on and off so that they can find their own level of acceptable performance/quality.

Re: Graceful Platform Degradation

lower refresh rate in some cases in order to try to avoid extra layout flushes etc. --Jet - Original Message - From: "smaug" To: "Nicholas Nethercote" , "Jet Villegas" Sent: Friday, March 28, 2014 11:16:42 AM Subject: Re: Graceful Platform Degradation Per

Re: Promise.jsm and the predefined Promise object

On 03/29/2014 02:55 PM, Paolo Amadini wrote: With bug 988122 landing soon, you'll now find a "Promise" object available by default in the global scope of JavaScript modules. However, this default implementation is still limited, and you're strongly recommended to import Promise.jsm explicitly in

Re: Recommendations on source control and code review

On 04/14/2014 12:42 AM, Robert O'Callahan wrote: On Sat, Apr 12, 2014 at 8:29 AM, Gregory Szorc wrote: I came across the following articles on source control and code review: * https://secure.phabricator.com/book/phabflavor/article/ recommendations_on_revision_control/ * https://secure.phabri

Re: Getting rid of already_AddRefed?

On 08/12/2014 06:23 PM, Aryeh Gregor wrote: On Tue, Aug 12, 2014 at 6:16 PM, Benoit Jacob wrote: As far as I know, the only downside in replacing already_AddRefed by nsCOMPtr would be to incur more useless calls to AddRef and Release. In the case of "threadsafe" i.e. atomic refcounting, these u

Re: Getting rid of already_AddRefed?

On 08/13/2014 07:24 PM, Aryeh Gregor wrote: On Wed, Aug 13, 2014 at 5:44 PM, Ehsan Akhgari wrote: Can't you do the following instead? unused << MyFunction(); // I know that I'm leaking this ref, but it's ok somehow No, because the use-case is where you don't want to leak the ref -- you want

Re: Intent to implement: Touchpad event

What would be the event types for touchpad events? We must not add yet another types of events to handle pointer type of events. And besides, touch event model is rather horrible, so if we for some strange reason need totally new events, I'd prefer using something closer to pointer events. -Ol

<    1   2   3   >