Re: refcounting - which types to use ?

On Thu, Aug 17, 2017 at 7:07 AM, Enrico Weigelt, metux IT consult wrote: > OTOH, is there a way to create versions that really return it as rval, > so I conveniently could just call like that ? > >nsCOMPtr list = addrbook->FindRecipients(addr); You can do this with a return type of already_Ad

Re: Linking with lld instead of ld/gold

On Mon, Aug 14, 2017 at 12:08 AM, Sylvestre Ledru wrote: > Packages for lld on Debian & Ubuntu are available on https://apt.llvm.org/ Ubuntu 16.04 and later also has an lld-4.0 package in its own repos (sudo apt install lld-4.0). ___ dev-platform mailin

Re: Intent to change editor newline behavior

On Thu, Apr 6, 2017 at 3:34 PM, Ehsan Akhgari wrote: > Thanks for the follow-ups and for filing bug 1354060. But now that we > know that this affected Gmail, I'll note that the risk around this is > still there, and while keeping this on the pre-release channels for a > while reduces the risk som

Re: Intent to change editor newline behavior

On Wed, Apr 5, 2017 at 11:22 PM, Daniel Veditz wrote: > One line or a thousand isn't the point; building, release and update > testing, and shipping 90 locales times 6 platforms is a huge amount work. If > we have a pref and break something we can back it out easily and quickly. We > could even do

Re: Enabling Pointer Events in Firefox (desktop) Nightly on Mac and Linux

