Re: Deprecating XUL in new UI

On 1/23/17 10:31 AM, David Bolter wrote: Should (can) it die in the Quantum development timeframe? In my opinion, no. What does that do to shipping risk? Makes it super-high. I realize churn creates risk, but I seem to recall XBL is getting in the way for Quantum styling? Not as much as

Re: Intent to ship: support "basic shapes" for the CSS 'clip-path' property

On 2/7/17 3:03 AM, Ku(顧思捷)CJ wrote: https://drafts.fxtf.org/css-masking-1/#the-clip-path https://drafts.csswg.org/css-shapes-1/#supported-basic-shapes How stable are these specs? They don't seem to be anywhere near CR, and while I realize that's not a requirement, it would be good to have

Re: Intent to implement: CSS text-justify property

On 2/8/17 5:08 AM, Jeremy Chen wrote: Link to standard: https://drafts.csswg.org/css-text-3/#text-justify-property How stable is this spec? Note that even if it's unstable that shouldn't stop us implementing; that mostly affects shipping. So as long as we're pretty sure that the basic set o

Re: Intent to implement and ship: document.origin

self.origin (in both workers and windows, for consistent API). For the window case it returns the origin of the active document. No one else implements this yet; I will be sending a separate intent for this. -Boris On 12/1/14 10:09 AM, Boris Zbarsky wrote: Summary: document.origin

Intent to implement and ship: self.origin

Summary: self.origin returns the Unicode serialization of the origin of the settings object of the global represented by "self" (a Window or WorkerGlobalScope). This gives scripts a consistent way of getting their origin in both situations. Note that unlike location.origin this represents the

Re: Intent to implement and ship: document.origin

On 2/9/17 5:44 AM, Mike West wrote: Perhaps we could deprecate `document.origin` and ship `self.origin` in Blink instead of y'all shipping `document.origin`? Given the lack of support in Edge and the incompatible support in WebKit, I can probably live with that. Especially if y'all remove it

Re: Intent to implement and ship: document.origin

On 2/9/17 5:44 AM, Mike West wrote: Perhaps we could deprecate `document.origin` and ship `self.origin` in Blink instead of y'all shipping `document.origin`? It seems like we want to encourage folks to use `self.origin` going forward... So specifically, should I be asking Anne to remove documen

Re: Intent to implement and ship: self.origin

On 2/9/17 5:45 AM, Mike West wrote: I look forward to stealing your tests. :) Yep, sounds good. I put up patches in https://bugzilla.mozilla.org/show_bug.cgi?id=1306170 with the test bits; in fact most of the patches are changes to the tests. Note that you'll want https://github.com/w3c/te

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 2/10/17 8:03 PM, Mats Palmgren wrote: I'm guessing Firefox add-ons might not bother with anything but -moz-appearance though, but I assume those counts as chrome sheets, so the property will continue to work there as before. (Please correct me if I'm wrong about that.) "Chrome sheets", for

Re: Intent to unship: xml:base attribute

On 2/16/17 7:12 AM, Xidorn Quan wrote: The perf penalty of xml:base is basically that we have to dynamically construct a URL from bottom to top along the tree whenever we need a base URL of an element. And since this URL may be constructed dynamically, the caller would have to hold a strong refer

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 2/16/17 10:23 AM, Mats Palmgren wrote: That's a valid concern, but I think ignoring -moz-appearance has fairly benign effects in most cases. Well, as in things just look wrong, is all, right? And as Jet pointed out to me, just landing it and see what breaks is standard procedure for unpref

Re: Intent to unship: xml:base attribute

On 2/16/17 5:52 PM, Xidorn Quan wrote: Is there any reason you think we should keep the Get/SetExplicitBaseURI API? As long as we can address its current users in some other way, no. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.o

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 2/16/17 6:54 PM, Mats Palmgren wrote: I don't think removing -moz-appearance even has the potential of being "critical". All that happens is that you get native styling instead (at worst). There shouldn't be any loss of function. That depends. It's not hard to come up with examples where

