Re: Getting rid of already_AddRefed?

On 12/23/14 1:03 PM, Jeff Walden wrote: And concerning the binary compatibility argument -- which I don't think really matters any more Oh, I wish you were right. Things like bug 1078674 suggest that you're wrong, however. We have random binary code we don't control calling into our code, s

Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests

On 12/18/14, 2:28 PM, Nils Ohlmeier wrote: Well there is an event listener waiting for the event to fire. But how else then through a timeout, obviously with a high timeout value like 30 or 60 seconds We've had quite a number of random oranges from precisely this scenario. It seems that it's

Re: Intent to implement and ship: document.origin

On 12/3/14, 6:30 AM, Anne van Kesteren wrote: Correct. I thought that was added a long time ago. location.origin has existed in Firefox since Firefox 21, I guess (and Firefox 29 for Workers). I guess that does make it hard to remove. That sucks. :( Anyway, the difference between a docume

Re: Intent to implement and ship: document.origin

On 12/3/14, 2:28 AM, Jonas Sicking wrote: This difference seems really esoteric to me. Do we really expect developers to understand this difference and use the right one? Especially given the very similar names? I don't. Hence my proposal to remove location.origin. Are there use cases for bo

Re: Intent to implement and ship: document.origin

On 12/2/14, 8:17 AM, Kevin Grandon wrote: We currently use location.origin quite frequently in gaia, and we also use it in workers. So the difference between location.origin and document.origin is that the latter is the origin of the document and the former is the origin of the document's UR

Intent to implement and ship: document.origin

Summary: document.origin returns the Unicode serialization of the document's origin. The returned value does not depend on what document.domain was set to. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=931884 Spec: http://dom.spec.whatwg.org/#dom-document-origin Platform coverage: All of

Re: Components.returnCode not working as expected.

On 11/24/14, 4:40 AM, Philipp Kewisch wrote: Personally I'd prefer if the JS component could just throw and not have to use Components.returnCode at all, isn't there a way the caller can catch the exception without it being logged? There is. The question is _when_ it should do this. Consider

Re: What's the difference do_CreateInstance do_GetService

On 11/21/14, 1:17 AM, Yonggang Luo wrote: I am looking for docs about this do_CreateInstance returns a new object every time. do_GetService creates one object and caches it, then keeps returning the cached object. In practice, for any given class you'd only use one or the other, depending

Re: [RFC] We deserve better than runtime warnings

On 11/20/14, 11:51 AM, David Rajchenbach-Teller wrote: I wasn't aware that we could whitelist an individual NS_ASSERTION. How do we do that? Ah, we can't. We can whitelist the number of assertions in a mochitest (or a number range if the number is not quite stable), but not the text of the a

Re: [RFC] We deserve better than runtime warnings

On 11/20/14, 10:38 AM, David Rajchenbach-Teller wrote: I have put together an API that could replace runtime warnings with something much more actionable, and much less noisy. They key aspects are that: - when the code is executed as part of the test suite, it causes test failures; - individual t

Re: MozReview ready for general use

On 11/10/14, 12:14 PM, Gregory Szorc wrote: I think if we land support for specifying the base revision to review (currently it takes all non-public changesets up to the revision you specify or . if none), that will be a sufficient stop-gap until proper multi-bug support is implemented. Yes, ag

Re: MozReview ready for general use

On 11/9/14, 11:10 PM, Gregory Szorc wrote: We currently only attempt to map each review/commit series to a single bug. This is definitely a problem; it serializes workflow such that you have to get review on bug 1 and land it before you can even request review on bug 2 that depends on bug 1,

Re: Screen Capture

On 10/24/14, 3:48 AM, Anne van Kesteren wrote: Then if a known-bad thing was found, such as a plugin, native form control, or non-CORS cross-origin image, Or link, right? Otherwise you leak :visited state. -Boris ___ dev-platform mailing list dev-pl

Re: treating B2G device tests as tier 1

On 10/16/14, 4:01 PM, Ehsan Akhgari wrote: Sure. But you're just describing why tests are useful and an absolute necessity. :-) I think what Bobby was asking for is a much stronger ask that is not really attainable. I think what Bobby was actually asking for is this: If a patch lands and is

Re: Moratorium on new XUL features

On 10/16/14, 5:30 AM, Neil wrote: Out of interest, what does it do that complicates layout? You mentioned the box model of course, but what else is there? There's a bunch of listbox-related frame constructor complexity (and for a while it was a quite lively source of security bugs, too). But

Re: Moratorium on new XUL features

On 10/15/14, 9:03 AM, Boris Zbarsky wrote: The situation is that we have a bunch of unmaintained code that complicates layout. I feel like I should expand on this. "XUL" covers a variety of somewhat-unrelated features, including at least: 1) The XUL box model. 2) The built-in XU

