swapDocShells
Firebug started throwing an exception (since Friday last week) swapDocShells is not a function ... every time it's detached. Is the method removed? If yes, are there any alternatives? Honza ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Mon, Jul 22, 2013 at 10:01 PM, Rob Arnold tell...@gmail.com wrote: That idiom seems dangerous by itself; the assumption it makes is that the reference will outlive the callee but that isn't actually enforced anywhere (you could write UseFoo(nsRefPtrT(new T)) and Bad Things would happen; there are less obvious ways to write this). I would rewrite UseFoo to take an const nsRefPtrnsIFoo instead and then you don't have to worry about these issues. It is dangerous. See discussion here, which Ralph Giles linked to: https://bugzilla.mozilla.org/show_bug.cgi?id=767178 In particular, I've fixed a crash bug and a security bug caused by this idiom, and I'm sure there are many more like them. (Although getting rid of mutation events would help a lot!) However, just making the argument be a refptr means the function call does addref and release on every call even if the caller is already holding a reference, which has been deemed unacceptable from a perf standpoint. A couple of suggestions were made in the linked-to bug to ameliorate the problem, but nobody has come up with a scheme that gives the same safety as nsRefPtr-as-param-type without unacceptable runtime cost. Most of the problem could be solved if you required that nsCOMPtr/nsRefPtr only be used as a local variable (in particular, not member variables) and introduced a type COMParam/RefParam or something that implicitly converted from nsCOMPtr/nsRefPtr without addref/release but didn't convert implicitly from raw pointer at all, so the caller would have to wrap it in something that did the addref/release. Then -- in theory -- the caller should hold a reference throughout the function call, unless you do something really obnoxious like store a non-const reference to the local variable somewhere that the callee can get at. Callees that were really super duper sure they didn't need a strong reference could still use the raw pointer for parameters if they wanted to save the addref/release. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: swapDocShells
On 7/23/13 10:38 AM, Jan Odvarko wrote: Is the method removed? No. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Changes to XPCOM refcounting
As part of an effort to remove use of the NSPR atomic macros in favor of mozilla::Atomic, the way that threadsafe reference counting works in XPCOM has changed. Whereas before, this was done using the macros by saying NS_IMPL_THREADSAFE_ISUPPORTSN (or related macros), now the threadsafe declaration has been changed to NS_DECL_THREADSAFE_ISUPPORTS in the class body. All of the affected NS_IMPL_THREADSAFE macros have been removed as a result, which may cause some patch bustage. Also related to this change, the NS_AtomicRefcnt functions and nsAtomicRefcnt.h itself have been removed (use mozilla::ThreadSafeAutoRefcnt instead). This change is being tracked in bug 884061 and has landed in mozilla-inbound already. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: intent to make exception to prefixing policy: -moz-(osx-)?font-smoothing
I think we found usage of -moz-font-smoothing in the wild. John Jensen may have more info. --Jet - Original Message - From: L. David Baron dba...@dbaron.org To: dev-platform@lists.mozilla.org Sent: Tuesday, July 23, 2013 12:43:54 PM Subject: intent to make exception to prefixing policy: -moz-(osx-)?font-smoothing FYI, I intend to make an exception to our current policy on experimental features and vendor prefixes by granting review on https://bugzilla.mozilla.org/show_bug.cgi?id=857142 , because: * while I proposed in comment 51 and on www-style an alternative that would avoid vendor prefixes, it hasn't gotten much support (the only support I've seen was from sgalineau on www-style) * the feature is already supported with vendor prefixes on all other major browsers on Mac OS X (as -webkit-font-smoothing), and I've seen no indications from either WebKit or Blink folks on interest in converging * we're under significant pressure to implement the feature immediately (I haven't yet decided whether to grant review as -moz-font-smoothing, -moz-osx-font-smoothing, or to leave the choice up to the patch author, but I plan to decide that soon.) -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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changes to XPCOM refcounting
On Tue, Jul 23, 2013 at 11:22 AM, Joshua Cranmer pidgeo...@gmail.comwrote: As part of an effort to remove use of the NSPR atomic macros in favor of mozilla::Atomic, the way that threadsafe reference counting works in XPCOM has changed. Whereas before, this was done using the macros by saying NS_IMPL_THREADSAFE_ISUPPORTSN (or related macros), now the threadsafe declaration has been changed to NS_DECL_THREADSAFE_ISUPPORTS in the class body. All of the affected NS_IMPL_THREADSAFE macros have been removed as a result, which may cause some patch bustage. Also related to this change, the NS_AtomicRefcnt functions and nsAtomicRefcnt.h itself have been removed (use mozilla::ThreadSafeAutoRefcnt instead). This change is being tracked in bug 884061 and has landed in mozilla-inbound already. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform To be clear, which classes have threadsafe addref/release hasn't changed, just the macro usage, right? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changes to XPCOM refcounting
On 7/23/2013 4:17 PM, Kyle Huey wrote: To be clear, which classes have threadsafe addref/release hasn't changed, just the macro usage, right? One or two classes that weren't really threadsafe to begin with had their threadsafety dropped on request of reviewers, and several more could well have their threadsafety attributes removed in the near future. But most of the several hundred classes have not had their threadsafety changed. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 10/07/13 23:14, Taras Glek wrote: I tried to capture feedback from this thread in https://wiki.mozilla.org/Code_Review I just did a pass over that page to highlight the key points. I added a Tips and Tricks section, with some tips on practices to make interdiff creation easier. -- Randell Jesup, Mozilla Corp remove .news for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