Re: Should &&/|| really be at the end of lines?

On 2/17/17 5:44 PM, gsquel...@mozilla.com wrote: - People who stick with the official parser will only ever see that (pushing to mozreview will reformat everything to the official style). Not all reviews go through mozreview. -Boris ___ dev-platform

Re: Please consider whether new APIs/functionality should be disabled by default in sandboxed iframes

On 2/27/17 7:07 AM, David Bruant wrote: Did a particular feature triggered your message? No, it was just something I had been thinking about for a bit. Would it make sense to add the question to the "Intent to Implement" email template? https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Inte

Re: Intent to ship: WebVR on Windows in Release

On 3/1/17 3:50 PM, kgilb...@mozilla.com wrote: As of March 1, 2017 I intend to turn WebVR on by default on Windows. So flip the pref on Windows only, right? If there is no VR hardware, is the idea that navigator.getVRDisplays() returns a promise resolving to an empty array? Link to standar

Re: Intent to ship: WebVR on Windows in Release

On 3/1/17 5:03 PM, Kip Gilbert wrote: We have worked directly with the other WebVR platform implementers to ensure compatibility. OK, but what is the actual state of that compatibility? https://github.com/w3c/webvr/issues/197#issuecomment-283492774 and https://github.com/w3c/webvr/issues/195

Re: Intent to ship: WebVR on Windows in Release

On 3/2/17 1:52 PM, kearw...@kearwood.com wrote: I tend to agree with Brandon on this particular issue That's fine. I agree with you and Brandon too. ;) I'm just worried about possible interop problems more than anything else at the moment. Would this issue block release of WebVR in Firefo

Re: Intent to ship: WebVR on Windows in Release

On 3/6/17 3:03 PM, kearw...@kearwood.com wrote: The underlying VR API's expect this process to persist for the browser's lifespan and to have mutually-exclusive access to input from the headsets. It seems that the GPU process is the best fit afaict. In case it matters, the GPU process does n

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

On 3/6/17 4:17 PM, Eric Rahm wrote: I'm unaware of a bug for this decision, but https://archive.mozilla.org stopped adding tinderbox builds back on January 18th. I'm unaware of a discussion of this at all. Why did this happen? -Boris ___ dev-platfor

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

On 3/6/17 4:29 PM, Kartikaya Gupta wrote: It looks like it's just the Linux builds that are no longer there. I'm guessing this has to do with them being on TaskCluster rather than BuildBot. That sounds like a TaskCluster bug we should just fix, then populate archive.mozilla.org with the missin

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

On 3/6/17 5:29 PM, Mike Hommey wrote: You can get the builds through the taskcluster index. Does that have the same lifetime guarantees as archive.mozilla.org? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.

Re: Sheriff Highlights and Summary in February 2017

On 3/7/17 6:23 AM, David Burns wrote: - Autoland 6%.(24 backouts out of 381 pushes) - Inbound 12% (30 backouts out of 251 pushes) Were those full backouts or partial backouts? That is, how are we counting a multi-bug push to inbound where one of the bugs gets backed out? Note that such

Re: Project Stockwell (reducing intermittents) - March 2017 update

On 3/7/17 9:26 AM, jma...@mozilla.com wrote: We find that we are fixing 35% of the bugs and disabling 23% of them. Is there a credible plan for reenabling the ones we disable? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https:

Re: Project Stockwell (reducing intermittents) - March 2017 update

On 3/7/17 1:33 PM, Honza Bambas wrote: I presume that when a test is disabled a bug is filed As far as I can tell, that's not the case... If that were the case, that would be a good start, yes. -Boris ___ dev-platform mailing list dev-platform@lists

Re: Project Stockwell (reducing intermittents) - March 2017 update

On 3/7/17 11:10 AM, jma...@mozilla.com wrote: Do you have suggestions for how to ensure we keep up with the disabled tests? Things that pop to mind are having "reenable this test" bugs filed, and possibly trying to reenable every so often and seeing whether it's still intermittent -Bori