Re: Moratorium on new XUL features

On 10/15/14, 5:01 AM, glazou wrote: w/o even trying to discuss with them the situation, the possibilities, the alternatives, the ETA, the transition plan. The situation is that we have a bunch of unmaintained code that complicates layout. And layout needs no extra complications; it has enoug

Re: Moratorium on new XUL features

On 10/15/14, 3:40 AM, glazou wrote: Guys, you understand there is an ecosystem - even if it is a small one - of companies relying on XUL for their businesses? Yes, including Mozilla, via Firefox. 1. does Mozilla still care about us? I can't answer this question. On a personal level, I car

Re: W3C Proposed Recommendation: HTML5

On 10/14/14, 1:29 AM, L. David Baron wrote: (2) While it would be helpful to have the recommendation contain The "While" seems extraneous. The rest looks great! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozill

Re: Moratorium on new XUL features

On 10/13/14, 11:28 PM, Yonggang Luo wrote: If the XUL is truly dead, then mozilla community should consider to remove it totally from the codebase Working on it. It's a big project. ;) -Boris ___ dev-platform mailing list dev-platform@lists.mozill

Re: Incorrect line number reported by JS engine for warnings?

On 10/12/14, 9:54 PM, ISHIKAWA, Chiaki wrote: > In this bugzilla, line 693 is actually out of range for the file reported. > The file is much shorter. Is it? The error is in nsContextMenu.js but your comments in the bug are about mailContextMenus.js, which is not at all the same thing. > Worse,

Re: JavaScript (strict) Warning from FF mochitest-plain test.

On 10/2/14, 4:53 PM, Jeff Gilbert wrote: If you want to guarantee it, don't warn, assert. Note that mochitest-plain tests will go orange on unexpected uncaught exceptions. Not least because we added that pretty early on in their evolution. We're nowhere close to doing that with mochitest-c

Re: PSA: Array.prototype.contains is going away again

On 10/2/14, 4:06 AM, Philip Chee wrote: Can we not reach out to the MooTools people and work together unbreak the web? Already done. Now you just have to get the several million sites using old MooTools versions to update. -Boris ___ dev-platform

Re: W3C Proposed Recommendation: HTML5

On 9/22/14, 1:18 PM, James Graham wrote: I think you'd get a better result by asking for agreement from all the relevant implementors that they felt that the spec was implementable. The problem was that in some cases this was more a less a non-goal (in some cases an anti-goal) for the spec edi

Re: W3C Proposed Recommendation: HTML5

On 9/21/14, 9:00 AM, James Graham wrote: I am substantially less convinced that tying these tests to the spec lifecycle makes sense. Agreed. The only reason it's an issue for me is the lack of errata-issuance by the W3C and hence the tendency to attempt to enshrine obviously-wrong things in

Re: W3C Proposed Recommendation: HTML5

On 9/20/14, 6:29 PM, Karl Dubost wrote: "This published recommendation has switched to a non maintenance mode. It may contain mistakes or things may have changed since the publication. Please make sure to check the most up to date document BLAH [with link to the whatw

Re: W3C Proposed Recommendation: HTML5

On 9/20/14, 5:41 AM, Karl Dubost wrote: Is the whatwg spec interoperable? No. Will it ever be? That's the goal. Whether we manage to get there, we'll see. So Boris said incomplete test suite. That's one comment. Note that I didn't say we should bring the comment back to the AC, since

Re: W3C Proposed Recommendation: HTML5

On 9/20/14, 5:03 AM, Karl Dubost wrote: The biggest issue I have with this is exiting CR without anything resembling a comprehensive enough test suite * What is a comprehensive enough test suite? Ideally, one that has a test for every normative requirement in the specification. This means

Re: W3C Proposed Recommendation: HTML5

