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

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).

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 >

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

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,

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 >

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

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 >

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

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 <hsivo...@hsivonen.fi> wrote: > On Mon, Oct 31, 2016 at 3:01 PM, Aryeh Gregor <a...@aryeh.name> wrote: >> If the concern is fingerprinting, perhaps it could be exposed only to >> sites that the user is logged into (assu

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

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

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.

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 >

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

On Mon, Aug 15, 2016 at 3:55 PM, Aryeh Gregor <a...@aryeh.name> 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* retu

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

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

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

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

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.

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

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

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

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.

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

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

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

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

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

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: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

On Sun, Oct 11, 2015 at 2:09 PM, Aryeh Gregor <a...@aryeh.name> 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 o

Re: Use of 'auto'

On Sun, Aug 2, 2015 at 8:37 PM, Joshua Cranmer  pidgeo...@gmail.com 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

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

On Tue, Jul 7, 2015 at 6:10 PM, Michael Layzell mich...@thelayzells.com 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

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

On Fri, Jul 3, 2015 at 6:22 PM, Michael Layzell mich...@thelayzells.com 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.,

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

On Fri, Jul 3, 2015 at 3:56 PM, Neil n...@parkwaycc.co.uk 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 writing ArgFoo foo

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

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

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

On Wed, Jul 1, 2015 at 6:24 AM, Joshua Cranmer  pidgeo...@gmail.com 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

Re: Use of 'auto'

On Wed, Jun 3, 2015 at 12:14 AM, Joshua Cranmer  pidgeo...@gmail.com 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

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 tbsau...@tbsaunde.org 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

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 ehsan.akhg...@gmail.com 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

Re: Intent to deprecate: Insecure HTTP

On Tue, Apr 14, 2015 at 3:36 PM, Gervase Markham g...@mozilla.org 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

Re: Intent to deprecate: persistent permissions over HTTP

On Mon, Mar 16, 2015 at 3:24 PM, Eric Rescorla e...@rtfm.com 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

Re: Intent to deprecate: persistent permissions over HTTP

On Thu, Mar 12, 2015 at 3:56 PM, Adam Roach a...@mozilla.com 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

Re: Intent to deprecate: persistent permissions over HTTP

On Thu, Mar 12, 2015 at 9:42 PM, Boris Zbarsky bzbar...@mit.edu 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 a href=b.com target=_blank

Re: Intent to deprecate: persistent permissions over HTTP

On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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

Re: Intent to deprecate: persistent permissions over HTTP

On Tue, Mar 10, 2015 at 5:00 PM, Boris Zbarsky bzbar...@mit.edu 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

Re: Intent to deprecate: persistent permissions over HTTP

On Sat, Mar 7, 2015 at 10:33 PM, Eric Rescorla e...@rtfm.com 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

Re: Intent to deprecate: persistent permissions over HTTP

On Fri, Mar 6, 2015 at 7:27 PM, Anne van Kesteren ann...@annevk.nl 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

Re: HTTP/2 and User-Agent strings?

On Tue, Jan 27, 2015 at 11:31 PM, Chris Peterson cpeter...@mozilla.com 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

Re: Getting rid of already_AddRefed?

On Sat, Dec 27, 2014 at 12:34 AM, smaug sm...@welho.com 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

Re: Getting rid of already_AddRefed?

On Sat, Dec 27, 2014 at 5:54 AM, Karl Tomlinson mozn...@karlt.net 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/pointer pair as input

Re: Getting rid of already_AddRefed?

On Mon, Dec 22, 2014 at 11:10 PM, Jeff Muizelaar jmuizel...@mozilla.com 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

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

On Wed, Dec 3, 2014 at 11:54 PM, Seth Fowler s...@mozilla.com 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: 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 bba...@mozilla.com 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

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 ann...@annevk.nl 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

Re: web-platform-tests now running in automation

On Tue, Sep 9, 2014 at 3:44 PM, James Graham ja...@hoppipolla.co.uk 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

Re: web-platform-tests now running in automation

On Sun, Sep 7, 2014 at 5:49 PM, James Graham ja...@hoppipolla.co.uk 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.

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

On Mon, Aug 25, 2014 at 8:27 PM, Bill McCloskey wmcclos...@mozilla.com 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

Re: Getting rid of already_AddRefed?

On Thu, Aug 14, 2014 at 12:00 PM, Neil n...@parkwaycc.co.uk 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

Re: Getting rid of already_AddRefed?

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

Re: Getting rid of already_AddRefed?

On Wed, Aug 13, 2014 at 4:11 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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

Re: Getting rid of already_AddRefed?

On Wed, Aug 13, 2014 at 5:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 5:59 PM, Benjamin Smedberg benja...@smedbergs.us 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

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 6:14 PM, L. David Baron dba...@dbaron.org 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

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 6:16 PM, Benoit Jacob jacob.benoi...@gmail.com 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

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 6:25 PM, L. David Baron dba...@dbaron.org 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 just return

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron dba...@dbaron.org 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

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 7:12 PM, Vladimir Vukicevic vladi...@pobox.com 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

Re: Getting rid of already_AddRefed?

On Tue, Aug 12, 2014 at 7:37 PM, Benjamin Smedberg benja...@smedbergs.us 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

Re: Are StaticAuto/RefPtr good?

On Tue, Aug 5, 2014 at 1:09 AM, Mike Hommey m...@glandium.org 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

Re: Standardized assertion methods

On Fri, Jun 6, 2014 at 8:35 PM, Boris Zbarsky bzbar...@mit.edu wrote: https://tbpl.mozilla.org/?tree=Tryrev=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.

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 dholb...@mozilla.com 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:

Re: Recommendations on source control and code review

On Mon, Apr 14, 2014 at 5:01 AM, Karl Tomlinson mozn...@karlt.net 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

Re: Policy for disabling tests which run on TBPL

On Tue, Apr 8, 2014 at 2:41 AM, Ehsan Akhgari ehsan.akhg...@gmail.com 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

Re: Policy for disabling tests which run on TBPL

On Mon, Apr 7, 2014 at 6:33 AM, Andrew Halberstadt ahalberst...@mozilla.com 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,

Re: Policy for disabling tests which run on TBPL

On Mon, Apr 7, 2014 at 3:20 PM, Andrew Halberstadt ahalberst...@mozilla.com 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

Re: Policy for disabling tests which run on TBPL

On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek t...@mielczarek.org 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

Re: Policy for disabling tests which run on TBPL

On Sat, Apr 5, 2014 at 12:00 AM, Ehsan Akhgari ehsan.akhg...@gmail.com 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

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

On Tue, Apr 1, 2014 at 5:56 PM, Zack Weinberg za...@panix.com 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

Re: Pushes to Backouts on Mozilla Inbound

On Fri, Nov 8, 2013 at 2:01 AM, L. David Baron dba...@dbaron.org 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

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

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

On Tue, Sep 17, 2013 at 12:30 PM, Gijs Kruitbosch gijskruitbo...@gmail.com 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?

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

On Mon, Sep 16, 2013 at 1:07 PM, Mike de Boer mdeb...@mozilla.com 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

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

On Mon, Sep 16, 2013 at 3:24 PM, Gavin Sharp ga...@gavinsharp.com 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

Re: On builds getting slower

On Sat, Aug 3, 2013 at 6:36 AM, Nicholas Nethercote n.netherc...@gmail.com 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

Re: Intent to implement: NavigationController

On Fri, Jul 26, 2013 at 8:29 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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

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;

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

On Sun, Nov 11, 2012 at 4:21 PM, Neil n...@parkwaycc.co.uk 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

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

On Sat, Nov 10, 2012 at 9:41 AM, Boris Zbarsky bzbar...@mit.edu 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

Re: nsresult is now a strongly typed enum

On Mon, Oct 15, 2012 at 2:09 PM, Ted Mielczarek t...@mielczarek.org wrote: On Sat, Oct 13, 2012 at 12:48 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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

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

On Wed, Oct 10, 2012 at 12:46 AM, Jonas Sicking jo...@sicking.cc 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

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

On Sat, Oct 6, 2012 at 6:25 AM, Jonas Sicking jo...@sicking.cc wrote: In general, testharness.js seems to be more optimized for producing a result report which measure how close an implementation is to implementing a feature, than it is optimized for making it easy to write tests. I think

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

On Sat, Aug 18, 2012 at 12:38 AM, Justin Dolske dol...@mozilla.com wrote: Given the long history (shall I say plague?) of intermittent-orange in our tree, I can't agree that this would be a non-issue or is easy to fix! [Nor am I saying reusable tests are a bad idea -- just that it would seem

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

On Thu, Aug 16, 2012 at 6:10 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: 1. Is the current testharness.js API the documentation at the beginning of http://w3c-test.org/resources/testharness.js? If that is the case, the API looks a lot heavier weight than the default mochitest API we use.

Re: Increase in mozilla-inbound bustage due to people not using Try

On Thu, Aug 16, 2012 at 4:18 PM, Ben Hearsum bhear...@mozilla.com wrote: I don't think this would be any more than a one-time win until the disk fills up. At the start of each job we ensure there's enough space to do the current job. By moving the objdir away we'd avoiding doing any clean up

Re: Increase in mozilla-inbound bustage due to people not using Try

On Tue, Aug 14, 2012 at 10:47 PM, Gregory Szorc g...@mozilla.com wrote: Is there a tracking bug for areas where we could gain efficiency? We all know the build phase is full of clownshoes. But, I believe we also do silly things like execute some tests serially, only taking advantage of 1/N CPU

New MFBT features: enum underlying type and enum classes

Support just landed for two new C++11 features in MFBT: https://bugzilla.mozilla.org/show_bug.cgi?id=751554 They're described in this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf In brief, this lets you do two new things. One is you can use MOZ_ENUM_TYPE() to

Re: New MFBT features: enum underlying type and enum classes

On Thursday, August 9, 2012 3:05:56 PM UTC+3, Ted Mielczarek wrote: Did you mean VC++ 2010 or 2012? There's no version called 2011. (VC 2010 is VC 10.0, and VC 2012 is VC 11.0, confusingly.) I meant Visual Studio 11, based on this:

Re: Switching nsnull to nullptr

On Wednesday, July 25, 2012 12:45:52 PM UTC+3, Aryeh Gregor wrote: The C++11 standard defines a new dedicated null-pointer symbol, nullptr. It provides better type-safety than existing null-pointer definitions, because it doesn't allow implicit conversion to numeric types. In https

  1   2   >