Re: Is there a way to improve partial compilation times?

On 3/7/17 2:05 PM, Mike Conley wrote: FWIW, the MOZ_MAKE_FLAGS bit can probably be removed, as I believe mach will just choose the optimal number based on examining your processor cores. Except mach's definition of "optimal" is "maybe optimize for compile throughput", not "optimize for doing a

Re: Is there a way to improve partial compilation times?

On 3/7/17 4:25 PM, Chris Peterson wrote: Can you just nice mach? I seem to recall trying that and it not helping enough (on MacOS) with the default "use -j8 on a 4-core machine" behavior. YMMV based on OS, ratio of RAM to cores, and whatnot. -Boris _

Re: Please write good commit messages before asking for code review

On 3/9/17 2:46 PM, Ehsan Akhgari wrote: Starting now, I'm going to try out a new practice for a while: I'm going to first review the commit message of all patches, and if I can't understand what the patch does by reading the commit message before reading any of the code, I'll r- and ask for anoth

Re: Please write good commit messages before asking for code review

On 3/9/17 4:35 PM, Eric Rescorla wrote: I'm in favor of good commit messages, but I would note that current m-c convention really pushes against this, because people seem to feel that commit messages should be one line. They feel wrong, and we should tell them so. ;) The first line should in

Re: Please write good commit messages before asking for code review

On 3/9/17 5:53 PM, Ben Kelly wrote: Right now our security bug process asks about the commit message and if it "paints a target" on the patch. It asks this: Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? I always i

Re: Tracking bug for removals after XPCOM extensions are no more?

On 3/13/17 9:17 AM, Nathan Froyd wrote: We do not. Bug 1299187 is related to such work, but that bug only covers unexporting symbols that 3rd party software would access. bz has filed a few bugs for removing nsIDOM* methods that only existed due to 3rd party compat concerns, but I don't think t

Re: Intent to ship: IntersectionObserver API

On 3/15/17 1:30 AM, Tobias Schneider wrote: As of March 14 I intend to turn the IntersectionObserver API on by default on all platforms. This is really exciting stuff! Some questions (largely based on the intent to ship/implement templates, fwiw): 1) Is there devtools support for this (e.g

Re: Intent to ship: IntersectionObserver API

On 3/15/17 1:32 PM, Tobias Schneider wrote: 1) No there isn't any yet. Good idea to file a bug for it tho. OK. Please make sure this happens. 2.1) Its was quite a living spec over the time I implemented things, but stuff seams to stabilize now. https://bugzilla.mozilla.org/show_bug.cgi?id=12

Re: Tracking bug for removals after XPCOM extensions are no more?

On 3/15/17 3:26 PM, Botond Ballo wrote: What will happen to WebExtension Experiments once these APIs start being removed? My understanding is that WebExtension Experiments use the same XPCOM APIs as XUL addons. We shouldn't be removing APIs that have no alternative. But I doubt a WebExtension

Re: Tracking bug for removals after XPCOM extensions are no more?

On 3/15/17 6:51 PM, Benjamin Smedberg wrote: On Wed, Mar 15, 2017 at 4:24 PM, Boris Zbarsky wrote: We shouldn't be removing APIs that have no alternative. As a blanket statement, I don't understand what this means. As a blanket statement, it would depend on an implied "that

Re: Tracking bug for removals after XPCOM extensions are no more?

On 3/15/17 5:35 PM, Henri Sivonen wrote: What's the current outlook on letting chrome JS read ArrayBuffers as opposed to JS strings where the high 8 bits are zero and the low 8 bits are the byte values from XPCOM streams? I see no reason not to allow that. We'd just add this on nsIScriptableI

Re: Will script implementations of nsIOutputStream be prohibited once XPCOM extensions are no more?