On 9/19/14, 8:23 PM, L. David Baron wrote: W3C recently published the following proposed recommendation (the stage before W3C's final stage, Recommendation): The biggest issue I have with this is exiting CR without anything resembling a comprehensive enough test suite to ensure anything like

Re: [PresentationAPI] Intend to implement

On 9/9/14, 2:57 AM, Kilik kuo wrote: Boris Zbarsky於 2014年9月8日星期一UTC+8下午11時51分04秒寫道： boolean available; This needs a default value. I'm not quite sure about this, I am. ;) Since it's an optional argument for AvailableChangeEvent. Right, and the question is: what is th

Re: [PresentationAPI] Intend to implement

dictionary AvailableChangeEventInit : EventInit { boolean available; This needs a default value. interface SocketChannelWithATwist { // temporary name Should this inherit from EventTarget? Seems like it, given the EventHandler attributes it has. Or does it not trigger those via dispat

Re: web-platform-tests now running in automation

On 9/7/14, 10:21 AM, James Graham wrote: There isn't anything at the moment, but it seems like a good idea to invent something. The easiest thing would be a new key-value pair like expected-reason: Some reason string Do you have a preferred syntax here? Nope. Pretty much anything works for m

Re: web-platform-tests now running in automation

On 9/5/14, 11:55 AM, James Graham wrote: Instructions for performing the updates are in the README file [2]. There is tooling available to help in the update process. Is there a way to document the spec or test suite bugs in the expectations file? e.g. if I want to add an "expected: FAIL" and

Re: web-platform-tests now running in automation

On 9/5/14, 11:55 AM, James Graham wrote: The web-platform-tests testsuite has just landed on Mozilla-Central. This is fantastic. Thank you! Does this obsolete our existing "imptests" tests, or is this a set of tests disjoint from those? -Boris __

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

On 9/4/14, 12:51 AM, Joshua Cranmer 🐧 wrote: It sounds to me like what you really want is support for a red squiggly line in your IDE Not quite, because red squiggly lines don't catch weird C++ namespacing rules, lack of conversion operators that should be present, etc... -Boris

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

On 9/4/14, 12:26 AM, Nicholas Nethercote wrote: But in lieu of sub-file dependency tracking you'll take manual overrides that emulate them by doing partial builds, relying on your knowledge of the codebase to know that those partial builds are safe. This is a point worth clarifying. I'm not tr

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

On 9/3/14, 10:10 PM, Mike Hommey wrote: Please file a bug with a timestamped log. Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1062668 And thank you! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.or

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

On 9/3/14, 6:53 PM, Nicholas Nethercote wrote: |mach build binaries| suffices most of the time It really doesn't for the use case of not building the world when you change a header and want to just rebuild the files that use the changed part of the header... I should also note that a comple

Re: Upcoming changes to Mac package layout, signing

On 8/12/14, 1:05 PM, Ben Hearsum wrote: Without any changes, future versions of Firefox will cease to function out-of-the-box on OS X 10.9.5 and 10.10. Will it still be possible to run old nightlies, presumably by changing something in system settings? -Boris ___

Re: Upcoming changes to Mac package layout, signing

On 8/27/14, 8:16 PM, Boris Zbarsky wrote: On 8/12/14, 1:05 PM, Ben Hearsum wrote: Without any changes, future versions of Firefox will cease to function out-of-the-box on OS X 10.9.5 and 10.10. Will it still be possible to run old nightlies, presumably by changing something in system settings

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

On 8/27/14, 5:05 PM, Ehsan Akhgari wrote: Right, but that should now be fixed right? Hmm. Yes, it looks like this got fixed in the last few days. Excellent! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.o

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

On 8/27/14, 1:46 PM, Ehsan Akhgari wrote: Ah, that's pretty weird. I would consider that a build system bug. ../mach build content/media/webaudio/compiledtest for example does the right thing. Well. The codegen runs in dom/bindings, not dom/bindings test. So if I do mach build dom/binding

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

On 8/27/14, 1:28 PM, Ehsan Akhgari wrote: Do you mean something beyond: $ ninja -t dom/bindings/test I have no idea what that command line does, but note that "mach build dom/bindings/test" doesn't compile the binding tests, or even regenerate the test files. I _really_ wish it did. -Bori

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

On 8/27/14, 12:29 PM, Steve Fink wrote: Enumerating some of them: Let me add one: 6. I touched a file or files. Rebuild only the compiled-code tests that test this stuff. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https:

Re: How to implement XPCOM API void render(in long width, in long height, out nsIImageLoadingContent imageContent); in Javascript?

On 8/22/14, 5:34 AM, David Rajchenbach-Teller wrote: If I recall correctly, this is implemented as an object with a field `out` – I'm not 100% sure of the name of the field, though, so you might need to experiment. The field name is "value". I should note that searching the web for "xpcom out

Re: nsIDocument::GetDocShell is not present in any Gecko 31/Windows .lib files

On 8/19/14, 2:52 PM, Look, Yuriy wrote: I am building my code against Gecko 31 for Windows and a public C++ method nsIDocument::GetDocShell defined in include\nsIDocument.h on line 1188 does not get resolved by Visual Studio 2010 linker. This is a non-virtual non-inline method, with default (

Intent to implement and ship: Element.matches

Summary: This is an unprefixed form of Element.mozMatchesSelector, which we've been shipping for a long time. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=886308 Link to standard: http://dom.spec.whatwg.org/#dom-element-matches (though note

Promise syntax in .webidl files now requires the resolution type

As of today, any Web IDL using Promise needs to specify the type the promise will be resolved with. For example, an API that used to be written like this: Promise getLength(); would now be written like this: Promise getLength(); If you don't put in the type, you will get invalid syntax e

Re: Intent to Transition from TBPL to Treeherder

On 7/23/14, 8:39 AM, Ed Morley wrote: That said, jmathies is also hitting this - I've CCed you on bug 1042627 - let's discuss there Done. 2) It seems to use a narrower space than tbpl for the patch descriptions; at my window width and font size I don't even see the entire bug number for most

Re: Intent to Transition from TBPL to Treeherder

On 7/23/14, 5:07 AM, Neil wrote: I think the arrow to the right of the revision is supposed to achieve this. I'm not sure what the point of the link itself is, or where it's documented. Ah, I see, yes. There is a clear indicator, but it's not obvious. (It's to the left of the tree name.) Ag

Re: Intent to Transition from TBPL to Treeherder

On 7/22/14, 9:01 PM, Jonathan Eads wrote: You can kick the tires here: https://treeherder.mozilla.org This looks pretty neat! I do have a few questions/comments: 1) It's trying to run Flash. Will it work correctly if I just don't let it do that? I haven't found anything broken so far even

Re: How to setting border-radius for window without the default style.

On 7/21/14, 9:50 PM, Yonggang Luo wrote: I am not so sure I understand correctly, is that the answer is there is no solution, the only accept way is using a transparent background? If you want the background clipped to the rounded border, and the rounded border to be on the root, then you can

Re: How to setting border-radius for window without the default style.

On 7/21/14, 9:35 AM, Markus Stange wrote: Oops, I was forgetting about borders. border-radius works for getting rounded borders on root elements, but it does not work for clipping backgrounds to a rounded rect. Right, because of background propagation to the viewport. The spec calls this out

Re: How to setting border-radius for window without the default style.

On 7/21/14, 8:36 AM, Markus Stange wrote: On 21.07.14 13:33, Yonggang Luo wrote: I am trying to remove the default style for tag but failed to setting the radius. Setting a border radius on the root element is not supported. In XUL, right? Works fine in HTML. -Boris __

Re: Standardizing request contexts

On 7/1/14, 10:54 AM, Anne van Kesteren wrote: Good question. From what I remember the main motivation was having something distinct from navigating the top-level browsing context. A service worker might want to know whether it's "app" top-level browsing context is being navigated or whether it's

Re: Standardizing request contexts

On 7/1/14, 6:06 AM, Anne van Kesteren wrote: Hi Doug, Patrick, Boris, ccing Jonas, since he's been thinking about this a lot recently. https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentPolicy suggests we have somewhat less granularity than Chromium / th

Re: JS assertions that get optimized away!

On 6/27/14, 11:55 AM, Fitzgerald, Nick wrote: I don't know if it is optimized by SpiderMonkey as well, but in the debugger we have |exports.dbg_assert =function dbg_assert(cond, e) {| This requires evaluation of "cond" and "e" on the caller side, unfortunately. That can't be optimized away.

Re: Intent to implement: CSS Font Loading API

On 6/24/14, 2:59 AM, Cameron McCormack wrote: Yes hence the "something similar". :-) Was just easiest for working with while implementing. Making the object iterable seems like the right thing to do, but our bindings generation scripts don't handle "iterator" in IDL yet. That's at least in pa

Re: Code coverage [was: Re: Javascript code coverage ?]

On 6/20/14, 8:00 AM, Joshua Cranmer 🐧 wrote: (there is 0% coverage of angle). That's not surprising given that the code coverage test is being done on Linux, is it? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.

Re: Standardized assertion methods

On 6/6/14, 8:42 PM, Jonas Sicking wrote: I definitely understand that it'll be a pain to convert existing tests that rely on the relaxed matching. Yes. We have about 3300 failing test assertions with is() using ===, and the vast majority are string-vs-number. All I'm saying is that we could

Re: Standardized assertion methods

On 6/6/14, 3:19 PM, Ehsan Akhgari wrote: Can we make is() do those checks explicitly and if neither of these cases apply, fall back to a non-strict equality check? Yes. As in, we could make it special-case the number-to-string compare and use == for that, and use === for everything else. -B

Re: Standardized assertion methods

On 6/6/14, 12:21 PM, Boris Zbarsky wrote: That will be the big question, yes. 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 ton

Re: DOMWindowCreated not fired for some frames

On 6/6/14, 12:42 PM, Matthew Gertner wrote: On Friday, June 6, 2014 6:33:27 PM UTC+2, Boris Zbarsky wrote: The about:blank document is quite real, sadly... From what I'm seeing, the document object that ends up there (window.document) is not the same one as when DOMWindowCreated is

Re: DOMWindowCreated not fired for some frames

On 6/6/14, 11:55 AM, Matthew Gertner wrote: So what's the best way to hook into the window so I am notified when the real document is created? The about:blank document is quite real, sadly... I'm not seeing anything obvious that gets fired when we reuse an inner for a new document. At least

Re: Standardized assertion methods

On 6/6/14, 12:21 PM, Boris Zbarsky wrote: Yeah, I've been dealing a lot with edge cases of DOM APIs for the last year or two Case in point. I got some try results, and here's one of the failures: 748 INFO TEST-UNEXPECTED-FAIL | /tests/dom/indexedDB/test/test_multientry.html |

Re: Standardized assertion methods

On 6/6/14, 11:04 AM, Gijs Kruitbosch wrote: I'm interested in the API exposure case (bug link please? :-) I'd have to search, sorry. :( I would have assumed that you would test that kind of thing by checking if the relevant API property is enumerable from the object, rather than checking for

Intent to unship: javascript: execution outside navigation contexts

Currently we support things like , as well as and @import(url("javascript:stuff")). What these do is run the script in a sandbox and then if it returns a value other than undefined treat that value as data for the load. I believe at this point we're the only UA that does this, and it causes

Re: Standardized assertion methods

On 6/6/14, 7:12 AM, Gijs Kruitbosch wrote: No, I think that in 99.99% of cases, I don't care about the type, and therefore I would normally use is() and not care that it's using non-strict equality. I think the case where there is (a) a possibility that I could get '5' instead of 5 when code is m

Re: DOMWindowCreated not fired for some frames

On 6/6/14, 10:00 AM, Matthew Gertner wrote: Is this a Firefox bug or somehow by design? It's by design: when you ask for a window and we haven't actually created one yet (because this is a new subframe that's doing its initial load, say), we have to go ahead and create an about:blank one to r

Re: Overriding the CSP for privileged protocols

On 6/5/14, 11:39 AM, Matthew Gertner wrote: Our extension injects styles into webpages via a protocol defined using our own protocol handler using . We have our own nsIContentPolicy which we use to enforce which resources from this protocol can be injected into content pages. The problem is th

Re: Standardized assertion methods

On 6/4/14, 11:30 PM, Gavin Sharp wrote: - benefits to shared API/implementation seem uncontroversial Agreed. - specifically, consistency between mochitest/SimpleTest-based harnesses (mochitest-plain/mochitest-chrome/mochitest-browser) and xpcshell tests is what we care about primarily. I don'

Re: Standardized assertion methods

On 6/4/14, 2:21 PM, James Graham wrote: * They encourage the use of deepEqual which has underdefined semantics, particularly in the case of objects that contain cycles (it looks like Assert.jsm goes into an infinite loop in this case, but I may have misread the code). You didn't misread the cod

Re: Standardized assertion methods

On 6/4/14, 1:56 PM, Ted Mielczarek wrote: The inconsistency between our various test harnesses makes it harder than necessary to write different types of tests. Yes, agreed. RE: the discussion of testharness.js etc, I think those are even farther afield, since the testing model there is much

Re: Standardized assertion methods

On 6/4/14, 1:42 PM, Mike de Boer wrote: I wasn’t implying that they’re broken at all, it’s just that James was hinting at that. Our existing testing frameworks are broken in terms of the goals of the testharness framework, as far as I understand. For example, one of the primary goals of tes

Re: Standardized assertion methods

On 6/3/14, 3:57 PM, Ehsan Akhgari wrote: Nobody is opposing a proposal where someone volunteered to create the rewriting facilities you're mentioning and using them to fix the entire code base in one go. I somewhat am. -Boris ___ dev-platform mailin

Re: Standardized assertion methods

On 6/3/14, 3:31 PM, Boris Zbarsky wrote: Maybe that's a personal failing of mine, but I suspect not. More precisely, I expect it's a personal failing that is widespread, not just my personal little quirk. -Boris ___ dev-platform mailin

Re: Standardized assertion methods

On 6/3/14, 2:36 PM, Gregory Szorc wrote: There is a clear win in the ability to reuse, understand, and modify the common code. No one is arguing against having common harness code as far as I can see. I can't even recall which file(s) contain is/ok from mochitest SimpleTest.js. Which also

Re: Standardized assertion methods

On 6/3/14, 1:49 PM, Gavin Sharp wrote: I suspected this is where we'd end up :) "Reasonability" is just as subjective as aesthetics. Of cours. I really have a hard time accepting at face value the argument "Assert.notEqual (or other shorter variants) is unreasonably long to type/paste repeate

Re: Standardized assertion methods

On 6/3/14, 11:17 AM, Joshua Cranmer 🐧 wrote: I'm used to xpcshell tests more than mochitests, and the biggest difference by far between xpcshell and mocha that I'm aware of is that mocha counts tests at finer granularity: xpcshell tests work on a file-by-file basis, whereas mocha tests work at th

Re: Standardized assertion methods

On 6/3/14, 11:19 AM, L. David Baron wrote: Locally I generally want to see all the failures, since seeing the complete set of failures is often a much better hint as to the cause of the failures than just seeing the first one. Yes, exactly. -Boris _

Re: Standardized assertion methods

On 6/3/14, 9:29 AM, Mike de Boer wrote: Nope, you got me there - I generalised too easily. This statement is based on personal experience, not science. I'm not looking for science, necessarily. I'm looking for an understanding of the problems we're trying to solve. My basic issue is that f

Re: Standardized assertion methods

On 6/3/14, 8:50 AM, Boris Zbarsky wrote: I do think we should be very intentional about adopting something new, both in terms of semantics (mochitest is() using == is a mistake we should not duplicate in the short-name comparison function in the new setup) y One other note. The checkin so far

Re: Standardized assertion methods

On 6/3/14, 6:22 AM, Mike de Boer wrote: Their lack of modularity costs us flexibility in adopting and/ or promoting TDD development. Mike, I'm very curious about this part. Do you have a link offhand to a more detailed explanation of the issues here? Note that none of us think Mochitest is

Re: Standardized assertion methods

On 6/3/14, 8:39 AM, Mike de Boer wrote: I think it helps provide a common, immediate understanding for new contributors who’d like to write test for the code they contribute, as the add-on SDK and the NodeJS community already use it exclusively. I think there's a bit of functional area bias h

Re: Standardized assertion methods

On 6/2/14, 9:44 PM, Boris Zbarsky wrote: On 6/2/14, 7:26 PM, Martin Thomson wrote: Sounds like an area ripe for standardisation Note that standardizing several test suites on the same API might not work all that well when they have different goals and operating parameters Specifically

Re: Standardized assertion methods

On 6/2/14, 7:26 PM, Martin Thomson wrote: Sounds like an area ripe for standardisation Note that standardizing several test suites on the same API might not work all that well when they have different goals and operating parameters, because what can you end up with is an API that doesn't qui

Re: Standardized assertion methods

On 6/2/14, 5:33 PM, Gavin Sharp wrote: Do either of you have reasoning for that other than "it looks better to me"? My personal experience is that when I try to write xpcshell tests the amount of time it takes to type the test function names is very noticeable and actively interrupts my think

Re: Standardized assertion methods

On 6/2/14, 3:34 PM, Paolo Amadini wrote: It seems to me that if we don't have external compatibility needs, we might as well move mochitests to use a set of assertion methods that is the same as xpcshell and maybe other test suites. Yes, but imho we should be moving xpcshell in the direction of

Re: using namespace

On 5/20/14, 2:23 PM, Bobby Holley wrote: In XPConnect, we have "using namespace JS" everywhere. This is pretty important, because the JS rooting/handle API is very cumbersome to use otherwise. Note that if every file in a directory has the same "using namespace" declarations, then there is no

Re: OMTC on Windows

On 5/18/14, 2:23 PM, Gavin Sharp wrote: OMTC is important, and I'm excited to see it land on Windows, but the Firefox and Performance teams have just come off a months-long effort to make significant wins in TART, and the thought of taking a 20% regression (huge compared to some of the improvemen

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/13/14, 2:42 PM, Rik Cabanier wrote: Why would that be? Are you burning more CPU resources in servo to do the same thing? In some cases, possibly yes. If so, that sounds like a problem. It depends on what your goals are. Any sort of speculation, prefetch or prerender is burning more C

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

On 5/13/14, 7:47 AM, Benjamin Smedberg wrote: Seems there's general agreement. Please make this change to the style guide. Done. Added to https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#C.2FC.2B.2B_practices -Boris __

Adding a recommendation that one-argument constructors be explicit to the C++ style guide

Background: in C++, one-argument constructors are implicit. What this means is that given this class declaration: class Foo { public: Foo(int arg); passAFoo(const Foo& arg); }; This bit of C++: Foo foo(5); foo.passAFoo(10); will compile and construct a temporary Foo that it

Re: nsRefPtr vs RefPtr

On 5/11/14, 7:50 PM, Chris Pearce wrote: Should we be preferring mozilla::RefPtr in new code? Should we be replacing nsRefPtr with mozilla::RefPtr? I would err on "no" for both, given https://bugzilla.mozilla.org/show_bug.cgi?id=820257 -Boris ___

Re: Intent to implement: WebGL 2.0

On 5/7/14, 2:00 PM, Benoit Jacob wrote: The idea is that if getContext("webgl", {version : N}) returns non-null, then the resulting context is guaranteed to be WebGL version N, so that no other versioning mechanism is needed. Sure, but say some code calls getContext("webgl", { version: 1 }) and

Re: Intent to implement: WebGL 2.0

On 5/7/14, 9:20 AM, Ehsan Akhgari wrote: interface WebGL2RenderingContext : WebGLRenderingContext { // new methods go here }; partial interface HTMLCanvasElement { (CanvasRenderingContext2D or WebGLRenderingContext or WebGL2RenderingContext) getContext(DOMString id, optional any op

Re: Intent to implement: WebGL 2.0

On 5/7/14, 12:34 PM, Ehsan Akhgari wrote: Implementations are free to return a context that implements a higher version, should that be appropriate in the future, but never lower. As pointed out, this fails the explicit opt-in bit. There is also another problem here. If we go with this setup

Re: Intent to implement: WebGL 2.0

On 5/6/14, 12:53 PM, Benoit Jacob wrote: Ah, I see the confusion now. So the first reason why what you're suggesting wouldn't work for WebGL is that WebGL extension my add functionality without changing any IDL at all. Sure, but we're not talking about arbitrary WebGL extensions. We're talkin

Re: Intent to implement: WebGL 2.0

On 5/6/14, 12:25 PM, Benoit Jacob wrote: To what extent does what I wrote in my previous email, regarding interactions between different extensions, answer your question? I'm not sure it answers it at all. With the example approach you suggested above, one would have to specify extensions sep

Re: Intent to implement: WebGL 2.0

On 5/6/14, 12:03 PM, Benoit Jacob wrote: Indeed, the alternative to doing WebGL2 is to expose the same functionality as a collection of WebGL 1 extensions I think Anne's question, if I understood it right, is why this requires a new context ID. I assume the argument is that if you ask for th

<    3   4   5   6   7   8   9   10   11   >