On Wed, Apr 5, 2017 at 7:34 PM, Tom Ritter wrote: > It looks like this exposes pointerType, which reveals whether the user > is using a mouse, pen, or touch input. > > It also exposes detailed information about the geometry of the input > (size of the thing pointing, pressure, tilt, twist. > > All

Re: Intent to change editor newline behavior

On Wed, Apr 5, 2017 at 4:48 PM, Ehsan Akhgari wrote: > Originally it seemed that you are working under the assumption that most > sites are overriding our default newline handling behavior. This is > very easy to measure through telemetry by adding a probe for example > that looks when an HTML ed

Re: Intent to change editor newline behavior

On Wed, Apr 5, 2017 at 3:12 AM, Ehsan Akhgari wrote: > Exactly. We can hypothesize either way, but we certainly can't know easily > without getting some data first. But unfortunately it's not possible to > collect data about what sites are doing in terms of DOM fix-ups like this. > We can, at le

Re: Intent to change editor newline behavior

On Tue, Apr 4, 2017 at 5:57 PM, Ehsan Akhgari wrote: > I don't own this module any more, so this isn't my call to make, but if > I had to choose what to do here, I would probably either choose to not > change our behavior (since I'm not sure what we're gaining here > concretely -- as AFAIK we're n

Re: Intent to change editor newline behavior

On Mon, Apr 3, 2017 at 11:39 PM, Benjamin Smedberg wrote: > > I'd like to encourage you to set up a test plan for this. My impression of > the risk profile of this work is that we could easily break some really > important use-cases, and it's likely that sites customize for gecko behavior > and

Intent to change editor newline behavior

In our rich-text editor (used in Firefox for designMode and contenteditable), when the user hits Enter, we have historically always inserted a . This does not match any other browsers, which use or as line separators. In bug 1297414, I'm changing our behavior to use as a line separator. This

Re: Removing navigator.buildID?

On Mon, Oct 31, 2016 at 4:00 PM, Henri Sivonen wrote: > On Mon, Oct 31, 2016 at 3:01 PM, Aryeh Gregor wrote: >> If the concern is fingerprinting, perhaps it could be exposed only to >> sites that the user is logged into (assuming we have a good working >> definition of &quo

Re: Removing navigator.buildID?

On Mon, Oct 31, 2016 at 10:02 AM, Chris Peterson wrote: > Alternately, buildID could be hidden behind a domain whitelist pref, seeded > with sites working with Mozilla. If you are, say, a Netflix customer, they > already know who you are, so exposing your buildID to them is not much of a > trackin

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

On Tue, Oct 25, 2016 at 9:43 PM, Eric Rescorla wrote: > Setting aside the policy question, the location API for mobile devices > generally > gives a much more precise estimate of your location than can be obtained > from the upstream network provider. For instance, consider the case of the > ISP u

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

On Tue, Oct 25, 2016 at 8:12 PM, Anne van Kesteren wrote: > The basic problem is prompting the user at all for non-HTTPS since > that leads them to think they can make an informed decision whereas > that's very much unclear. So prompting more would just make the > problem worse. > > We want to get

Re: Intent to implement and ship: SVGElement.prototype.dataset

On Thu, Aug 11, 2016 at 12:53 AM, Boris Zbarsky wrote: > Summary: HTML elements have a .dataset property that allows convenient > somewhat structured access to data-* attributes. The proposal is to add > this to SVG elements too, following corresponding changes in the SVG > specification. Why do

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

On Mon, Aug 15, 2016 at 3:55 PM, Aryeh Gregor wrote: > IMO, it makes sense to move ahead with this. One more point I forgot to (re-?)mention: with proper move constructors, it's not just already_AddRefed return values that should be changed to RefPtr, but also T* return values, in the ca

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

Sorry for the necroposting, but some points that I think are still worth correcting: On Thu, Jun 16, 2016 at 11:50 AM, Boris Zbarsky wrote: > On 6/16/16 3:15 AM, jww...@mozilla.com wrote: >> >> I think that is the legacy when we don't have move semantics. Returning >> RefPtr won't incur ref-count

Re: Intent to ship: invalid values behave like "metadata", not "subtitles"

On Sun, May 8, 2016 at 9:15 AM, Simon Pieters wrote: > httparchive (494,168 pages): > > SELECT COUNT(*) AS num, REGEXP_EXTRACT(LOWER(body), > r']+\s)?kind\s*=\s*([a-z]+|["\'][^"\']+["\'])') as match > FROM [httparchive:har.2016_04_15_chrome_requests_bodies] > GROUP BY match > ORDER BY num DESC > >

Re: Intent to ship: invalid values behave like "metadata", not "subtitles"

On Thu, May 5, 2016 at 4:32 PM, Florin Mezei wrote: > Do you still intend to do some analysis to see whether this will be a > problem in real life? We have somewhat of a history in shipping changes that > break compatibility, and then end up doing dot releases (in some cases). I wasn't planning o

Intent to ship: invalid values behave like "metadata", not "subtitles"

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1269712 Relevant change in standards: https://github.com/whatwg/html/issues/293, also maybe https://www.w3.org/2015/10/28-htmlcue-minutes.html Bugs filed against other UAs: https://bugs.chromium.org/p/chromium/issues/detail?id=608772 https://bugs.

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 9:58 PM, Boris Zbarsky wrote: > For a 900KB stack (what we have on Windows, per > ) > 512 DOM nodes deep corresponds to ~2KB per DOM node. 200 deep corresponds > to 5KB. > > Now quick, tel

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 9:19 PM, Steve Fink wrote: > It makes me nervous to try to make the overflow behavior the same across > engines, because it could end up restricting implementation choices. But > making things roughly the same without trying to make them too much the same > seems reasonable.

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 8:51 PM, L. David Baron wrote: > So, at the very > least, limiting in the parser isn't effective anymore and we need > checks at later stages, which hopefully could be done in a > standardizable way. Having dynamic fallback checks for anything not currently standardized is

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 8:07 PM, Bobby Holley wrote: > In general, dynamic stack checks (measuring the top of the stack at XPCOM > startup, and comparing it with the stack at the point of interest) seem > preferable to hard-coding number-of-recursive-calls, since it doesn't > depend on the size of

Re: Can MAX_REFLOW_DEPTH be increased?

Test-case: var cur = document.querySelector("script"); var depth = -1; while (cur) { cur = cur.parentNode; depth++; } document.body.textContent = depth; Outputs 513 in Chrome. It looks like any further s are inserted as siblings instead of children. The is processed correctly. IE11

Re: Can MAX_REFLOW_DEPTH be increased?

On Mon, May 2, 2016 at 10:22 AM, Henri Sivonen wrote: > If the depth limit is still needed, can now be increased? What do other UAs do? This seems like it may as well be standardized, just so the odd corner-case page breaks the same in all UAs. ___ dev

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

On Tue, Apr 19, 2016 at 5:13 PM, Boris Zbarsky wrote: > We could try to mitigate through searching web content for the relevant > method names, but I believe that was already done when writing the spec. I > could be wrong, of course > > Past that, I'm not sure how to design a test plan that w

Re: Moving XP to ESR?

On Mon, Apr 18, 2016 at 9:02 PM, Chris Peterson wrote: > OTOH, if an XP users doesn't mind running an unpatched OS, then they > probably won't care/know about running an unpatched Chrome browser. Gmail nags you if you use an outdated Chrome version. I know someone who asked me to take a look at

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

On Thu, Apr 14, 2016 at 11:54 AM, Chris Peterson wrote: > * Sites that allow users to configure preferences without logging into an > account would forget the users' preferences if they are not using HTTPS. For > example, companies that have regional sites would forget the user's selected > region

Re: Coding style for C++ enums

On Fri, Apr 8, 2016 at 8:35 PM, smaug wrote: > enum classes are great, but I'd still use prefix for the values. Otherwise > the values look like types - nested classes or such. > (Keeping my reviewer's hat on, so thinking about readability here.) In some cases I think it's extremely clear, like

Re: Maintaining the en-US dictionary that ships with Mozilla products

On Mon, Dec 28, 2015 at 9:31 PM, Jörg Knobloch wrote: > Thirdly, the add-on dictionary contains 13% more words than the Mozilla > maintained dictionary, and I think in dictionaries, bigger is better. This is not always true for spelling correction, because there may be common words that can be m

Intent to unship: DocumentType.internalSubset

The current DOM standard says DocumentType.internalSubset should be removed: https://dom.spec.whatwg.org/#dom-documenttype-internalsubset It looks like Chrome has already removed it: https://code.google.com/p/chromium/issues/detail?id=272096 http://codereview.chromium.org/282823004 It seems the

Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

On Sun, Oct 11, 2015 at 2:09 PM, Aryeh Gregor wrote: > A new language feature could be used to solve this: allow conversion > operators to behave differently based on how the variable is declared. > For instance, it might convert differently if the source or > destination is a lo

C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

In bug 1193762, there's been work on eliminating the implicit conversion from nsCOMPtr to T*, at least for rvalues, to avoid the safety problem discussed there. The problem is that then you can't pass an nsCOMPtr&& to a function that wants a T*, even though this is perfectly safe: the lifetime of

Re: Use of 'auto'

On Sun, Aug 2, 2015 at 8:37 PM, Joshua Cranmer 🐧 wrote: > I've discussed this several times, but with we added operator T*() && = > delete;, that would prevent the scenario you're talking about here. And FWIW, I have patches that I'm going to shortly submit to bug 1179451 that do this for nsRefPt

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

On Tue, Jul 7, 2015 at 6:10 PM, Michael Layzell wrote: > No, I never checked if it happens on an optimized build, but as C++ follows > an "as-if" principal, which means that code has to execute as if those > temporaries had been created. Unfortunately, AddRef and Release are virtual, > which, I'm

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

On Fri, Jul 3, 2015 at 6:22 PM, Michael Layzell wrote: > So the ternary actually causes an unnecessary AddRef/Release pair, neat. Did you check whether this actually occurs in an optimized build? C++ allows temporaries to be optimized away under some circumstances, e.g., when returning a local v

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

On Fri, Jul 3, 2015 at 3:56 PM, Neil wrote: > Aryeh Gregor wrote: > >> we still want a new type for function parameters that accepts implicit >> conversions from nsRefPtr/nsCOMPtr, to use instead of raw pointers. >> > Sure, but that won't stop someone from writin

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

On Thu, Jul 2, 2015 at 3:50 PM, Neil wrote: > Would you mind reminding me what the failure case this avoids is? already_AddRefed ReturnFoo1() { nsRefPtr foo = new Foo(); return foo.forget(); } nsRefPtr ReturnFoo2() { return new Foo(); } // This doesn't compile Foo* foo = ReturnFoo1(); //

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

On Wed, Jul 1, 2015 at 6:24 AM, Joshua Cranmer 🐧 wrote: > > You'd get the same benefit, I think, by making operator T*() && = delete;, > syntax which is accepted on gcc 4.8.1+, clang, and MSVC 2015 IIRC. I once tried this and found it had problematic side effects that made deploying it difficult

Re: Use of 'auto'

On Wed, Jun 3, 2015 at 12:14 AM, Joshua Cranmer 🐧 wrote: > The case which I am personally very much on the fence is integral types. On > the one hand, sometimes the type just doesn't matter and you want to make > sure that you have the same type. On the other hand, I have been very burned > before

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

On Thu, Apr 30, 2015 at 6:49 PM, Trevor Saunders wrote: > I don't think it would actually be backward incompatible the only > changes would be turning invalid programs into valid ones. Given that "void foo() override;" currently makes foo() a virtual function, allowing override on non-virtual fun

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

On Tue, Apr 28, 2015 at 4:07 AM, Ehsan Akhgari wrote: > Well, we're not talking about changing C++. ;-) My understanding is that the C++ committee will never change the meaning of existing programs without extremely compelling reason, so if override currently implies virtual, I think we can safe

Re: Intent to deprecate: Insecure HTTP

On Tue, Apr 14, 2015 at 3:36 PM, Gervase Markham wrote: > Yep. That's the system working. CA does something they shouldn't, we > find out, CA is no longer trusted (perhaps for a time). > > Or do you have an alternative system design where no-one ever makes a > mistake and all the actors are trustw

Re: Intent to deprecate: persistent permissions over HTTP

On Thu, Mar 12, 2015 at 3:56 PM, Adam Roach wrote: > As an aside, the first three are not just fixable, but actually fixed within > the next few months: https://letsencrypt.org/ That seems like a huge step forward. But putting my ex-sysadmin hat on -- assuming it works as advertised, there are s

Re: Intent to deprecate: persistent permissions over HTTP

On Mon, Mar 16, 2015 at 3:24 PM, Eric Rescorla wrote: > Lots of people have the cameras in their rooms pointing at them even when > they are not using the computer, and so the camera can be used to spy on > them (Again, I refer you to Checkoway's description of "ratting" [1]). This > might be more

Re: Intent to deprecate: persistent permissions over HTTP

On Thu, Mar 12, 2015 at 9:42 PM, Boris Zbarsky wrote: > On 3/12/15 3:31 PM, Aryeh Gregor wrote: >> >> 2) Attacker opens a background tab and navigates it to http://b.com (I >> can't think of a JavaScript way to do this, but if there isn't one, >> making a big

Re: Intent to deprecate: persistent permissions over HTTP

On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari wrote: >> 2) If the only common real-world MITM threat is via a compromise >> adjacent to the client (e.g., wireless), there's no reason to restrict >> geolocation, because the attacker already knows the user's location >> fairly precisely. > > > I do

Re: Intent to deprecate: persistent permissions over HTTP

On Tue, Mar 10, 2015 at 5:00 PM, Boris Zbarsky wrote: > The mitigation applies in this situation: > > 1) User connects to a MITMed network (e.g. wireless at the airport or > coffeeshop or whatever) which I will henceforth call "the attacker". > 2) No matter what site the user loads, the atta