On 3/16/17 3:35 AM, Henri Sivonen wrote: Do we need to keep caring about https://bugzilla.mozilla.org/show_bug.cgi?id=170416 once XPCOM extensions are no more? A first glance, no. We should try marking nsIOutputStream builtinclass on trunk right now. As far as I can tell, this should just wor

Re: Tracking bug for removals after XPCOM extensions are no more?

On 3/13/17 11:36 AM, Steve Fink wrote: There's a whitelist of "safe" things that we assume will never be overridden. But now I can remove everything that treats nsISupports specially. Things can still be implemented in chrome JS via XPCWrappedJS, right? Assuming the analysis will consider all

Please do NOT hand-edit web platform test MANIFEST.json files

We have tools for this: "mach wpt-manifest-update" will do the right thing. The typical result of hand-edits is that later changesets that do use the tools end up conflicting with each other, as they all fix up the incorrect hand-edits. Please don't cause this pain for other developers and th

Re: windows build anti-virus exclusion list?

On 3/17/17 3:40 PM, Ted Mielczarek wrote: We do try to build js/src pretty early in the build We do? It's always the last thing I see building before we link libxul. Seeing the js/src stuff appearing is how I know my build is about done... -Boris ___

Re: Posthumous intent to unship: experimental createImageBitmap() overload accepting ArrayBuffer and ArrayBufferView arguments

On 3/18/17 2:09 AM, Anne van Kesteren wrote: I'm not sure this should be unusual though. The unusual thing is unshipping an API that has shipped in release, via direct landing on release, without any sort of deprecation period, going through nightly/aurora/beta, etc. This should in fact be

Re: Please do NOT hand-edit web platform test MANIFEST.json files

On 3/19/17 12:36 AM, Nils Ohlmeier wrote: Wouldn’t it make more sense to let the build system detect and reject/warn about (?) such a manual modification? That would be ideal, but there are some issues with doing it. We tried adding a lint, but it was orange _all the time_ because the sanest

Preferences::RegisterCallback and variants will now do exact, not prefix, matches

I have just landed a change[1] which changes Preferences::RegisterCallback/RegisterCallbackAndCall to do an exact, not prefix, match on the passed-in string. So if you do: Preferences::RegisterCallback(MyFunc, "foo"); and the preference named "foobar" changes, MyFunc will no longer be call

Re: Please do NOT hand-edit web platform test MANIFEST.json files

On 3/21/17 6:41 PM, Jeff Gilbert wrote: JSON allows comments if all the JSON processors we use handle comments. :) JSON.parse in JS does not. The Python "json" module does not as far as I can tell. What JSON processors are you thinking of? -Boris P.S. The Python "json" module is most relev

Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

On 3/21/17 4:34 PM, Eric Rahm wrote: This doesn't affect the behavior of |Preferences::AddStrongObserver| which does prefix matching, correct? That's correct. Same for AddWeakObserver. It's a little harder to misuse because it doesn't have a closure arg (so you can't just associate the total

Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

On 3/21/17 7:18 PM, zbranie...@mozilla.com wrote: Is there a reason we should use RegisterCallback over AddStrongObserver? It doesn't require creating a separate object to act as an observer. Of course it creates one under the hood for you, so this is mostly a matter of whether calling code

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 3/22/17 2:38 PM, Mats Palmgren wrote: Does that sound reasonable? Yes, thank you! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

On 3/22/17 6:17 PM, zbranie...@mozilla.com wrote: On Tuesday, March 21, 2017 at 7:46:07 PM UTC-7, Boris Zbarsky wrote: Are you properly handling the fact that AddStrongObserver watches all prefs starting with the prefix you pass it? ;) I don't, and I'd love not to. I know perfectly

Re: Please do NOT hand-edit web platform test MANIFEST.json files

On 3/22/17 8:11 PM, gsquel...@mozilla.com wrote: (Is the ~10s extra build time unacceptable?) I just checked on my local machine, and a full manifest update takes over a minute. I rather doubt your machine is actually 6x faster than mine, so I have to assume that you didn't actually time a f

