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

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

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

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: 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,

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: 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

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

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

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 <bzbar...@mit.edu> 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

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

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

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

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

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

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

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

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

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

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: 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

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

Re: Finalizer for WebIDL object backed by JS impl of an XPCOM interface

On 8/9/17 1:55 PM, Henri Sivonen wrote: I'm thinking of introducing a C++-implemented XPCOM object that the JS-implemented XPCOM object can hold a reference to and that has a C++ destructor that does what I want. Does that mean your action doesn't depend on which exact JS object got

Re: nsIURI API changes - punycode domain names

On 8/9/17 1:43 PM, Daniel Veditz wrote: ​What do web pages do if they want to reflect a pretty URL into their page? Cry, basically. This is the fundamental reason I was opposed to this behavior change, but apparently no other browsers care about this issue and we were getting compat

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

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

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

On 7/5/17 5:41 AM, nmago wrote: char* cname = new char[N]; memcpy(cname, , 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 your

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: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

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

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: 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: Converting const char ()[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

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

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

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

Re: disabled non-e10s tests on trunk

On 8/8/17 5:12 PM, jma...@mozilla.com wrote: In bug 1386689, we have turned them off. There was some surprise in doing this and some valid concerns expressed in comments in the bug. Indeed. Given how often non-e10s mode needs to get used for debugging, it's a little concerning to see the

Re: Changing .idl files

On 8/7/17 6:17 PM, Nicholas Nethercote wrote: Is there going to be a clear point in time when legacy extensions stop working in Nightly? I was under the impression that there is, and I strongly feel there should be. -Boris ___ dev-platform mailing

Re: Changing .idl files

On 8/7/17 11:17 PM, Kris Maglione wrote: There isn't. Not as such, anyway. By the end of the week, legacy extensions that aren't specially signed will be disabled by default. That fits what I want. That being a notification to nightly users that says "These are now officially unsupported; if

Re: disabled non-e10s tests on trunk

On 8/8/17 6:40 PM, Blake Kaplan wrote: What part of the current set-up is rocket science? Debugging pageload. Especially pageload with no session history. In multi, there's definitely a problem figuring out which process is the active one (though tooltips when hovering over tabs can help).

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

Re: Changing .idl files

On 8/7/17 1:05 PM, Kris Maglione wrote: So what is the state of things at the moment? Should we just turn off old-style addons on nightly? If not, then we should probably stop breaking them until we _do_ turn them off. I don't think so. Extension authors know the score here. OK, I thought

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

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

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

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

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: 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

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,

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

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: 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

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: 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

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

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*

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

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

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

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: 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

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

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

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: 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

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

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: 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

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

Re: Re-visiting the DOM tree depth limit in layout

On 9/15/17 6:35 AM, Henri Sivonen wrote: I'm assuming that anonymous frames count towards the limit and a display: table-cell that doesn't belong to a table ends up creating 5 frames. Correct? Yes for both. It creates a table, table-row-group, table-row, table-cell, and a block inside the

Re: Eiminating nsIDOM* interfaces and brand checks

On 9/15/17 9:58 AM, David Bruant wrote: Maybe @@toStringTag will end up not working well enough for your need anyway. Not least because its use is kinda ugly, no? But another solution could be to define a chromeonly symbol for the brand. obj[Symbol.brand] === 'HTMLEmbedElement'

Re: Intent to unship: Visibility of window.content to untrusted code

On 9/14/17 5:47 PM, Kris Maglione wrote: Could we make it non-enumerable and add a counter to the window binding resolve hook? We could. Note that it would also trigger on sets of "window.content" or on "var content" and so forth, though... Not clear how useful the resulting data would be,

Re: Intent to require `mach try` for submitting to Try

On 9/15/17 10:08 PM, Steve Fink wrote: I've never used it, but it already has pretty much exactly this. Look at --save, --preset, and --list-presets under ./mach help try syntax Ah, I see. Alright, I'll give this a shot. -Boris ___ dev-platform

Re: Intent to require `mach try` for submitting to Try

On 9/15/17 6:30 PM, Gregory Szorc wrote: we'd like to require the use of `mach try` for Try submissions. So just to be clear, instead of being able to "hg push -f try" will one now need to do "./mach try syntax ." and put in the actual syntax string on every single try push? The reason

Re: Eiminating nsIDOM* interfaces and brand checks

On 9/4/17 4:51 AM, Anne van Kesteren wrote: Also, do we need this for Promise, Map, Set, etc., or just IDL-defined objects? For the moment, just the latter, I think, in that we have no one who is trying to do if for the former... -Boris ___

Re: TabChild visibility

On 9/20/17 3:18 PM, Mike Conley wrote: it appears to be possible to have a non-visible but active DocShell (despite the documentation [4]). The documentation is kinda wrong. A simple example of an active but non-visible docshell is a display:none iframe in the currently selected tab. I

Re: Intent to unship: Visibility of window.content to untrusted code

On 9/14/17 5:33 PM, Ehsan Akhgari wrote: I think either of these two ideas would be good, but I think unshipping in 57 is premature without having an understanding of how much the Web depends on this for UA sniffing. OK. Do you have any suggestions on how we could gain that understanding? We

Re: Null[C]String() has been renamed Void[C]String()

On 9/22/17 2:41 AM, Nicholas Nethercote wrote: This probably won't affect most people, because void strings are a niche feature. Not in the DOM. They're used anytime you see "DOMString?" in webidl. http://searchfox.org/mozilla-central/search?q=DOMString%3F=webidl shows several hundred hits.

Re: Null[C]String() has been renamed Void[C]String()

On 9/22/17 1:31 PM, Eric Rahm wrote: The problem is these were never a null string, they're a voided empty string. Sure. In the DOM usage, it's "a string that will convert to JS null when converting to 'DOMString?'", and not anything about the string itself being null. Arguably that API

Re: Changes to tab min-width

On 10/3/17 5:18 PM, Boris Zbarsky wrote: So just to make sure I understand the change (and this is a theoretical point, because I haven't had a chance to try the change yet)... OK, now I have had a chance to try it. When set to the new 50px default, I see 1 letter of title or less (less

Re: Changes to tab min-width

On 10/6/17 9:52 AM, Nicolas B. Pierron wrote: I will add that 91% of the session on release have 12 or fewer tabs, and thus would not be concerned at all by these changes. Do we actually know that? As I said upthread, at the 100px tab width my tabs start to scroll when adding the 9th tab.

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On 10/2/17 5:35 PM, Kris Maglione wrote: So far it doesn't look like there's any significant difference on any talos test from adding [NeedsCallerPrincipal] to setAttribute/setAttributeNS/Attr.value, OK. That's a minimum bar, obviously, but I would still like us to measure what the

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

On 10/4/17 3:17 AM, Jan Keromnes wrote: Please report any bugs with the bot here: https://bit.ly/2y9N9Vx Not sure this is a bug, but... I got bugmail today from this bug saying that a patch (not mine; just a bug I was cced on) didn't have any problems. Can we consider having the bot add

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

On 10/4/17 10:32 AM, Jan Keromnes wrote: We've already disabled this "no defects" comment, and are currently deploying the fix to production, so the bot should stop sending them soon. Great, thank you! No need to apologize, by the way. Bugmail noise happens; thank you for moving on it

Re: Changes to tab min-width

On 10/3/17 4:36 PM, Jeff Griffiths wrote: 2. it sets the default value of the tab to 50, previously this value was hard-coded at 100. Jeff, So just to make sure I understand the change (and this is a theoretical point, because I haven't had a chance to try the change yet)... Right now, the

Re: Changes to tab min-width

On 10/10/17 1:11 PM, Jeff Griffiths wrote: This is highly dependent on screen size. It's dependent on window size. And I was just pointing out that the post I was replying to assumes that "12 or fewer tabs" means "not scrolling", whereas we have no obvious data to that effect. That is, we

Re: C++ function that the optimizer won't eliminate

On 10/6/17 5:00 AM, Henri Sivonen wrote: If we don't have one, how should one be written so that it works in GCC, clang and MSVC? Are you OK with it being restricted to a single thread? If so, would something like this work? mutable void* taint; void* black_box(void* foo) { taint =

Re: Intent to Unship: stream decoder for BinHex format

On 10/17/17 5:47 AM, Shih-Chiang Chien wrote: I intent to remove all the code that handling BinHex decoding, i.e. nsBinHex.cpp, from mozilla-central if no other project is using it. The code was originally added for mailnews. See https://bugzilla.mozilla.org/show_bug.cgi?id=81352 Please

Re: Re-visiting the DOM tree depth limit in layout

On 9/11/17 7:41 AM, Henri Sivonen wrote: Frame construction runs recursive algorithms along the depth of the DOM tree. It's not just frame construction. Recursive algorithms are all over the place in layout and DOM code. Frame construction may be a long pole here in terms of crashes due to

Re: Re-visiting the DOM tree depth limit in layout

On 9/11/17 10:08 AM, Henri Sivonen wrote: What kind of style would have the maximum stack frame size? Is display: table-cell enough to trigger the worst case? I suspect that display:table-cell is the worst case, but at only about 70% confidence. That said, I can't think of a worse case

Re: Kris Maglione and Andrew McCreight are now XPConnect Peers

On 9/6/17 7:47 PM, Bobby Holley wrote: Andrew became a peer in May, and Kris become a peer a few minutes ago. Excellent. Congrats to them both! And I do mean congrats, not condolences. ;) -Boris ___ dev-platform mailing list

Intent to unship: Visibility of window.content to untrusted code

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=864845 window.content is a Gecko-specific thing that basically acts like window.top in untrusted code. In chrome it returns the currently selected tab, effectively. I would like to unship window.content for 57; no one else implements it.

Re: Intent to unship: Visibility of window.content to untrusted code

On 9/12/17 5:04 PM, Emilio Cobos Álvarez wrote: I've noticed that this may be used pretty easily for UA detection. Right, that and use in Gecko-only codepaths are the main concerns I considered adding a usecounter, but as you noted it would be affected by window enumeration. We could

Re: indexedDB.open failing silently?

On 9/12/17 5:57 AM, Geoff wrote: What they got instead was: undefined. I actually can't think of a way this could happen... This surely must mean that indexedDB.open is failing but not throwing an exception. Failing in what sense? There _is_ a concept of "uncatchable exception" in Gecko,

Re: Status of deprecating non-secure HTTP

On 9/25/17 3:18 AM, Anne van Kesteren wrote: But it would also be good if we could all communicate this on behalf of Mozilla without caveats. E.g., Chrome might ship worklets soon and being able to object to that happening (specification-wise) on insecure contexts on behalf of Mozilla would be

Re: Status of deprecating non-secure HTTP

On 9/25/17 9:01 AM, Anne van Kesteren wrote: It does not seem hard to come up with solutions to those problems, if we're actually committed to going down this path. If we are, yes. We need to decide whether we are... (E.g., just like globals have isSecureContext, there could be a media

<    2   3   4   5   6   7   8   9   10   >