Re: Intent to deprecate: persistent permissions over HTTP

On Sat, Mar 7, 2015 at 10:33 PM, Eric Rescorla wrote: > Let's consider a different example than the one you propose: access > to the camera and microphone via getUserMedia(). Say that a site > adds a feature which lets you take a picture of yourself for your > avatar (come to think of it, I wish g

Re: Intent to deprecate: persistent permissions over HTTP

On Fri, Mar 6, 2015 at 7:27 PM, Anne van Kesteren wrote: > A large number of permissions we currently allow users to store > persistently for a given origin. I suggest we stop offering that > functionality when there's no lock in the address bar. This will make > it harder for a network attacker t

Re: HTTP/2 and User-Agent strings?

On Tue, Jan 27, 2015 at 11:31 PM, Chris Peterson wrote: > Are there recent studies of which features servers do detect and why? I > could see arguments for sharing information about mobile devices, touch > support, and OS. Long ago I used to do development for MediaWiki. We had UA string checks

Re: Getting rid of already_AddRefed?

On Sat, Dec 27, 2014 at 12:34 AM, smaug wrote: > How would this setup help with the case when one passes > nsCOMPtr/nsRefPtr member variable as a param? I believe that has been the > most common issue > with "caller-should-keep-the-parameter-alive" - one just doesn't remember to > make sure the >