Re: Intent to unship: :-moz-bound-element pseudo-class.

On 3/25/17 2:06 PM, Emilio Cobos Álvarez wrote: I don't think there's any benefit of keeping untested and unused stuff in the tree, but if I got it wrong, or anyone has any concern, please speak. Removing this makes sense to me. -Boris ___ dev-platfo

Web IDL review checklist updated

I just updated https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist to remove some no-longer relevant bits and add various new parts. The primary audience for this document are people doing Web IDL reviews (bcced; you can see the list at

Re: Web IDL review checklist updated

On 4/3/17 3:53 PM, Kyle Huey wrote: There should probably be something about checking that the spec is something other vendors are interested in, or that Mozilla has a good reason to go ahead without them. Ah, good point. I added a thing about ensuring that an intent to implement is sent, and

Re: Intent to change editor newline behavior

On 4/5/17 10:14 AM, Aryeh Gregor wrote: On Wed, Apr 5, 2017 at 4:48 PM, Ehsan Akhgari wrote: But to me it seems like the kind of thing that we'd want to be able to quickly turn off on the release channel through shipping a hotfix add-on that sets a pref if something goes wrong... FWIW, changi

A reminder about commit messages: they should be useful

A quick reminder to patch authors and reviewers. Changesets should have commit messages. The commit message should describe not just the "what" of the change but also the "why". This is especially true in cases when the "what" is obvious from the diff anyway; for larger changes it makes sens

Re: A reminder about commit messages: they should be useful

On 4/17/17 10:45 PM, Jim Blandy wrote: It seems like there is actually not a consensus on this. (I had thought Smaug's view was the consensus, and found bz's post surprising.) Really? I know where Olli is coming from, but even in his view a commit message like the one I was talking about is n

Re: A reminder about commit messages: they should be useful

On 4/18/17 3:00 AM, Anne van Kesteren wrote: On Mon, Apr 17, 2017 at 5:16 PM, Boris Zbarsky wrote: A quick reminder to patch authors and reviewers. Is this documented somewhere so you can just point folks to documentation if they get it wrong? Not yet. As this thread shows, there's

Re: A reminder about commit messages: they should be useful

On 4/25/17 10:50 AM, Alexander Surkov wrote: I don't want to affirm that this approach suites every Mozilla module, but it seems be working well in relatively small modules like accessibility one. Just as a counterpoint... as non-regular contributor to the accessibility module, I have a _very

Re: A reminder about commit messages: they should be useful

On 4/25/17 1:07 PM, Alexander Surkov wrote: I bet there's always room for improvements, and I hope this was a counterpoint for the example only, not for the bug organization approach. Sort of. It was a counterpoint to "just check the bug; all the info is there". Often it's not there, or not

Re: A reminder about commit messages: they should be useful

On 4/25/17 4:27 PM, Alexander Surkov wrote: Maybe we should have a style guide, explaining what makes a good commit message and what makes a good and descriptive bug, with number of (good and bad) examples. Yes, we should. Maybe we should have a discussion at the all hands about this... -Bo

Re: Editing vendored crates take #2

On 4/28/17 1:05 PM, Josh Matthews wrote: Has anybody been able to make this work? I _think_ I made it work recently-ish, like so: 1) Modify toolkit/library/rust/Cargo.toml with the relevant [replace] bit. 2) Run "cargo vendor" and watch it fail because of something I never figured out. 3

Re: Editing vendored crates take #2

On 5/2/17 2:54 PM, Josh Matthews wrote: My cargo from April 19 claims that "cargo vendor" isn't a real command. Did you mean `./mach vendor rust` Er, yes, I did. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozill

Re: Representing a pointer to static in XPConnected JS?

On 5/5/17 4:09 AM, Henri Sivonen wrote: On Thu, May 4, 2017 at 7:39 PM, Nathan Froyd wrote: I think you could possibly make your things a WebIDL interface, which don't require refcounting, and magically make the WebIDL interfaces work with XPIDL, but I do not know the details there. I'll keep

