Re: Gecko 17 as the base for B2G v1
On 8/2/12 1:44 AM, Andreas Gal wrote: Reporting of the results and integration is very lacking, and until those pieces fall into place (e.g. try integration), the developer experience is going to suck a lot if we enforce the rule below (backout). That's the concern, yes. Basically, if we're going to have the rules proposed at the level of testing we have now then the path of least resistance for me is probably to land nothing else for the rest of the 17 cycle because it almost certainly save me a bunch of time to do things that way... If we get to a point where we have decent try test coverage, it's a different story. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 8/16/12 12:07 PM, Ehsan Akhgari wrote: I agree with Benjamin here. In fact, I think if we take out item 4 completely Aryeh's proposal still makes sense. Where the tests live in our tree should not really matter. It matters insofar as it makes it more complicated to export our tests to the official W3C test suite, right? As long as we solve that problem in a locaton-agnostic way, we should be fine. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Attribute getter naming in WebIDL bindings
Right now, attribute getters always get prefixed with Get in the WebIDL bindings. So readonly attribute long foo becomes int32_t GetFoo() in the C++. Would it make sense to drop the Get in certain cases? In particular, in cases in which: 1) The getter is infallible. 2) The return value is not returned via an outparam. 3) The return value is not an interface type or is not nullable. So this IDL: readonly attribute long foo; readonly attribute Iface bar; readonly attribute Iface? baz; would become: int32_t Foo(); already_AddRefedIface Bar(); already_AddRefedIface GetBaz(); (with Iface* instead in cases when the getter is not an addreffing getter). Thoughts? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Attribute getter naming in WebIDL bindings
On 8/30/12 4:16 AM, Ms2ger wrote: It certainly looks nicer, but I'm not a big fan of complicating the rules for assembling the C++ signature from the WebIDL. XPIDL's consistency here, IMO, saves time when implementing an interface: you can focus on the actual implementation, rather than the binding code. One of the goals, honestly, is to have the xpidl getters look exactly like the C++ getters you'd have if you just wrote C++ getters (or for that matter like the ones you probably already have). That is, ideally WebIDL maps to the API you'd pick for your C++ class for C++ consumers anyway. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Attribute getter naming in WebIDL bindings
On 8/30/12 8:26 AM, Jonas Sicking wrote:
What would
readonly attribute long? bin;
compile into? If it compiles into something called GetBin then we'd
have a nice consistency that any getters for nullable types are named
GetX and any getters for non-nullable types are named X.
I was going to make it GetBin after thinking about it, yeah.
Specifically, it would be:
Nullableint32_t GetBin();
So my specific logic was going to be like so:
if (fallible || retval_nullable || retval_outparam) {
// prepend Get
}
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: What would be the right approach to hide scrollbars for one document?
On 9/25/12 7:54 AM, Paul Rouget wrote:
let win = gBrowser.contentWindow;
let gIOService =
Components.classes[@mozilla.org/network/io-service;1].getService(Components.interfaces.nsIIOService);
let windowUtils =
win.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils);
let uri = gIOService.newURI('data:text/css,@namespace
url(http://www.w3.org/1999/xhtml;);@namespace xul
url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul;);html xul|scrollbar
{display:none}', null, null);
windowUtils.loadSheet(uri, windowUtils.AGENT_SHEET);
But it doesn't appear to work.
Any idea?
This should work for non-root scrollbars.
The problem with the root scrollbars is that they're outside the root
element's primary frame. When you add a stylesheet, we post a restyle
event on the root element. When this is processed we restyle that
element and all its descendants. But as I said, the scrollbars are
actually _siblings_ of the root element, so don't get restyled.
We could try to change this on the Gecko side, but it might be simpler
(though making the operation slightly slower) for you to just force a
root frame reconstruct. Either remove and reinsert the documentElement
or set the relevant browser to display:none, flush, and then set it
back to its normal display value
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: NS_New$THING vs. new $THING
On 10/5/12 8:55 PM, Jonas Sicking wrote: With WebIDL you don't even need to use XPCOM interfaces to expose something to javascript! Indeed. As of a few days ago, you don't even need to inherit from nsISupports. ;) -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 10/9/12 6:46 PM, Jonas Sicking wrote: On Tue, Oct 9, 2012 at 2:43 AM, Aryeh Gregor a...@aryeh.name wrote: If it's a pain to write a particular file in testharness.js, it can be kept as mochitest. In my experience, quite a lot of tests boil down to like ten lines, which would take about three minutes more to write using testharness.js than mochitest. Also, a test that's based on testharness.js but uses some Gecko-only features would be easier to make portable later than a test that's based on mochitest and also uses Gecko-only features. This doesn't match my experience at all. My experience is that writing tests has a high cost and results in fairly complex test files. You're both right. Simple tests for really basic DOM stuff are very short. Tests for things like XHR and events and IndexedDB, which are a lot of what Jonas has had to write tests for are complete hell to write, if nothing else because of the async nature of those objects. We need a test harness that can handle both use cases without exploding. It's not quite clear to me that testharness.js is it, fwiw. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 10/10/12 12:23 AM, Ian Bicking wrote: Here's how I think you'd write a simple XHR test in both: // SimpleTest aka MochiTest req = new XMLHttpRequest(); req.open(GET, /example.json); How did example.json get there? What if you need to test CORS? With mochitest at this point you're doing some SJS work and whatnot. // testharness And here you have to go and do whatever is appropriate to your server setup. Which is not part of testharness. Which is why the CORS tests imported from Opera to the W3C ended up all broken, because they did not configure the server correctly. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Remove Linux PGO Testing
On 10/11/12 3:05 AM, Tim Taubert wrote: Also, I'm not sure how this affects Telemetry results. In terms of perf measurements we'd probably need to completely ignore everything from non-release builds as the results might differ heavily for some use cases. I'm not following. The suggestion, as far as I can tell, is to drop Linux PGO completely. We woudln't have it in nightly, Aurora, Beta, or releases. Compiling with PGO on Linux would be an unsupported configuration that we'd probably advise distros against, because it wouldn't be particularly well-tested. So the real question is whether PGO on Linux is worth it in general to us, again as far as I can tell. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: WOFF File Format 1.0
On 10/15/12 10:28 AM, alexander.alis...@gmail.com wrote: Any properly licensed TrueType/OpenType/Open Font Format file can be packaged in WOFF format for Web use. anybody else see problems here. No, explain? i think Mozilla's Jonathan Kew, needs to stick this where it does not shine But no matter what, this is unacceptable. If you can't be civil, please just don't say anything. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for reorganizing test directories
On 10/25/12 11:51 AM, Rob Campbell wrote: You won't have browser-chrome living next to xpcshell in the same location (pretty sure, please correct me if I'm wrong). http://mxr.mozilla.org/mozilla-central/source/docshell/test/ It's got xpcshell tests, xpcshell-ipc tests, browser tests, browser-chrome tests, mochitests. No reftests yet, but a bunch of the chrome tests and mochitests here do similar things using WindowSnapshot. This is not as isolated example as you might think. http://mxr.mozilla.org/mozilla-central/source/content/base/test/ has similar things going on, for example, and I'm sure I could find more. Granted, if we more finely subdivide our directory structure we would have fewer directories with a variety of test types. But it's not clear to me how beneficial such subdivision of source files is. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 11/9/12 8:11 PM, Benoit Jacob wrote: The only issue I see is using namespace at file scope in a _header file_. I would support a coding style rule against that. https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style#Namespaces says: No using statements are allowed in header files, except inside class definitions or functions. So whoever is putting using in header files is already breaking the rules... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 11/9/12 8:03 PM, Zack Weinberg wrote: I challenge your presuppositions. The average file should need no more than one or two `using SYMBOL;` lines per header it includes. That depends on the structure of the code, no? For example, until we finish moving over all of the DOM to live inside the mozilla::dom namespace, something like nsDocument would need to have a using for every single interface type used in the Document interface in IDL... I assure you there are more than two of those. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 11/9/12 12:52 AM, James Graham wrote: I know Mozilla use a system where all the tests in a file should pass, but I don't see how that will work well when you don't control the tests. If you are manually editing every file when you import it, I imagine that updating tests will be so time consuming that it will be tempting not to bother. How do you plan to address this? 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 directly; we're comparing it to should all pass, except this whitelist of things that we know fail. Constructing these whitelists of known failures is indeed a bit of a PITA, but they're pretty static until we fix stuff, usually. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: When nsGlobalWindow gets its principal?
On 11/21/12 9:50 AM, Honza Bambas wrote: The question is: where is a good place where nsGlobalWindow already knows its associated principal to trigger the preload? Outer window, or inner window? Also, do you need to know the exact principal, or just not system? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: abort listener not executed for XHR
On 11/22/12 3:48 AM, Jan Honza Odvarko wrote: I can create a simple extension, but it'll require having patch from bug 800799 applied. That's fine. I'm pretty good at applying patches. ;) Should I create a new bug report for this? Please! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Synchronous loading of data: URLs
On 12/11/12 7:18 AM, Henri Sivonen wrote: On Wed, Dec 5, 2012 at 5:37 AM, John Daggett moz.li...@windingwisteria.com wrote: Fonts are loaded when used so font loading won't start until the contents using a particular font are laid out. That seems like a problem for JS-driven display. It's also the only way to avoid loading tons of unnecessary font data that sites link to. Note also that the spec has ways of specifying different fonts for different Unicode character ranges, so you literally don't know which fonts you need until you know what characters you're trying to deal with... A big problem in the canvas case There are APIs being added to handle the canvas case, yeah. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++11 atomics in Mozilla
On 12/14/12 1:48 AM, Justin Lebar wrote: FWIW, I once tried changing all of our atomic string refcounting to non-atomic operations and could not eke out a performance (or stability) difference on x64. This was despite the fact that I was able to generate profiles where the atomic string refcounting showed up as taking a few percentage points. I think bz reproduced this somewhat surprising result more recently. What I found was that changing the refcounting on nsStringBuffer to not be atomic didn't obviously help. Neither did inlining those addref/release calls (they're out-of-line right now). But doing both together _did_ help a good bit, for my microbenchmark. Also x64 for that test. And _very_ microbenchmarky... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing writable [Replaceable] properties
On 12/20/12 12:14 PM, Jeff Walden wrote: Setting it creates a shadowing property on window itself, using the exact value passed in. // Current Gecko alert(typeof window.screenX); // number window.screenX = 123; alert(typeof window.screenX); // string, not number Er... no. If you do that, you get number for the second alert, because you did a qualified set. That's the whole complication with these properties: they behave differently for qualified and unqualified sets. // Proposed Gecko alert(typeof window.screenX); // number window.screenX = 123; alert(typeof window.screenX); // number (setter coerces string-number, or the setter silently did nothing) This is compatible with IE9 (standards or quirks mode -- and not in IE9 compat mode, and it seems not in older IE modes; I don't have IE10 to test) and Opera behaviors. IE9 puts the accessor on Window.prototype, and Opera puts it on window, but there's no visible difference in behavior for getting or setting. But there's still a supposed compatibility bugaboo to changing, because sites might have relied on the old behavior (notwithstanding that browsers are all over the map here) So specifically, for unqualified sets right now Gecko and WebKit reconfigure the property to a data property, as do older IE, but not newer IE or Opera, right? And the proposal here is to align with new IE and Opera? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing writable [Replaceable] properties
On 12/20/12 12:14 PM, Jeff Walden wrote: WebKit gives the old behavior, but only for some of the listed properties -- it doesn't for status or name. OK. Given that, I think we should just go ahead and make these non-replaceable. Given WebKit doesn't make status and name replaceable, the only place I'd expect possible compat problems is opener, and I think it should be ok even there. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Use of instanceof SomeDOMInterface in chrome and extensions
We have a bunch of chrome and extension code that does things like instanceof HTMLAnchorElement (and likewise with other DOM interfaces). The problem is that per WebIDL spec and general ECMAScript sanity this shouldn't work: instanceof goes up the proto chain looking for the thing on the right as a constructor, and chrome's HTMLAnchorElement is not on the proto chain of web page elements. The arguably right way to do the el instanceof HTMLAnchorElement test is: el instanceof el.ownerDocument.defaultView.HTMLAnchorElement Needless to say this sucks. For now we're violating the spec in a few ways and hacking things like the above to work, but that involves preserving the nsIDOMHTML* interfaces, which we'd like to get rid of to reduce memory usage and whatnot. So the question is how we should make the above work sanely. I've brought up the problem a few times on public-script-coord and whatnot, but there seems to not be much interest in solving it, so I think we should take the next step and propose a specific solution that we've already implemented. One option is to model this on the Array.isArray method ES has. We'd have to figure out how to name all the methods. Other ideas? No matter what we'd then need to migrate our chrome and extensions to the new setup, so I'd rather not change this more than once. Especially for extensions. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/27/12 1:54 PM, Neil wrote: More importantly it suggests 311 for the similar instanceof Components.interfaces.nsIDOMHTMLAnchorElement (or equivalent) often used in components and modules of course. Yeah. We'd obviously need to do something about that... Presumably there's no easy way to avoid the el instanceof el.ownerDocument.defaultView.HTMLAnchorElement from a component? Since a component has no HTMLAnchorElement hanging off the global, yeah... Presumably this involves completely removing all XPIDL DOM interfaces from HTML nodes, thus saving one vtable entry per node? There are cases in which we can remove nsIDOM* stuff without removing nsIDOMNode/Element/HTMLElement. Which is good, because removing those is a long-term project. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/27/12 2:49 PM, Justin Dolske wrote: Hmm. My first reaction is to gently challenge if this really has to change Well, it really has to change as exposed to web content (or we have to convince every single other browser to change behavior and get the ECMAScript spec changed and so forth). What happens with chrome is an interesting question we can discuss; that's what this thread is about. If really desired, we _could_ make our chrome interface objects behave differently from content ones and do weird instanceof magic. That would mean that some edge cases like Function.prototype.toString.call(HTMLAnchorElement) would do the wrong thing in chrome (specifically, throw instead of not throwing) and that you'd have to be very careful about what sort of window you were working with, but it's pretty doable. Alternately, we could do something where the proto chain of an Xray for a content object passes through the corresponding chrome prototypes, not through Xrays for the content window's prototypes. That would presumably make el instanceof el.ownerDocument.defaultView.HTMLAnchorElement return false and might have other issues. After all, if it's changing a frequently used chrome/addon pattern, that's a pretty big incompatibility step. And I'd sort of expect an HTMLAnchorElement to always be an HTMLAnchorElement, without the creator's context mattering... [1] Unfortunately, that's not how instanceof works in JS. Try it with Object instead of HTMLAnchorElement... One fairly easy (and mechanical?) option would be to add a global helper function. Something roughly along the lines of: var isIt = checkForDOMInterface(el, HTMLAnchorElement); Right. This would work for elements and for our chrome code. It doesn't help with the problem on the web, but maybe I should just give up on solving that as part of the work here. :( A bigger shift might be to change to using existing properties (.nodeName? .nodeType?) or add something new? localName and namespaceURI are the relevant things. And they're a bit of a pain to use, especially namespaceURI. And it's not quite clear to me how they'll end up interacting with web components. // Hello, I am chrome code adding an anchor to content var noob = document.createElement(a); gBrowser.contentDocument.body.appendChild(noob); // ...later, for an arbitrary node, possibly el === noob var isAnchor = el instanceof HTMLAnchorElement; Right now on m-c this sets isAnchor to true. If HTMLAnchorElement is switched to follow the spec, it will set isAnchor to false, because the implicit adoptNode during the appendChild changes the prototype chain in Gecko. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/28/12 4:12 AM, Neil wrote: In the interim I believe foo.constructor.name == Array was popular, but I see that doesn't work for (e.g.) new Image(). This should work (modulo bugs in exactly the cases where we've hacked the instanceof behavior) for WebIDL bindings, actually. We could also make it work for XPConnect DOM constructors Sadly, it's not much better than using .ownerDocument.defaultView on the RHS of instanceof in terms of typing and having to remember to do it. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/28/12 2:00 PM, Neil wrote: But if you're keeping nsIDOMNode, then you might as well keep the most popular interface that derives from it. Probably true, unless we decide we don't care _that_ much about editor perf and move it to a tearoff -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/29/12 11:19 AM, smaug wrote: And doesn't work for data documents which don't have defaultView Hrm... Yes. You mean something like Node.is(element, HTMLAnchorElement); ? Or HTMLAnchorElement.isHTMLAnchorElement(element) or HTMLAnchorElement.is(element) or something -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/30/12 10:34 PM, Andreas Gal wrote: In this sea of terrible choices, how about making HTMLAnchorElement an actual function, but having it return object for typeof? Apart from being an ES violation (which we're in the business of anyway, at the moment), what does that actually buy us? Right now, in my tree, HTMLAnchorElement is an object with a [[Call]], so typeof returns function and it has a JSClass that lets us override the behavior of instanceof. But if it were an actual function then we couldn't change how instanceof behaves (it would just look up the proto chain of the LHS for the value of HTMLAnchorElement.prototype), right? What do we get from making its typeof return object? Feel like I'm missing something, Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/30/12 11:14 PM, Bobby Holley wrote: 1) How do we want this to work going forward for chrome touching content? |obj instanceof Node| should return true. 2) How do we want this to work going forward for web pages touching other web pages? |obj instanceof Node| should return false until the standards community decides something to the contrary and specs it. OK. What do we do with b2g? I'm not quite sure whether the code in there I see using instanceof is running in chrome; most of b2g doesn't do that See (2). I'm in favor of Mozilla taking the back seat on this one - I'm happy to implement it if other vendors are pushing for it, but think we have bigger things to be pushing for ourselves. If we weren't running into this problem head-on ourselves, including in b2g, I wouldn't be worrying about it as much as I am, yeah. But we are. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/31/12 4:26 PM, Bobby Holley wrote: Well, if we're talking about JS-implemented WebAPIs, then that stuff should be running as chrome, potentially in the content process (unless I'm mistaken - I'm still a bit behind on all the b2g architecture). If we're talking about web apps, then they're supposed to be regular old web content, and we shouldn't do anything special for them in Gecko. Doing so undermines our position that these apps are open and portable. We're talking about the b2g UI. And I'm not talking theoretically; it's using instanceof on HTML elements right now. So either we change that code, or we make those instanceof checks work or something. I'd think the arguments should be based on improving the HTML5 developer experience Yes, of course. As I said, this has come up multiple times in the past, precisely on those grounds. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/31/12 8:25 PM, Boris Zbarsky wrote: They were, as roc points out, apathetic. Or rather, there was some talk about it being a good idea but no concrete proposals and nothing actually happening. That said, I posted one more time on public-script-coord (and bcced es-discuss) just to see if people bite this time. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Effects of JSM Compartments on Performance and Development Practices
On 1/20/13 4:01 PM, Joshua Cranmer wrote: If it were possible to have strings cross-compartments that don't require flattening and excessive copying, that would make the lives of add-on authors in a CPG world much easier. Please make sure bugs are filed? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Effects of JSM Compartments on Performance and Development Practices
On 1/20/13 2:37 PM, Gregory Szorc wrote: * Have all or most of chrome-privileged JS share the same compartment (like on B2G). It's my understanding the CPG decision was largely driven by content/security requirements and chrome just got caught up in it. What's not clear to me is whether this is a proposal to keep separate globals per JSM but have them all in one compartment or whether this is a proposal to have a single global for all JSMs, or all JSMs that opt into having this single global or something. The latter is much simpler to do. * Eliminate excessive copying and other perf issues associated with sending objects across compartments. This would be a good idea, yes. * Allow JSMs to be imported into specific named compartments. As might this be. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PHP to AngularJS - Permission Denied to access property
On 1/23/13 3:39 PM, edgar.am...@gmail.com wrote: also, the the angularJS app is in my localhost port 81, the php file is in my localhost, different port. Then they're not same-origin and can't call back and forth directly. I suggest using postMessage to send the data across. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 1/31/13 10:33 AM, Till Schneidereit wrote: Do we think the planned optimizations cause the gains through PGO to be less pronounced? It... depends. There are a few things at play here. First of all, our current profiling at least for DOM and layout stuff is largely looking for the wallet where the light is good, that is to say happening on Mac. Which happens to be the one desktop platform on which we don't do PGO. As a result, code micro-optimized based on those profiling results tends to inline a lot of things (in many cases forcing inlining via MOZ_ALWAYS_INLINE where the compiler wasn't otherwise doing it) and hope for the best. This works pretty well for microbenchmarks; how it works at scale is an interesting question that we don't have a great answer to yet because we don't have good things to measure. The flip side of that is that we've been a bit more resistant to the write the code and let PGO sort it out approach some have advocated, so turning off PGO won't be a total disaster for such code. Second, in any testcase that involves both jitcode and C++ code, turning off PGO will only affect the C++ code, of course. So to the extent that we speed up the C++ parts of the app relative to the jitcode, turning off PGO becomes less of a hit in testcases that involve both. Of course as we optimize the JIT the balance swings in the other direction. The real benefit of PGO is its ability to somewhat easily optimize the actual workload you care about instead of microbenchmarks For microbenchmarks proper we can always make them faster manually; the question is at what cost. If not, then slowdown in benchmarks and associated PR loss would be the same whenever we finally pulled the plug on PGO, right? Even if we posit the slowdown is the same, the PR loss is not. Say browser A takes time T to run a test, browser B takes time 1.2T and browser C takes time 0.8T. Say browsers B and C both suffer a 10% regression on that test. Now the times are: A: T, B: 1.32T, C: 0.88T From a PR point of view, the key part is that browser B is now 30% slower than A, but C is still 12% faster. So it's not clear to me that there would be any particularly bad PR for C at all. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 2/1/13 10:50 AM, Nathan Froyd wrote: Do you have examples that you can point to? This certainly used to be the case for Mozilla code at one point, but it may be worth remeasuring. Lots of gcc (and MSVC, and Mozilla code) changes since then. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The future of PGO on Windows
On 2/1/13 10:52 AM, Jean-Marc Desperrier wrote: The trouble with going 64-bits is that the jit would then see some significant regression, for cache pressure/instruction set related reasons Do you have numbers here? I'm aware of some regressions for things that involve traversing DOM trees in a microbenchmark with 64-bit builds, but not for the JIT per se. Well, apart from us having focused a bit more on 32-bit JIT perf than 64-bit JIT perf, I guess. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES
On 2/22/13 7:25 PM, bernhardr...@gmail.com wrote: const unsigned long LOAD_NOCOOKIES = 1 15; ... just stop sending / accepting cookies at this request 115 is LOAD_FRESH_CONNECTION, no? const unsigned long LOAD_NOAUTH = 1 16; ... don't add authentification headers automatically 116 is LOAD_DOCUMENT_URI. So at the very least you'll need different values for these constants. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
On 2/24/13 12:44 PM, matt...@salsitasoft.com wrote: Unfortunately I'm relying on DOMWindowCreated to inject my symbols into the window, and this is no longer fired in FF19 with the type set to chrome. Uh code inspection and basic testing over here suggest it fires just fine, for what it's worth. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Loading data into browser with type == chrome
On 2/25/13 12:36 PM, matt...@salsitasoft.com wrote: As discussed in https://groups.google.com/d/topic/mozilla.dev.platform/E4MG_hTv6Zw/discussion, I am not getting the DOMWindowCreated message when I use a browser element with type set to chrome Depending on what you're doing, you could just be seeing the about:blank inner window reused. Ideally I would use my own protocol handler to load the document, but I haven't had any success due to the aforementioned problem with DOMWindowCreated. I tried setting the protocolFlags to URI_DANGEROUS_TO_LOAD but that doesn't help. I'm not clear on why the protocol handler would depend on DOMWindowCreated 2) Barring that, can I change the baseURI of the document when DOMWindowCreated is fired (i.e. before the scripts are loaded)? In that case I would load the document from the chrome:// URL but change the baseURI to use my own protocol. You can set your channel's originalURI to whatever you want (which may not match where the data is loaded from, which is the URI), right? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Loading data into browser with type == chrome
On 2/25/13 1:46 PM, matt...@salsitasoft.com wrote: I tried adding properties to the window before the load (under the hypothesis that the inner window is being reused), but they don't seem to be there after the load. Then the inner window is not being reused. You can set your channel's originalURI to whatever you want (which may not match where the data is loaded from, which is the URI), right? So are you suggesting that I create the chrome:// URI channel myself and load from it after changing the originalURI? Yes, I think so. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: LOAD_ANONYMOUS + LOAD_NOCOOKIES
On 2/28/13 9:37 PM, bernhardr...@gmail.com wrote: i have run hg pull and hg update on mozilla central and still have no LOAD_DOCUMENT_URI. Are you looking in the right file? The problem seems to be that this patch breaks the WHOLE Cookie handling of firefox. Because your LOAD_NO_COOKIES has the same value as LOAD_DOCUMENT_URI. Which means it's getting set for every web page load. Oh, and your LOAD_NOAUTH_HEADER has the same value as LOAD_RETARGETED_DOCUMENT_URI which will lead to subtle bugs of its own, of course. You really can't introduce new flags to a bitfield that have the same values as existing flags. It just doesn't work well. ;) On a more serious note, I believe at this point all the flags except (125) are in use on HTTP channel, between nsIRequest, nsIChannel, and nsICachingChannel -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 3/3/13 10:12 PM, Zack Weinberg wrote: If an event is dispatched from C++ using nsContentUtils::DispatchTrustedEvent with both the 'bubbles' and 'cancelable' flags set false, what precisely is the difference between targeting it at a document's window and targeting it at the document's window's chrome event handler? The main difference is whether the web page will be able to see the events, I think. In particular, if such an event is targeted at the window, is there any circumstance in which a handler registered from chrome JS on gBrowser will *not* get a crack at it? If it's a capturing handler, it should work, assuming nothing else higher up in chrome captures and eats them... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XMLHttpRequest for REST/PUT request to GoogleCalendar -- discloses login/PW to console
On 3/4/13 6:26 AM, gNeandr wrote: Any idea how to fix that problem, any workaround .. catching the response NOT to throw it to the console? If you control the server, make sure the Content-Type it returns is not an XML type (like the fruux.com server does). If you control the caller and don't expect to get back XML for this request, tell the XHR so by setting responseType=text or whatever you want on the XHR before the send(). There is a bug https://bugzilla.mozilla.org/show_bug.cgi?id=521301 already but no solution! It's not clear to me that this is a bug, per spec. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 3/4/13 9:10 AM, Zack Weinberg wrote: So I guess the next question is where does one put a capturing event handler so that it will see *all* events of the relevant type regardless of which window it was dispatched to or the contents of that window I don't think such a thing is possible in a world in which stopImmediatePropagation exists, is it? As in, if you have two handlers which both try to (1) see all events and (2) make sure nothing else sees them, then one of them will lose. If you ignore that part, putting a capturing handler on the toplevel chrome window would presumably work, I think. the immediate followup is whether it's possible for that handler to retrieve the window (originalTarget?) and learn its chrome structure (e.g. 'is this document in a tab, and if so, which tab?') The event.target and event.originalTarget should presumably work correctly, yes. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: proposal: replace talos with inline tests
On 3/4/13 8:15 AM, Jim Mathies wrote: So to work around this I’ve been putting together some basic perf tests I can use to measure performance using the mochitest framework. How are you dealing with the fact that mochitest runs on heterogeneous hardware (including VMs and the like last I checked, which could have arbitrarily bad (or good!) performance characteristics depending on what else is happening with the host system)? Maybe we should consider changing this system so devs can write performance tests that suit their needs that are integrated into our main repo? Basically: 1) rework graphs server to be open ended so that it can accept data from test runs within our normal test frameworks. 2) develop of test module that can be included in tests that allows test writers to post performance data to graph server. 3) come up with a good way to manage the life cycle of active perf tests so graph server doesn’t become polluted. 4) port existing talos tests over to the mochitest framework. 5) drop talos. This sounds plausible, modulo the inability to port Tp in its current state to a setup that involves the tests living in m-c, as long as the problem above is kept in mind. Basically, reusing something mochitest-like for developer familiarity may make sense, but it would need to be a separate test suite run on completely separate test slaves that are actually set up with performance testing in mind. A separate test suite which is like mochitest is not a problem per se (we have the ipcplugins, chrome, browserchrome, a11y tests already). So the main win would be making it easier to add new tests in terms of number of actions to be taken (something it seems like we could improve with the current Talos setup too) and easier for developers to add tests because the framework is already similar, right? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 3/4/13 1:08 PM, Zack Weinberg wrote: It only needs to be certain of seeing the event despite anything content can do, In that case, a capturing handler on the chrome event listener will work fine. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Turning off window.Components for the web
On 3/5/13 12:01 PM, Bobby Holley wrote: They were embarrassed and fixed their code They weren't embarrassed and didn't fix their code. And since we relanded netscape they don't really have incentive to... Of course now their sniffing relies on at least three separate things all of which we want to remove. :( Defining a shim for interface constants is significantly more complicated. While possible, it represents a fair amount of engineering effort that I'd like to avoid, and forces us to maintain nsIDOMFoo interfaces that would otherwise go away with the WebIDL transition. Peter has suggested making Components.interfaces.nsIXMLHttpRequest == window.XMLHttpRequest, for what it's worth. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Why firefox is not sending 'filename' parameter for form file parts encoded as specified in rfc2388?
On 3/11/13 12:27 PM, Gavin Sharp wrote: But firefox is just sending 'filename' parameter encoded with the page encoding or the form accept-charset, this is, it is sending raw UTF-8 or the choosen encoding. Which is the reason for this? The main reason is that it's what Netscape and IE did 12 years ago, so servers were written to expect it, so other browsers had to copy it, so more servers were written to expect it and here we are. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: T pushes to try
On 3/27/13 8:08 PM, Steve Fink wrote: Yes, it does depend on a mostly undocumented try syntax feature from bug 802937. I've at least added these example pushes to https://wiki.mozilla.org/ReleaseEngineering/TryChooser. Adding either a link to that, or examples directly, to http://trychooser.pub.build.mozilla.org/ would be awesome... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Clang static checking support now available
On 3/31/13 8:05 AM, ISHIKAWA, Chiaki wrote: Has mozilla considered using this free service before? Yes. You can query bugzilla for coverity-based bug reports... The false positive rate was very very high, last time it was tried. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing expando properties from window wrapper when freeing sandbox
On 4/22/13 4:37 AM, Matthew Gertner wrote: However, the sandbox lives on if it contains DOM event handlers that have not been removed. Event handlers, or event listeners? For event listeners, this happens because they're not holding cross-compartment wrappers, presumably... and that's not likely to change; see bug 862629. For event handlers this is surprising now but will stop being so once bug 862629 lands. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking the amount of system JS we use in Gecko on B2G
On 4/21/13 7:51 PM, Justin Lebar wrote: Since most of these features implemented in JS seem to be DOM features, I'm particularly interested in the opinions of the DOM folks. Opinions differ. ;) I think for DOM features that are not invoked on most pages, implementing them in JS seems like a reasonable choice. We are actively working on making this easier to do than it is now. This is only a viable implementation strategy for objects you don't expect to have lots of around, since there is a lot more per-object overhead for a JS-implemented DOM object. But lots of things that are currently implemented in JS are per-page singletons, so that's ok. I'm very sympathetic to Andreas' points about memory-safety (especially for hard-to-fuzz things) and ease of prototyping and implementation. But on the flip side, there are security bugs that JS implementations are subject to (involving content passing in unexpected objects and whatnot) that a C++ implementation simply never has to deal with. See https://bugzilla.mozilla.org/show_bug.cgi?id=856042 for those with the access... I'm hoping that putting a WebIDL layer in front of the JS implementations will help, but will of course add to the per-object overhead. One other thing to keep in mind is that doing an implementation in JS does not involve having to figure out cycle collection, etc, boilerplate... So to the extent that b2g is in a not enough hands situation, implementing in JS makes sense. To the extent that we have code whose performance we want to maximize or whose memory footprint we need to minimize, a JS implementation right now is not a good idea. I'm afraid in practice the right decision should probably be made on a per-component basis, and the hard part with that is making sure informed decisions are made. :( -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rethinking the amount of system JS we use in Gecko on B2G
On 4/22/13 5:22 PM, Jeff Muizelaar wrote: I don't know if there's anything surprising here. Calling into JS from C++ goes through xpconnect which is a long standing slowness. _That_ we can try to fix by converting to JS-implemented WebIDL. Right now that performs about the same, but we know how to make it much faster... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accelerating exact rooting work
On 4/23/13 11:18 AM, Ehsan Akhgari wrote: Does this also apply to code holding on to JSObject*s? If you're holding them on the heap... sigh. Just trace them and use fromMarkedLocation as needed; there is nothing better at the moment. You can't use JS::Rooted on the heap. Can the stuff in objdir/dom/bindings be fixed whole-sale by changing the WebIDL codegen? Yes, and it's being done. See https://bugzilla.mozilla.org/show_bug.cgi?id=864727 and https://bugzilla.mozilla.org/show_bug.cgi?id=861022 which cover most of it. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Some data on mozilla-inbound
On 4/23/13 1:17 PM, David Keeler wrote: I would like to know a bit more about this. Is our list of supported toolchains so diverse that building with one version versus another will report so many false positives as to be useless? Yes. For example a typical clang+ccache build of the tree with fatal warnings will fail unless you jump through deoptimize-ccache hoops, because things like if (FOO(x)) will warn if FOO(x) expands to (x == 5). For another example msvc until recently didn't actually have warnings as errors enabled at all in many directories, so it didn't matter what you did with your local setup in msvc. I enabled warnings-as-errors on my local machine after pushing something to inbound that failed to build because of this, and I've had no problems since then. It _really_ depends on the exact compiler and toolchain you're using. So there are instances where developers didn't use the try servers and also didn't compile locally at all before pushing to inbound? I don't think we as a community should be okay with that kind of irresponsible behavior. Agreed. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for an inbound2 branch
On 4/26/13 6:26 PM, Nicholas Nethercote wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2?
The following steps assume that the default and default-push for your
repo are both appropriate versions of inbound and that i2 and
i2-push are the appropriate versions of inbound2 (you can create such
aliases in your .hgrc). They also assume that since inbound just closed
there is bustage on inbound that is not going to be present on inbound2
and that you have already pulled this bustage into your tree.
1) Make sure your patch-to-land is tracked by mq
2) hg qpop -a
3) hg strip roots(outgoing('i2'))
4) hg pull -u i2
5) hg qpush your patches
6) hg qfin -a hg push i2-push
Step 3 is slightly annoying because you have to quote the parens from
the shell
In any case, the upshot of the above steps is that after step 4 your
tree is effectively a clone of inbound2, and then you just push to it
normally.
If your patches are not tracked by mq and you don't want them to be thus
tracked then things are more complicated: as far as I can tell you want
to pull into the same tree from inbound2, transplant your patch on top
of the tip of inbound2, strip out the bits of inbound that shouldn't be
landing, then push.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: DOM Bindings Meeting - Monday @ 12:30 PM PDT
On 4/29/13 11:05 AM, Kyle Huey wrote: Our (ostensibly) weekly DOM bindings meetings continue on Monday April 29th at 12:30 PM PDT. Per discussion of the meeting, here's a strawman plan for converting Window to WebIDL: https://etherpad.mozilla.org/WebIDL-Window Please add anything I missed that needs to happen there? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stylesheet loaded from privileged channel does not trigger content policy for subresources
On 5/1/13 6:48 PM, Matthew Gertner wrote: Is it normal that subresources loaded by a stylesheet from a privileged channel do not trigger the content policy Yes. Content policy checks are skipped when the loader has system principal. If so, is there any way around this other than to not have the stylesheet's channel have the system principal? There is not. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for an inbound2 branch
On 5/2/13 10:09 AM, Matt Brubeck wrote: The suggested workflow with inbound2 would lead to almost-identical multi-headed repos in developers' local clones anyway. Only temporary ones, until inbound and inbound2 merge. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Accelerating exact rooting work
On 4/23/13 11:18 AM, Ehsan Akhgari wrote: Can the stuff in objdir/dom/bindings be fixed whole-sale by changing the WebIDL codegen? This is nearly done: we're down to the issues in bug 868715, which largely affect the js-implemented codegen at the moment, and the problem of what to do with TypedArray structs. Sadly, this last doesn't fall into the easy and tedious bucket. :( David Zbarsky has also fixed all the hazards in classinfo and a bunch more in various other files under dom/, so we're down to about 350 rooting hazards in the browser, from about 2500 a week or so ago. If people want to help out, I'm including the full list of browser hazards at the end of this mail. Please comment in bug 867844 if you plan to fix the content/ hazards and please comment in bug 868312 if you plan to fix things in dom/, and in other cases file bugs blocking 831379, just so we can avoid duplicating work. -Boris P.S. Full hazard list can be found at http://people.mozilla.org/~sfink/analysis/browser/rootingHazards.txt and the list of relevant files as of this morning is: 1 hazards in js/src/jsapi-tests/testXDR.cpp 1 hazards in js/xpconnect/src/XPCConvert.cpp 1 hazards in dom/ipc/StructuredCloneUtils.cpp 1 hazards in js/src/ion/AsmJS.cpp 1 hazards in dist/include/mozilla/dom/CallbackFunction.h 1 hazards in js/xpconnect/src/XPCVariant.cpp 1 hazards in content/media/webaudio/AudioBuffer.cpp 1 hazards in dom/workers/Exceptions.cpp 1 hazards in js/src/ctypes/typedefs.h 1 hazards in dom/workers/ChromeWorkerScope.cpp 1 hazards in js/src/ion/Lowering.cpp 1 hazards in clude/molude/mozilla/dom/TypedArray.h 1 hazards in content/xul/document/src/XULDocument.cpp 1 hazards in js/src/ctypes/CTypes.cpp 1 hazards in js/src/vm/ParallelDo.cpp 1 hazards in content/base/src/EventSource.cpp 1 hazards in content/base/src/nsNodeUtils.cpp 1 hazards in js/xpconnect/src/XPCJSRuntime.cpp 1 hazards in toolkit/xre/nsEmbedFunctions.cpp 1 hazards in dist/include/mozilla/dom/BindingUtils.h 1 hazards in dom/indexedDB/IDBRequest.cpp 1 hazards in dom/indexedDB/IDBDatabase.cpp 1 hazards in clude/jslude/js/Vector.h 1 hazards in content/events/src/nsEventListenerManager.cpp 1 hazards in content/base/src/nsContentUtils.cpp 1 hazards in content/html/content/src/UndoManager.cpp 1 hazards in content/xbl/src/nsXBLSerialize.cpp 1 hazards in content/html/content/src/HTMLMediaElement.cpp 1 hazards in dom/workers/ImageData.cpp 1 hazards in dom/camera/CameraControlImpl.cpp 1 hazards in content/xslt/src/xslt/txMozillaXSLTProcessor.cpp 1 hazards in js/jsd/jsd_obj.cpp 1 hazards in content/events/src/nsEventListenerService.cpp 1 hazards in security/manager/ssl/src/nsCrypto.cpp 1 hazards in content/html/content/src/nsGenericHTMLElement.cpp 1 hazards in tools/profiler/TableTicker.cpp 1 hazards in js/xpconnect/src/nsDOMQS.h 1 hazards in content/xul/document/src/nsXULPrototypeDocument.cpp 1 hazards in js/xpconnect/src/XPCQuickStubs.cpp 1 hazards in content/xbl/src/nsXBLBinding.cpp 1 hazards in widget/xpwidgets/GfxInfoBase.cpp 1 hazards in js/xpconnect/src/XPCQuickStubs.h 1 hazards in content/xbl/src/nsXBLDocumentInfo.cpp 1 hazards in toolkit/components/telemetry/Telemetry.cpp 1 hazards in dom/camera/DOMCameraControl.cpp 1 hazards in content/base/src/nsInProcessTabChildGlobal.h 1 hazards in dom/mobilemessage/src/ipc/SmsIPCService.cpp 1 hazards in js//inclst/include/mozilla/dom/workers/bindings/EventTarget.h 1 hazards in dom/indexedDB/IndexedDatabaseManager.cpp 1 hazards in dist/include/mozilla/dom/EventListenerBinding.h 1 hazards in content/base/src/nsContentList.cpp 1 hazards in content/canvas/src/CanvasUtils.h 1 hazards in storage/src/mozStorageAsyncStatementParams.cpp 1 hazards in js/src/vm/Shape.cpp 1 hazards in tools/profiler/ProfileEntry.cpp 1 hazards in content/base/src/nsDOMBlobBuilder.cpp 1 hazards in dom/mobilemessage/src/SmsManager.cpp 1 hazards in clude/molude/mozilla/jsipc/ContextWrapperChild.h 1 hazards in dom/file/ArchiveRequest.cpp 1 hazards in content/html/document/src/nsHTMLDocument.cpp 1 hazards in content/base/src/nsDocument.h 1 hazards in js/src/ion/IonCaches.cpp 1 hazards in content/xul/content/src/nsXULElement.cpp 1 hazards in js/src/vm/Debugger.cpp 1 hazards in dom/base/DOMRequest.cpp 2 hazards in dom/network/src/TCPSocketChild.cpp 2 hazards in dom/system/OSFileConstants.cpp 2 hazards in content/xul/document/src/nsXULPrototypeCache.cpp 2 hazards in content/base/src/nsXMLHttpRequest.cpp 2 hazards in dom/devicestorage/nsDeviceStorage.cpp 2 hazards in storage/src/mozStorageStatementParams.cpp 2 hazards in content/base/src/WebSocket.cpp 2 hazards in storage/src/mozStorageStatementRow.cpp 2 hazards in js/jsd/jsd_stak.cpp 2 hazards in content/xul/templates/src/nsXULTemplateBuilder.cpp 2 hazards in js/src/jswrapper.cpp 3 hazards in tools/profiler/JSObjectBuilder.cpp 3 hazards in dom/workers/EventTarget.cpp 3 hazards in js/xpconnect/src/XPCWrappedNative.cpp 3 hazards in dist/include/nsTArrayHelpers.h 3 hazards in
Re: We should drop MathML
On 5/6/13 7:27 AM, Benoit Jacob wrote: I guess I don't see the usefulness of allowing to apply style to individual parts of an equation Styling parts of an equation with different colors can be _extremely_ useful for readability. It's rarely done in print, of course, and I assume there are various reasons ranging from it's more expensive to no one does that for why. But on the web it seems like a no-brainer. Styling parts of an equation with different font styles is of course all over the place; there are lots of TeX packages that will let you do things like \mathfrak, for example. Of course fraktur in particular got stuck into Unicode... There are some interesting use cases I can think of for scripted visibility styling in educational materials. Regarding editing, if I understand correctly, you have WYSIWYG or other kinds of fancy editing in mind, where understanding of the syntax tree inside of the equation is needed; I haven't seen a need for WYSIWYG editing of math I think this goes back to roc's point about current TeX workflows being ok for specialists (maybe; I have in fact wished for a good wysiwyg editor for TeX on many an occasion, but was always stymied by the need for custom macros for my documents), but most people _do_ in fact want wysiwyg editing. It's not fancy for most people but a baseline requirement. So any system for math on the web needs to have support for that requirement... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Visual C++ PGO linker memory usage
On 5/16/13 3:15 PM, Ted Mielczarek wrote: TL;DR: PGO on MSVC is now opt-in per-source-directory. This is awesome. Thank you, Ehsan and Ted, for getting this sorted out! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: We should drop MathML
On 5/28/13 8:22 AM, Benoit Jacob wrote: When I started this thread, I didn't even conceive that one would want to apply style to individual pieces of an equation. Someone gave the example of applying a color to e.g. a square root sign, to highlight it; I don't believe much in the pedagogic value of this kind of tricks --- that sounds like a toy to me --- but at this point I didn't want to argue further, as that is a matter of taste. Note that I've seen at least one PhD dissertation that made good use of color to highlight which terms of a 2-page-long equation canceled each other to produce the final (much shorter; iirc it was 0) result. Of course that was in the PDF version; the print version had to be black-and-white, and was a lot harder to follow. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Code Review Session
On 5/24/13 10:50 AM, Justin Lebar wrote: Consider for example how much better harthur's fileit and dashboard tools [1] [2] are than bugzilla's built-in equivalents. [2] http://harthur.github.io/bugzilla-todos/ So I actually tried using the dashboard you link to for the last week. It's actually worse at least for my use case than what I do in bugzilla right now (which is just a saved search for review/feedback requests on me), because: 1) It does not show feedback requests. This may explain why some people are routinely ignoring them 2) It's a lot slower to load than a saved search. 3) If left open (see #2) it does a bunch of JS off timeouts, causing noticeable jank in my browser. All of which is to say that use cases apparently differ, since I assume for you the bugzilla-todos dashboard is in fact a lot better. Of course I would love something that did what this dashboard does in terms of showing bugs to check in and whatnot without the drawbacks. ;) We shouldn't conflate owning the PR data with integrating the PR tool into bugzilla. I think that depends on what integrating means. Ideally, we should have something that makes it easy, starting from a line of code to track back why that line of code is the way it is. In a perfect world that would mean correct blame, with the changeset linking to the discussion about the patch, reviews, design documents if they exist, etc, etc. We're not going to get there, if nothing else because a lot of that seems to be in email/irc/hallways, but the closer we can get the better. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Being careful about adding new Web APIs, and how we are perceived
I know we already try to be, but it's worth seeing things like https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/wDV9JHs0mBA/0iw5vRDThXYJ to be reminded that others may not realize that we are... Now the particular examples Greg cites are, I think, not really applicable, but it's worth keeping in mind that the perception is there. To the extent that we worry about this perception, what are good ways to deal with it, other than announcing an official policy on how we will add stuff and sticking to it? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/9/13 3:14 PM, Taras Glek wrote: Conversely, poor code review practices hold us back. Agreed. At the same time, poor patch practices make reviews _much_ harder. We should generally expect good patch practices from established contributors; obviously expecting them from new contributors is not reasonable. I believe that getting fast review turnaround is a collaboration between the reviewer and review requester; it shouldn't be solely on the reviewer to do a fast review no matter how hard the requester makes it. More on this below. a) Realize that reviewing code is more valuable than writing code as it results in higher overall project activity. I agree that it results in higher activity. Whether it results in overall higher value depends on the activity. But as a first cut, I agree with this claim. If you find you can't write code anymore due to prioritizing reviews over coding, grow more reviewers. Easier said than done, of course. ;) Especially for people who get flagged to review abandoned code because there is no one else who is willing to learn it. b) Communicate better. Yes, absolutely. The flip side of this is don't request review from people who are labeled as being away in Bugzilla and expect fast turnaround. I really wish Bugzilla could let me flag myself as not available for reviews when I'm on vacation, say. Expecting people to comment about being on vacation while on vacation is, imo, not reasonable. Does anyone disagree with my 3 points above? Modulo the caveats above, no, but I would like to add some points about what makes a patch easier to review. A lot of our contributors are not very good on these points: * Split mass-changes or mechanical changes into a separate patch from the substantive changes. * If possible, separate patches into conceptually-separate pieces for review purposes (even if you then later collapse them into a single changeset to push). Any time you're requesting review from multiple people on a single huge diff, chance are splitting it might have been a good idea. * Actually address the review comments before requesting another review. It's very common to just ignore (miss?) some of the review comments, which means the reviewer then needs to triple-check that all the things they pointed out got fixed. * When requesting a second review on a patch, provide an interdiff so that the reviewer can just verify that the changes you made match what they asked for. Bugzilla's interdiff is totally unsuitable for this purpose, unfortunately, because it fails so often. * When requesting review or feedback on just part of the patch, make that very clear. All of the above are a consequence of a simple observation: time to review, except for simple mass-changes, is nonlinear in patch size. For a single review pass, I would say it's probably quadratic in most cases. Since the number of review passes is itself typically non-constant in patch size, this means that the common modus operandi of posting a huge diff with a bunch of issues, then addressing some of the review comments and posting another huge diff, etc, takes up a huge amount of reviewer time, most of it basically wasted. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Embracing git usage for Firefox/Gecko development?
On 5/31/13 3:20 PM, Matt Brubeck wrote: blame mobile/android/chrome/content/browser.xul: git 1.015s hg 0.830s Was this a git blame -C (which would be more similar to hg blame), or just a git blame? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/9/13 4:29 PM, Chris Peterson wrote: I've seen people change their Bugzilla name to include a comment about being on PTO. Sure. As a simple example, I did that on June 20th. I got about 20 review requests over the course of the following week and a half, and that's with most of the people who would normally ask me for review _not_ doing so because they knew I was away. Bugzilla's interdiff is totally unsuitable for this purpose, unfortunately, because it fails so often. Can we fix Bugzilla's interdiff? Not easily, because it does not have access to the original code... The most common failure mode here is something like this: 1) Author posts patch. 2) Review happens. 3) Author rebases patch to tip, makes edits to address review comments, re-requests review. At this point, bugzilla interdiff between the new patch and the old one will only work if the rebase was exceedingly trivial. Further, what's really desired in most cases is the diff between the rebased patch and the patch that addresses comments, not the diff between the old patch and the new patch. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/9/13 6:11 PM, therealbrendane...@gmail.com wrote: I've said this before, not sure it's written in wiki-stone, maybe it should be: if you get a review request, respond same-day either with the actual review, or an ETA or promise to review by a certain date. Again, this is not viable during vacations/weekends... Unless by get you mean get the mail as opposed to have it appear in your queue. People may need reminding or nagging but that should be the exception. It sounds like it isn't exceptional, or rare enough. Indeed. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Disabling XUL -moz-inline-stack/-moz-stack on the Web?
On 6/13/13 11:56 PM, Robert O'Callahan wrote: Bug 875060 made me wonder whether we should disable XUL 'display' values on the Web, perhaps starting with -moz-stack and -moz-inline-stack. They do very little that can't be done with absolute positioning. Perhaps we would leave XUL 'display' values enabled for pages where remote XUL has been whitelisted. What do people think? I think it's a great idea, just like I did a week ago when I filed https://bugzilla.mozilla.org/show_bug.cgi?id=879275 ;) I was more worried about -moz-box, since people are more likely to (ab)use it, but you're right that the compat issues are likely to be less with the stack display types. The point about allowing them if remote XUL was whitelisted is a good one, though; we probably should do that -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/10/13 1:58 PM, Mark Côté wrote: The BMO team is again considering switching to ReviewBoard, which should fix this problem How does ReviewBoard address this? Again, what we have in the bug is diff 1 against changeset A and diff 2 against changeset B that incorporates the review changes. What the reviewer would like to see is a diff from 1 rebased against B to 2. I guess that's possible if the system tries to automatically rebase diff 1 against changeset B, but if the automatic rebase fails you still fail... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/10/13 12:56 PM, msrecko...@mozilla.com wrote: Why not? Because submitting a first patch is scary enough as it is that we should try to minimize the roadblocks involved in it. This is also why the reviewer in cases like that should handle setting the checkin-needed keyword (or just land the patch), push it to try as needed, etc. If there is a list of good patch practices, there is no reason we can't ask people to complete a checklist and comment on it. I think that's a fine thing to do for people who are planning to do more than one patch, and is definitely something we should do when someone starts contributing somewhat consistently. But I'm not convinced that it's reasonable to require it for a first patch... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Watching pages on MDN
On 6/14/13 10:19 AM, Eric Shepherd wrote: We have just thrown the switch, and if you're logged into MDN, you should now have a new Email me article changes button next to the Edit button near the top of the page. Thank you for making this happen! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Making proposal for API exposure official
On 6/24/13 5:49 PM, Ehsan Akhgari wrote: What about changes made in order to improve compliance with a spec not developed by Mozilla? This is a tough call. My experience is that most specs out there are buggy in their use of WebIDL and in their general API design, so such a change would need someone who understands the various pieces involved to have reviewed the spec first... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/10/13 8:31 AM, Mark Banner wrote: The problem is, that doesn't work on the patch submission forms. Or on bzexport. I can't recall the last time I used the Bugzilla UI for requesting review... but I think it would be good to have the option to provide a warning with a little bit of text *and* have that a) displayed on the submission forms, and b) prompted/confirmed if the user decides to request anyway. And communicated via bzapi so bzexport can also warn. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/11/13 7:59 AM, Gervase Markham wrote: Hey, if we had a PTO app that tracked all absences, we could integrate with it... sigh Just in case you were talking about the moco PTO app, it doesn't track absences for non-MoCo employees, and even for employees it does not track non-PTO absences (being a PTO app and all). -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/11/13 9:23 AM, Justin Lebar wrote: One thing I've been thinking about is /why/ people are slow at reviews. Here are some possible reasons I've encountered myself: 1) Feeling overwhelmed because you have too many reviews pending and therefore just staying away from your list of reviews. Note that this can be self-perpetuating. 2) Feeling like you have to do your reviews in some sort of FIFO order, so that a review for a large patch (which takes a long time because that's just how large patches work) will block possibly-quick reviews for smaller patches. 3) Feeling like you want to do your reviews in some sort of most-expeditious order, so that a constant stream of small patches delays review of a big patch for weeks or months. 4) Feeling that you need multiple hours of uninterrupted time, probably over several days for review of a complicated patch and not being able to find it due to the scattering of meetings, people asking you questions, smaller reviews, etc that you're also doing. Note that anyone who has no time to code because of reviews probably also has no time to do big complicated reviews, for the same reasons! 5) Simply having too high a review load. Anecdotally, it typically takes me until sometime Tuesday afternoon at best to catch up on all the review requests that come in between end-of-work Friday and Monday morning. 6) Just disliking doing reviews (but more on this below). 7) Wanting to completely focus on some other complicated task for a few days ... or weeks. It would be interesting to see what other reasons there are and what the relative frequencies are. Someone who usually has a long review queue has told me that he hates reviewing code. Reviewing code is just not all that fun. You have to tell people they did something wrong, often with some fairly arbitrary (in the grand scheme of things; we do it so we have consistent coding style) nitpicks, there is not that much of a sense of accomplishment at the end. It feels very adversarial at times. Sometimes you learn new things in the process, but more often you try hard to politely tell people that they've screwed something up... possibly after you already told them that about that same thing in the previous iteration of the patch. At least for me, it can get downright depressing at times. But debugging leaks is not that fun either. Or trying to read through flat profiles and speed things up. Or hunting down a dangling pointer bug. Or trying to convince people on a standards mailing list to not do something insane, for that matter. Fundamentally, we feel that reviews are useful and that means they have to get done; the doing is not all that fun, but it's a sort of giving back to the community, in my view. I realized that we don't really have a place at Mozilla for experienced hackers who don't want to do reviews. Should we? Could we do this without violating people's sense of fairness? How do we handle this with the other unpalatable tasks above? Informally, what I see is that they get shunted to people who are either not as unhappy doing them or have a stronger sense of I don't like it, but it needs doing, and no one else is stepping up. And it sure as heck violates people's sense of fairness. Of course we do that with reviews too (a well-known technique for doing fewer reviews is just being slow about it so people stop asking, whereas someone who does reviews quickly is rewarded by people piling on reviews), and it likewise violates people's sense of fairness. Of course the other thing I see happen with the unpalatable tasks I list above is that they just don't get done in many cases because no one steps up. That's a bit rarer with reviews, because we don't consider those as optional. But it has happened: I've seen patches die because no one stepped up to review. Here's another way to look at this: do these hackers want _others_ to review their patches? If so, how do they expect that to happen? Obviously everyone would prefer to work on the things they _want_ to work on, not necessarily the things that _need_ to be worked on. To the extent that someone focuses more on the former than on the latter, they're shafting others whose sense of duty won't let them do that. The result is that you get people who are unhappy because they never get to work on the things they want to or who are unhappy because they're doing all their I would like to get this done work after hours. Or both, at times: only working on things that need to happen _and_ having to do it after hours... And as a further note, the more reviews pile on just a small subset of people, the more problems 1-5 listed above manifest. As Taras said, the right solution to review load is to grow more reviewers, but that's hard to do if people are basically shirking the responsibility. As another data point, someone told me recently that he's trying not to
Re: review stop-energy (was 24hour review)
On 7/11/13 11:37 AM, Robert O'Callahan wrote: While I think your observations are useful, I think (hope!) you are a massive outlier Somewhat. My list was based on not only what makes my reviews slow but what I've heard people mention as making reviews slow. I do agree we shouldn't design a policy based on my review queue. ;) I would be totally OK with a policy that explicitly applies to everyone except you. Or, we could parameterize it with a dynamic list of exceptions who are known to be overloaded with reviews. So the thing is, I'm not _always_ overloaded with reviews. I generally keep on top of them unless I take time off or several large patches end up in my review queue at once. And I think that applies to most people who are trying to do their reviews... The problem is that right now there is no way to mark yourself as temporarily less responsive on reviews than normal, whether it's because you're on vacation or because you have a 500KB patch to review that will take all week. And then reviews pile on. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/11/13 2:41 PM, Chris Pearce wrote: Maybe you need to start farming out reviews to other/newer members of the teams you work on? Oh, that's been happening. A lot. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: review stop-energy (was 24hour review)
On 7/15/13 2:58 PM, Steve Fink wrote: Even for the case of dependent patches (ones with separate parts that cannot be landed together, but are usefully split up for review)? Assuming s/cannot/must/, that's why I said generally, not always. ;) Perhaps that's wrong of me, but it seems like the patches attached to bugs and the patches that actually land aren't very well correlated in our current setup anyway. They should be for anyone using checkin-needed... But yes, in other cases maybe not so much. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: unreported JS exception bugs
On 7/18/13 9:27 PM, Benjamin Smedberg wrote: My opinion is still that we should rip out most or all of this mechanism, and replace it with an opt-in mechanism for methods that actually do exception passthrough. For what it's worth, that's how the mechanism for calling JS from C++ via WebIDL bindings works: Exceptions in JS are reported unless the C++ caller explicitly opts in to rethrowing them. And in that case we assert if it doesn't check whether it needs to rethrow, even if there is no exception thrown, so the exceptions won't disappear due to inattentiveness. The xpidl story is a bit more complicated because it tries to make it transparent whether you're calling C++ or JS, so you can't just put the opt-in in the function signature like we do for WebIDL. But maybe we could just set up a simple RAII class for doing such opt-in... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: id2webidl
On 7/22/13 10:45 AM, Andrea Marchesini wrote: I know that we don't want to convert all the existing interfaces to WebIDL, but I still think this report is useful to choose which interface is available to be converted. I think it would be useful to have a report like this but restricted to nsIDOM* interfaces, which are more likely to be something we want to convert. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: swapDocShells
On 7/23/13 10:38 AM, Jan Odvarko wrote: Is the method removed? No. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
On 7/30/13 7:43 AM, Boris Zbarsky wrote: On 7/30/13 7:20 AM, janjongb...@gmail.com wrote: But is it possible to have a promise as a return type in my .idl file (b2g)? Just list it as nsISupports in the .idl. XPConnect will do the right thing. Ignore the above; I thought you were talking about Gecko's Promise implementation, not a manual impl in JS. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
On 7/30/13 11:13 AM, Dave Townsend wrote: The JS promise implementation came out of a desire to use promises in add-ons and devtools amongst others. I believe the C++ implementation came out of the DOM spec. I'm not sure why we need both. OK. Given that there is also a desire to be able to use the DOM Promises in b2g (see bug 897913), how do people feel about enabling the Promise API in at least chrome globals (and via Xrays), and setting up Promise in things like JS component globals as well? This shouldn't be too difficult to do... Then anyone who wants to use Promises in Chrome code can use the DOM ones. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
On 7/30/13 1:37 PM, Gavin Sharp wrote: We'll need to investigate whether the implementations are compatible, though That's fair. DOM Promises are definitely modeled after Promises/A+, but the APIs might not quite match up. :( -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: std::unique_ptr, std::move,
On 8/2/13 8:14 PM, Brian Smith wrote: The risk that any developer would need to waste time on ESR just to support a product that isn't even Firefox on a platform that virtually nobody uses, and the risk that comes with making any changes to the security fix that you are trying to backport. I feel that there's an important piece of data missing here: how many patches get backported to ESR in practice? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On builds getting slower
On 8/5/13 2:05 AM, Justin Lebar wrote: Nick, when you made changes to the JS engine's #includes, did you observe a change in build times? Just for data, when khuey just reduced the number of includes in bindings code, that did in fact affect build times. https://bugzilla.mozilla.org/show_bug.cgi?id=887533#c8 has some numbers, but the upshot is that rebuilding every single binding .cpp (equivalent of a clobber build) went from about 5 minutes to about 3 minutes. Which is still too darned long. :( -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On builds getting slower
On 8/5/13 1:46 AM, Joshua Cranmer wrote: DOMJSProxyHandler.h [2614, #197] includes xpcpublic.h [2645, #188] includes nsIURI [3295, #121]. DOMJSProxyHandler appears to include xpcpublic.h solely for IsDOMProxy; xpcpublic.h appears to include nsIURI because it uses it as an nsCOMPtr in the CompartmentStatsExtras class it defines. The end result is that touching nsIURI will require us to rebuild all of the DOM bindings. Note that BindingUtils.h also includes xpcpublic.h, so even fixing the DOMJSProxyHandler bits wouldn't necessarily help. On the bright side, nsIURI is almost never touched, unlike xpcpublic itself. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use .then(null, Cu.reportError); with Promise.jsm
On 8/9/13 5:54 AM, Neil wrote: (For instance I suspect it might be feasible for DOM promises to report any pending exception when they get garbage collected.) Oh, that is a _very_ interesting idea. I wonder whether we can get that specced, or at least allowed by the spec. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Removing xml:base
There is a proposal in https://bugzilla.mozilla.org/show_bug.cgi?id=903372 to remove xml:base support. Do we actually use this for anything? I thought we used to set it for xbl stuff, but I don't see obvious code doing that. If we can, it would be great to rip this out: it would significantly simplify a bunch of things. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use .then(null, Cu.reportError); with Promise.jsm
On 8/9/13 9:27 AM, Boris Zbarsky wrote: I think we should definitely report to the error console. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=903419 -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stop #including jsapi.h everywhere!
On 8/19/13 8:15 PM, Nicholas Nethercote wrote: Unfortunately, this work will only go so far because xpcpublic.h, BindingUtils.h, and DOMJSClass.h all (unavoidably) include jsapi.h, and they are headers that are large and included in lots of places. I'd love to hear suggestions as to how they could be broken into smaller pieces and/or included in fewer places. DOMJSClass.h only needs various forward-declarations, mostly. The exceptions are: 1) It needs js::GetGlobalForObjectCrossCompartment (used in an inline method), but we could move that bit into some other header. The declaration of the inline method would need to stay here, but the definition could be somewhere else. 2) It needs the definition of JSClass, for a member of the DOMJSClass struct and the DOMIfaceAndProtoJSClass struct. Unfortunately, this is defined in jsapi.h and defining the DOMJSClass struct is the main point of this header file. 3) It needs js::GetReservedSlot for some inline functions, but we could put those in some other header. BindingUtils.h we could try breaking up in various ways, but it should be very rare for _headers_ to include that file; for the most part such inclusions are a bug from my point of view. For non-headers that include it (e.g. binding implementation files), it might well be common to need jsapi.h. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Build times of different projects
On 8/26/13 6:31 PM, Mike Hommey wrote: Not necessarily. You can take that as being exactly the point being made, and it has some value. If your preprocessed source is 40 times bigger than the plain source, there might be something wrong. Mmm... We pretty commonly have files whose .i is 40x bigger than the .cpp. :( Luckily, cutting down on unnecessary includes helps a lot with this sort of thing. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Detection of unlabeled UTF-8
On 9/5/13 11:15 AM, Adam Roach wrote: I would argue that we do, to some degree, already do this for things like Content-Encoding. For example, if a website attempts to send gzip-encoded bodies without a Content-Encoding header, we don't simply display the compressed body as if it were encoded according to the indicated type Actually, we do, unless the indicated type is text/plain. The one fixup I'm aware of with Content-Encoding is that if the content type is application/gzip and the Content-Encoding is gzip and the file extension is .gz we ignore the Content-Encoding. Both of these are workarounds for a very widespread server misconfiguration (in particular, the default Apache configuration for many years had the text/plain problem and the default Apache configuration on most Linux distributions had the gzip problwm). -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: window.opener always returns null
On 9/5/13 10:41 PM, digitalc...@gmail.com wrote: I'm creating a FF extension that needs to detect whether a window was opened via javascript with the window.open() command. Generally, testing .opener on the relevant window will work. However note that pages can explicitly null this out to break references to the opener... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stop #including jsapi.h everywhere!
On 9/7/13 12:56 PM, Benoit Jacob wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=913847 moves NS_IsMainThread to a new MainThreadUtils.h header that's cheaper to include, and in particular is all what BindingUtils.h needs (there was a helpful comment about that in BindingUtils.h). Excellent. Note https://bugzilla.mozilla.org/show_bug.cgi?id=909971 also: we can stop including MainThreadUtils.h in this header too, I think. https://bugzilla.mozilla.org/show_bug.cgi?id=913852 makes BindingUtils.h not include algorithm just for one use of std::min. This is good, but unfortunately algorithm leaks in all over the place anyway in DOM code. The way it does that is that dom/Element.h has inline methods that need nsPresContext.h and Units.h. Either one will get you things like nsRect.h or nsCoord.h, both of which include algorithm. Oh, nsContentUtils.h includes Units.h too... We should strongly consider moving the Element methods that need those includes out of line, I think; not sure what we can do about nsContentUtils. If there is a BindingUtils.h tracking bug, they could block it. There isn't one yet. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stop #including jsapi.h everywhere!
On 9/7/13 8:49 PM, Nicholas Nethercote wrote: I've been focusing entirely on jsapi.h includes. We're down to ~1480 rebuilt files when it gets touched; we started at ~2600. It's getting hard to improve, because there's a tangled clump of widely-included files that include it still either directly or indirectly: BindingUtils.h, xpcpublic.h, nsCxPusher.h, DOMJSProxyHandler.h, Workers.h, probably a couple of others I've forgotten right now. For some of these it's not too hard to break the dependency, but AFAICT we need to break the dependency for most or all of them, which is harder. Of those 1480 files, 440 or so are generated binding .cpp files. You can't stop including jsapi.h in those, for obvious reasons. We should looks at non-binding files that include BindingUtils.h and figure out why: I suspect they mostly want UnwrapObject (which definitely needs jsapi-ish bits, but could have a non-inline version for those callers) or WrapObject (which I expect doesn't need JSAPI for its inline parts). DOMJSProxyHandler.h is included almost entirely in bindings code or via BindingUtils.h. I suspect xpcpublic.h is over-included. https://bugzilla.mozilla.org/show_bug.cgi?id=910937 kills off some of that, but I bet there's more we can get rid of. I believe nsCxPusher.h only needs jsapi.h because it needs to know sizeof(JSAutoRequest) and sizeof(JSAutoCompartment) for the members of AutoCxPusher... Not sure what we can do with that. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Including algorithm just to get std::min and std::max
On 9/8/13 7:29 PM, Nicholas Cameron wrote: I timed builds to see if this makes a significant difference and it did not.. The other thing that reducing .i size helps is Windows PGO memory usage. See graph at http://graphs.mozilla.org/graph.html#tests=[[205,63,8]]sel=nonedisplayrange=90datatype=running showing the impact of the header reductions recently The tradeoff may still not be worth it, of course. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