Re: Getting rid of already_AddRefed?

On Sat, Dec 27, 2014 at 5:54 AM, Karl Tomlinson wrote: > Aryeh Gregor writes: > >> Do we have a better convention for an in/out parameter that's a >> pointer to a refcounted class? editor uses this convention in a >> number of functions for "pass me a node/

Re: Getting rid of already_AddRefed?

On Mon, Dec 22, 2014 at 11:10 PM, Jeff Muizelaar wrote: > Possible solutions would be to: > - remove implicit conversions to T* If this were done, I think we should change the calling convention for functions that take pointers to refcounted classes. The convention is broken anyway: the convent

Re: Proposal: Change the coding style guide to allow an 'o' prefix to indicate out-params

On Sat, Dec 6, 2014 at 1:31 AM, Botond Ballo wrote: > In APZ code, we've been using the prefix 'aOut' for out-parameters. This > keeps them consistent with the general rule of "'a' for arguments" while > identifying out-parameters with a convention. This is what I'm accustomed to as well. I pr

Re: Proposal: Standardize initializer list formatting in our coding style guide

On Wed, Dec 3, 2014 at 11:54 PM, Seth Fowler wrote: > So I noticed that we don’t say anything about initializer list formatting in > our coding style guide. I’d like to propose that we standardize this > formatting: > > Foo::Foo(int aBar, char aBaz) > : mBar(aBar) > , mBaz(aBaz) > { > …. >

Re: http-schemed URLs and HTTP/2 over unauthenticated TLS (was: Re: WebCrypto for http:// origins)

On Mon, Sep 15, 2014 at 11:34 AM, Anne van Kesteren wrote: > It seems very bad if those kind of devices won't use authenticated > connections in the end. Which makes me wonder, is there some activity > at Mozilla for looking into an alternative to the CA model? What happened to serving certs over

Re: web-platform-tests now running in automation

On Tue, Sep 9, 2014 at 3:44 PM, James Graham wrote: > Yes, I agree too. One option I had considered was making a suite > "web-platform-tests-mozilla" for things that we can't push upstream e.g. > because the APIs aren't (yet) undergoing meaningful standardisation. > Putting the editing tests into

Re: web-platform-tests now running in automation

On Sun, Sep 7, 2014 at 5:49 PM, James Graham wrote: > Well, it would also make sense to have interop for editing of course :) Not a single major browser has significant resources invested in working on their editing code. Until that changes, nothing much is going to happen. > I would certainly

Re: web-platform-tests now running in automation

On Fri, Sep 5, 2014 at 8:23 PM, James Graham wrote: > I think Ms2ger has a better answer here, but I believe it obsoletes most > of them, except a few that never got submitted to web-platform-tests > (the editing tests are in that class, because the spec effort sort of died). FWIW, the editing te

Re: PSA: ./mach build doesn't work reliably any longer

On Mon, Aug 25, 2014 at 8:27 PM, Bill McCloskey wrote: > Even if a full no-op build took no time, partial builds are still useful. > Often my workflow looks something like this: > > change files in directory D > rebuild only D, get a list of errors to fix > ...iterate until no more errors > try t

Re: Getting rid of already_AddRefed?

On Thu, Aug 14, 2014 at 12:00 PM, Neil wrote: > Well there's your problem: GetWSBoundingParent doesn't need to own the nodes > it works on. Editing code is ancient, poorly maintained, and not performance-sensitive, so personally, I don't ever use raw pointers as local variables in editor/. Bette

Re: Getting rid of already_AddRefed?

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 it to be released automatically for you.

Re: Getting rid of already_AddRefed?

On Wed, Aug 13, 2014 at 4:11 PM, Ehsan Akhgari wrote: > What goal would this achieve? I don't understand why it's OK to ignore the > return value of a function which returns an "already AddRef'ed" object from > a conceptual perspective. You might want the effect of the function but not care abou

Re: Getting rid of already_AddRefed?

On Wed, Aug 13, 2014 at 3:14 PM, Aryeh Gregor wrote: > It has > the disadvantage that you could still not pass an already_AddRefed > directly to a function that wants T*, which is unfortunate because > it's perfectly safe to do so. I can't think of any way to avoid that

Re: Getting rid of already_AddRefed?

On Wed, Aug 13, 2014 at 9:42 AM, Jeff Walden wrote: > So at risk of adding yet another flavor of thing: why not introduce an > already_AddRefed sort of struct that *does* own an addref, *will* release > on destruction if not nulled out, and does *not* explicitly convert to T*? > Give nsCOMPtr

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 7:37 PM, Benjamin Smedberg wrote: > > On 8/12/2014 12:28 PM, Joshua Cranmer 🐧 wrote: >> The rationale for why we still had it was that: >> nsIFoo *foobar = ReturnsACOMPtr(); >> >> silently leaks. > > Really? I thought that in this case there would be no leak because the > (

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 7:12 PM, Vladimir Vukicevic wrote: > It's unfortunate that we can't create a nsCOMPtr<> that will disallow > assignment to a bare pointer without an explicit .get(), but will still allow > conversion to a bare pointer for arg passing purposes. (Or can we? I admit > my C

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron wrote: > In these cases we document that it's likely safe for callers to do > this by having those getters return raw pointers. Getters that > require reference-counting return already_AddRefed. Thus the > designer of the API makes a choice about w

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 6:25 PM, L. David Baron wrote: > On Tuesday 2014-08-12 18:15 +0300, Aryeh Gregor wrote: >> 1) You can use the return value directly without assigning it to an>> 4) If >> the callee already holds a strong reference in a local variable, >> it can

Re: Getting rid of already_AddRefed?

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 use atomic instructions, > which might be

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 6:14 PM, L. David Baron wrote: > Bug 967364 did already add assertions to guarantee this. Yes, if I'm not mistaken, already_AddRefed these days is quite safe. > Two thoughts: > > (1) I think it introduces a somewhat major coding style risk, in > that it makes it possibl

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 5:59 PM, Benjamin Smedberg wrote: > Just reading bug 1052477, and I'm wondering about what are intentions are > for already_AddRefed. > > In that bug it's proposed to change the return type of NS_NewAtom from > already_AddRefed to nsCOMPtr. I don't think that actually saves

Re: Are StaticAuto/RefPtr good?

On Tue, Aug 5, 2014 at 1:09 AM, Mike Hommey wrote: > > On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote: > > Yes, that's correct. You have to clear them somehow before the > > process exits or we leak. > > Which, besides accounting, is not really a problem, since the process is > exiting

Re: Standardized assertion methods

On Fri, Jun 6, 2014 at 8:35 PM, Boris Zbarsky wrote: > https://tbpl.mozilla.org/?tree=Try&rev=e26ab6d5e1e0 says we have quite a > number of things that are in fact assuming that 5 and "5" should test is(). > I'm not sure how much I like throwing in tons of toString() for that case. Why should

Re: PSA: Refcounted classes should have a non-public destructor & should be MOZ_FINAL where possible

On Thu, May 29, 2014 at 12:27 AM, Daniel Holbert wrote: > For now, our code isn't clean enough for this sort of static_assert to > be doable. :-/ And we have at least one instance of a refcounted class > that's semi-intentionally (albeit carefully) declared on the stack: > gfxContext, per https://

Re: OS.File design issue from bug 961080 (making downloads respect umask)

On Sun, Apr 27, 2014 at 7:25 PM, Dave Hylands wrote: > You stat downloading the file to the temp location. > Once the user selects the final location, you open the file in the final > location and start copying the file from the temp location to the final > location. > Eventually, your copy shou

Re: Recommendations on source control and code review

On Mon, Apr 14, 2014 at 5:01 AM, Karl Tomlinson wrote: > Very often I've found that the intended approach changes during the > life of a bug, and there is no clear summary in the bug of what > eventually was done. It is then necessary to go back through > multiple revisions of the patch and assoc

Re: Policy for disabling tests which run on TBPL

On Tue, Apr 8, 2014 at 2:41 AM, Ehsan Akhgari wrote: > What you're saying above is true *if* someone investigates the intermittent > test failure and determines that the bug is not important. But in my > experience, that's not what happens at all. I think many people treat > intermittent test fa

Re: Policy for disabling tests which run on TBPL

On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek wrote: > If a bug is causing a test to fail intermittently, then that test loses > value. It still has some value in that it can catch regressions that > cause it to fail permanently, but we would not be able to catch a > regression that causes it to

Re: Policy for disabling tests which run on TBPL

On Mon, Apr 7, 2014 at 3:20 PM, Andrew Halberstadt wrote: > I would guess the former is true in most cases. But at least there we have a > *chance* at tracking down and fixing the failure, even if it takes awhile > before it becomes annoying enough to prioritize. If we made it so > intermittents n

Re: Policy for disabling tests which run on TBPL

On Mon, Apr 7, 2014 at 6:33 AM, Andrew Halberstadt wrote: > Many of our test runners have that ability. But doing this implies that > intermittents are always the fault of the test. We'd be missing whole > classes of regressions (notably race conditions). We already are, because we already will s

Re: Policy for disabling tests which run on TBPL

On Sat, Apr 5, 2014 at 12:00 AM, Ehsan Akhgari wrote: > Note that is only accurate to a certain point. There are other things which > we can do to guesswork our way out of the situation for Autoland, but of > course they're resource/time intensive (basically running orange tests over > and over a

Re: Enable -Wswitch-enum? [was Re: MOZ_ASSUME_UNREACHABLE is being misused]

On Tue, Apr 1, 2014 at 5:56 PM, Zack Weinberg wrote: > The downside of turning this on would be that any switch statements > that *deliberately* include only a subset of the enumerators, plus a > default case, would now have to be expanded to cover all the > enumerators. If there are few enough t

Re: Pushes to Backouts on Mozilla Inbound

On Fri, Nov 8, 2013 at 2:01 AM, L. David Baron wrote: > I think this depends on what you mean by "known intermittent > failures". If a known intermittent failure is the result of any > regression that leads to a previously-passing test failing > intermittently, I'd be pretty uncomfortable with th

Re: Pushes to Backouts on Mozilla Inbound

On Wed, Nov 6, 2013 at 5:49 PM, Ryan VanderMeulen wrote: > What do we gain by having results that can't be trusted? The same that we gain from allowing any try pushes that don't run every single test. It's a tradeoff between reliability and time, not black-and-white. For instance, if I change a

Re: Pushes to Backouts on Mozilla Inbound

Has anyone considered allowing try pushes to run only specified directories of tests, and to allow incremental builds rather than clobbers on try? This would make try a heck of lot faster and resource-efficient, for those who are willing to accept less certain results. On Wed, Nov 6, 2013 at 12:5

Re: How to check if an element is visible...

On Tue, Sep 17, 2013 at 12:30 PM, Gijs Kruitbosch wrote: > On 17/09/13 11:18 , Neil wrote: >> >> Gavin Sharp wrote: >> >> Probably the conceptually simplest solution is to get the bounding >> client rect of the found range. > > Won't that be non-zero for visibility:hidden content? Should be, as w

Re: How to check if an element is visible...

On Mon, Sep 16, 2013 at 3:24 PM, Gavin Sharp wrote: > The find bar wants to avoid finding "hidden" text, AIUI (see bug > 257061). Some false positives would certainly be OK. The findbar C++ > code already does something not-quite-perfect and we've lived with > that for a while, so from my perspect

Re: How to check if an element is visible...

On Mon, Sep 16, 2013 at 1:07 PM, Mike de Boer wrote: > * Is a node visible, with all CSS styling taken into account that might cause > an element to not be visible, including parent nodes that might obscure it? > > In other words, when a node is painted on the canvas by the gfx layer, > partiall

Re: Detection of unlabeled UTF-8

On Fri, Aug 30, 2013 at 1:03 PM, Henri Sivonen wrote: > This is true if you run the heuristic over the entire byte stream. > Unfortunately, since we support incremental loading of HTML (and will > have to continue to do so), we don't have the entire byte stream > available at the time when we nee

Re: On builds getting slower

On Sat, Aug 3, 2013 at 6:36 AM, Nicholas Nethercote wrote: > Gregory suggested that headers aren't something that the build config > group can tackle, and I agree. Modifying #include statements en masse > is much easier if you have some familiarity with the code. You need a > sense of which head

Re: Intent to implement: NavigationController

On Fri, Jul 26, 2013 at 8:29 PM, Ehsan Akhgari wrote: > We're planning to implement a prototype of the NavigationController > interface (see bug 898524). We will try to get feedback from web > developers on the prototype and will use that feedback to change the spec > and the implementation and i

Re: Using C++0x auto

On Mon, Jul 22, 2013 at 10:01 PM, Rob Arnold 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(nsRefPtr(new T)) and Bad Things would happen; > there are less obv

Re: Proposed policy change: reusability of tests by other browsers

On Sun, Nov 11, 2012 at 4:21 PM, Neil wrote: > Why not simply verify that the list of actual fails equals the list of > expected fails, and report items that are only in one of the two lists? That would be a bit more robust, yes, and it should be doable without much work. It still wouldn't detec

Re: Proposed policy change: reusability of tests by other browsers

On Sat, Nov 10, 2012 at 9:41 AM, Boris Zbarsky wrote: > I believe right now we have a list of "known failures" alongside such tests, > and our own test harness knows to compare what the tests are reporting to > our list of known failures. As in, we're not using the pass/fail state of > the tests

Re: Proposed policy change: reusability of tests by other browsers

On Wed, Nov 7, 2012 at 4:13 PM, James Graham wrote: > There is an experimental branch with this mode in; it isn't production > quality yet. I am still unsure that it's a good idea; in particular I think > it encourages people to write multiple tests on the same page in such a way > that if one fai

Re: nsresult is now a strongly typed enum

On Mon, Oct 15, 2012 at 2:09 PM, Ted Mielczarek wrote: > On Sat, Oct 13, 2012 at 12:48 PM, Ehsan Akhgari > wrote: >> This is currently enabled on all compilers which support strongly typed >> enums (recent clang, gcc >= 4.4, and Visual C++ 2012). > > So this is all of our official builds except

Re: Proposed policy change: reusability of tests by other browsers

On Wed, Oct 10, 2012 at 12:46 AM, Jonas Sicking wrote: > However, for someone working against a looming deadline, the cost of > writing sharable tests and risk missing the deadline can be much > higher than having those tests not be run by other browser vendors. Which is why we have rolling relea

  1   2   >