Re: Representing a pointer to static in XPConnected JS?

On 5/5/17 2:57 PM, Henri Sivonen wrote: I'm not sure what chrome JS runs on non-main threads and if there's non-main-thread chrome JS doing things like obtain an encoding name from a channel and pass it to the UTF8 converter service. There's nothing like that going on. This seems complicated

Re: Using references vs. pointers in C++ code

On 5/9/17 9:17 AM, Nathan Froyd wrote: On Tue, May 9, 2017 at 5:58 AM, Emilio Cobos Álvarez wrote: Personally, I don't think that the fact that they're not used as much as they could/should is a good argument to prevent their usage, but I don't know what's the general opinion on that. The arg

Re: Using references vs. pointers in C++ code

On 5/9/17 9:03 AM, Bobby Holley wrote: I think passing non-nullable things by reference is good, but I think we should keep it consistent for a given type. I should note that we already have this across all types to some extent: WebIDL bindings pass non-nullable interface types as references,

Re: Using references vs. pointers in C++ code

On 5/9/17 11:41 AM, Nathan Froyd wrote: I think I would feel a little better about this rule if we permitted it only for types that deleted assignment operators. Not sure if that's really practical to enforce. Hmm. I wonder what happens right now if you try to invoke nsINode::operator=

Re: Intent to Ship throttling of tracking timeouts

On 5/11/17 10:59 AM, Andreas Farre wrote: As of 2017-05-15 I intend to turn on throttling of background tracking timeouts by default. For purposes of this feature, what is the definition of "tracking timeout"? -Boris ___ dev-platform mailing list dev

Re: Intent to Ship throttling of tracking timeouts

On 5/11/17 10:30 PM, Eric Shepherd (Sheppy) wrote: So part of private browsing and not a developer-facing feature, then? No, as I understand this is being applied across the board, not just in private browsing, and not just if tracking protection is generally enabled. -Boris

Re: Intent to ship: SourceMap header

On 5/17/17 11:01 AM, Tom Tromey wrote: In this case I think this does not apply, because as far as I'm aware source maps are not part of any standard process; rather there is: https://github.com/source-map/source-map-rfc Are there any plans to have a standard here? It really would be good

Re: Avoiding jank in async functions/promises?

On 5/17/17 9:22 PM, Mark Hammond wrote: I'm wondering if there are any ideas about how to solve this optimally? I assume https://w3c.github.io/requestidlecallback/#the-requestidlecallback-method doesn't have quite the right semantics here? That would let you run when the browser is idle, an

Re: Intent to unship: -moz-placeholder pseudo-element and pseudo-class

On 5/24/17 1:06 PM, Mike Taylor wrote: [1] Sadly, that code is already buggy in Firefox: it uses ":moz-placeholder", which doesn't parse. The thing that parses is ":-

Re: Intent to ship: SourceMap header

On 5/17/17 2:14 PM, Nick Fitzgerald wrote: In my experience, trying to get anyone to comment or provide feedback on source map RFCs was a huge pain, and it felt to me like nobody (other browser devtools teams, maintainers of compilers targeting JS) cared enough about source maps to get involved o

Re: Improving visibility of compiler warnings

On 5/25/17 8:31 AM, Ehsan Akhgari wrote: This currently only serves to make it more difficult to find compiler errors when they occur. Fwiw (and not to distract from your main point), https://bugzilla.mozilla.org/show_bug.cgi?id=1367405 just got fixed so we should no longer get the warning sp

Re: Linux builds now default to -O2 instead of -Os

On 6/1/17 9:04 PM, Mike Hommey wrote: Ah, forgot to mention that. No, it doesn't affect *our* shipped builds (because PGO uses a different set of optimization flags). But it does affect downstream builds that don't PGO. Based on the jump I see on June 2 at https://treeherder.mozilla.org/perf.

Re: JSBC: JavaScript Start-up Bytecode Cache

On 6/13/17 11:00 AM, Dirkjan Ochtman wrote: Has anyone thought about doing similar things for chrome JS? We've been doing fastload for chrome JS (and indeed for entire chrome XUL documents, including their scripts) for 15+ years now, no? -Boris ___

Re: JSBC: JavaScript Start-up Bytecode Cache

On 6/13/17 5:23 PM, Kris Maglione wrote: Yes and no. We do something similar to this for the module loader and subscript loader, but only for the entire compiled source, not for individual functions, and without any kind of lazy compilation. True. For

Re: Changing .idl files

On 6/14/17 12:23 PM, Andrew Swan wrote: I would hope that if we have promising or widely used webextension experiments, that the relevant peers would be aware of them when reviewing changes that might affect them I don't see how they would be, unless we have something like dxr for the relevant

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

On 6/16/17 7:22 AM, Henri Sivonen wrote: My hypothesis is that the JSC/WebKit overhead of returning a string from C++ to JS is much lower than SpiderMonkey/Gecko overhead or the V8/Blink overhead. It definitely is. JSC and WebKit use the same exact refcounted strings, last I checked, so retur

Re: Profiling nightlies on Mac - what tools are used?

On 6/19/17 6:03 PM, Chris Cooper wrote: If you profile on Mac, now is your chance to speak up. What other profiling tools do you use that we should be aware of? Instruments for targeted profiling, though I mostly do that on my own builds, not mozilla.org nightlies. The sampling tool in Activ

Re: Profiling nightlies on Mac - what tools are used?

On 6/19/17 11:22 PM, Gregory Szorc wrote: The decision to strip Nightly builds does not come lightly. Read 1338651 comment 111 and later for the ugly backstory. It's still really confusing to me that not stripping symbols has a significant performance impact. That's not the case in any other

Re: Getting a JS stack from an automation assertion

On 6/20/17 1:53 PM, Benjamin Smedberg wrote: Is there a way to have automation call DumpJSStack() on assertion (before crashing) You could hack a DumpJSStack() call into the nsDebug machinery, basically. Would it be safe to call DumpJSStack() explicitly from the place where I'm firing this as

Re: Profiling nightlies on Mac - what tools are used?

On 6/21/17 10:44 AM, Ehsan Akhgari wrote: It seems like that we have an answer now in the bug! https://bugzilla.mozilla.org/show_bug.cgi?id=1338651#c129 Just for clarity, so people don't have to read the whole bug, changing the _path_ the build is at when it's compiled/linked results in the hu

Re: switch to macosx cross-compiled builds on taskcluster on trunk

On 6/21/17 2:38 PM, Kim Moir wrote: At 11:00PT today, we will be landing patches to run mac opt builds on trunk as cross compiled builds on Linux machines on taskcluster. I just wanted to thank everyone who has worked on this change. I know there were a bunch of nasty obstacles to making this

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

On 6/22/17 4:43 AM, Henri Sivonen wrote: The length of the string is always well over 100, so that already means that a string cache isn't interfering with the test, right? The way the string cache works is that it will reuse an existing JSString* in two situations: 1) The nsStringBuffer* i

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

On 6/22/17 6:19 AM, Henri Sivonen wrote: https://hsivonen.com/test/moz/encoding_bench_web/english-only.html OK, so here's what I'm seeing on that benchmark, all numbers measured on Mac with a current nightly; other platforms may differ, etc. Profile at https://perf-html.io/public/f6a0a4a61ed

Re: Sheriff Survey Results

On 6/23/17 8:39 AM, Carsten Book wrote: We got a lot of Feedback thats its not easy to find out who is on "sheriffduty". We will take steps (like adding |sheriffduty tag to irc names etc) For what it's worth, searching IRC names is a bit of a pain. Can we just throw the current sheriff nick i

Re: Converting const char (&name)[N] to nsACString

On 7/5/17 5:41 AM, nmago wrote: char* cname = new char[N]; memcpy(cname, &name, N); nsACString strName(cname, N, 0); This copies the data twice, and leaks it once, as far as I can tell. What, exactly, are you trying to accomplish? For example, do you need an nsACString that has a copy of you

Re: Phabricator Update, July 2017

On 7/12/17 11:54 AM, Byron Jones wrote: or uploading patches directly to bugzilla. But still rewriting existing links (including from the mirrored review comment comments, so it's clear which diff the review comments applied to), right? -Boris _

Re: Phabricator Update, July 2017

On 7/13/17 9:04 PM, Mark Côté wrote: It is also what newer systems do today (e.g. GitHub and the full Phabricator suite) I should note that with GitHub what this means is that you get discussion on the PR that should have gone in the issue, with the result that people following the issue don'

Re: Phabricator Update, July 2017

On 7/14/17 1:31 AM, Jim Blandy wrote: But keeping all the comments in one thread is a mixed blessing, too Absolutely. I guess what I'm saying is we should try to have some guidelines for when it's appropriate to take the discussion back to the bug instead of continuing it in the review...

Intent to implement and ship: SVGImageElement as CanvasImageSource

Summary: allow passing to canvas createPattern and drawImage. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1382027 Spec: https://html.spec.whatwg.org/multipage/canvas.html#htmlorsvgimageelement and https://html.spec.whatwg.org/multipage/canvas.html#canvasimagesource Platform coverage:

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

On 7/18/17 11:21 PM, Tom Ritter wrote: This will respect the 'svg.in-content.enabled' pref, correct? Respect in what sense? What this will do is that _if_ you have an and you drawImage it to a canvas, that will work, assuming the was loaded. I don't think the pref you mention prevents suc

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

On 7/18/17 11:56 PM, Tom Ritter wrote: Sorry I got the pref name wrong; it's svg.disabled from https://bugzilla.mozilla.org/show_bug.cgi?id=1216893 Ah. So as you note, this pref, when set, makes it so you can't even create an SVGImageElement instance. And then of course you can't pass one to

Re: Converting const char (&name)[N] to nsACString

On 7/21/17 9:44 AM, nmago wrote: Yes, I needed nsACString copy of data to use it as nsACString argument for other function. Assuming "cname" is a char[N] or char*, you should be able to do: nsCString str(cname, N); This will make a copy of the first N bytes of cname and add a null-termina

Re: who uses idl stuff

On 7/23/17 9:58 PM, Enrico Weigelt, metux IT consult wrote: what's the difference between idl and webidl ? Brief summary. IDL: 1) Generates xptcall information for xpconnect to allow calling from JS and into JS (via synthetic vtables). 2) Generates headers that declare pure virtuals. 3)

Re: Actually-Infallible Fallible Allocations

On 8/2/17 11:18 AM, Nathan Froyd wrote: In particular, the API of Sequence<> is constrained because it inherits from FallibleTArray, which *only* exposes fallible operations. We should consider just fixing this. The history here is that FallibleTArray and InfallibleTArray used to bake the all

Re: webidl: partial interfaces and build-time configuration

On 8/6/17 3:56 PM, Enrico Weigelt, metux IT consult wrote: is there a way to use the partial interfaces for build-time configurable features ? Not without #ifdef. Can I move that stuff to a separate webidl file, which is only added in dom/webidl/moz.build when wakelocks enabled ? (so no #ifde

Re: webidl: partial interfaces and build-time configuration

On 8/7/17 11:28 AM, Enrico Weigelt, metux IT consult wrote: hmm, then what are the partial interfaces actually for ? They're for use in specifications that want to add things to an existing interface. They're a specification device, basically. I had the impression that distributing (potent

Re: Changing .idl files

On 6/14/17 9:02 AM, Benjamin Smedberg wrote: Given that old-style addons are going away for 57, if it's possible to delay addon-breaking IDL changes by one release until 57 that's probably the easiest way to deal with this. We're already causing the addon community a lot of churn. I'd like to g

  1   2   3   4   5   6   7   8   9   10   >