Re: Intent to implement and ship: document.origin

On 3/18/15 2:39 AM, Anne van Kesteren wrote: On Wed, Mar 18, 2015 at 1:09 AM, Jonas Sicking jo...@sicking.cc wrote: I think making the location object match URLUtils is futile. There's so much weirdness about the location object that I think we should treat it as the special flower that it is.

Re: Intent to deprecate: persistent permissions over HTTP

On 3/16/15 8:10 AM, Aryeh Gregor wrote: What's the use of taking a picture if the user isn't actively using the computer? You get to see whatever the user _is_ doing at the time. You seriously don't see the use of that, especially for nefarious ends? Also, the user will almost certainly

Re: Intent to implement and ship: document.origin

On 3/19/15 3:16 AM, Anne van Kesteren wrote: That is in our implementation Yes, because it was a security bug as specified, iirc. Of course no one else implements searchParams at all, or plans to. But as long as we're talking implementations, last I checked no one else even implemented

Re: RFC: what's the correct behavior for Visual Studio projects and unified builds?

On 3/12/15 5:39 AM, Chris Pearce wrote: Breaking VisualStudio Intellisense also broke most of the code navigation things that make VisualStudio awesome. Chris, So just to make sure the actual question in Nathan's mail is answered: 1) You're saying Intellisense _does_ work in a reasonable

Re: Intent to deprecate: persistent permissions over HTTP

On 3/12/15 6:28 AM, Anne van Kesteren wrote: It does seem like there are some improvements we could make here. E.g. not allow an iframe to request certain permissions. Insofar we haven't already. That doesn't help much; the page can just navigate itself to the attack site instead of loading

Re: Intent to deprecate: persistent permissions over HTTP

On 3/12/15 10:26 AM, Ehsan Akhgari wrote: Well, top level navigation cancels the fullscreen mode, right? The attack scenario I'm thinking is: 1) User loads http://a.com 2) Attacker immediately sets location to http://b.com 3) Attacker's hacked-up b.com goes fullscreen, pretending to still be

Re: Intent to deprecate: persistent permissions over HTTP

On 3/12/15 12:19 PM, Ehsan Akhgari wrote: (Note that the fullscreen API cannot be used outside of user generated event handlers.) Oh, good point. That helps a lot, yes. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to deprecate: persistent permissions over HTTP

On 3/12/15 3:31 PM, Aryeh Gregor wrote: 2) Attacker opens a background tab and navigates it to http://b.com (I can't think of a JavaScript way to do this, but if there isn't one, making a big a href=b.com target=_blank that covers the whole page would work well enough) This is presuming user

Re: Intent to deprecate: persistent permissions over HTTP

On 3/12/15 1:28 PM, Ehsan Akhgari wrote: Another concern with persisting permissions requested from iframes Can we persist them for the pair (origin of iframe, origin of toplevel page) or something? -Boris ___ dev-platform mailing list

Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

On 3/12/15 7:04 PM, Seth Fowler wrote: It looks like it doesn’t anymore, because it works fine in Chrome. Iirc, bugzilla sniffs server-side and sends different things to different browsers. Worth testing in Firefox with multipart/x-mixed support disabled. -Boris

Re: Chrome removed support for multipart/x-mixed-replace documents. We should too.

On 3/12/15 6:37 PM, Seth Fowler wrote: They made main resources that use multipart/x-mixed-replace trigger downloads instead of being displayed. So what gets downloaded is the entire mixed stream, right? The observation that multipart/x-mixed-replace support introduces a lot of complexity

Re: What are your pain points when running unittests?

On 3/12/15 6:51 PM, Jonathan Griffin wrote: What other use cases would you like us to address, which aren't derivatives of the above issues? I ran into a problem just yesterday: I wanted to run mochitest-browser locally, to debug an error that happened very early in the test run startup. So

Re: Propose to remove nsAString::AssignLiteral(const char (aStr)[N])

On 3/1/15 5:04 PM, Xidorn Quan wrote: Hence I think we should remove this method. All callees should use either AssignLiteral(MOZ_UTF16(some string)), or, if don't want to bloat the binary, explicitly use AssignASCII(some string). The latter requires an strlen() that AssignLiteral optimizes

Re: Intent to ship: MouseEvent.offsetX/Y

On 3/2/15 1:00 AM, Chris Peterson wrote: Gecko's offsetX/Y could return doubles, for compatibility with the spec, that are always snapped to whole numbers, for compatibility with other browsers. How, precisely, is this different from returning integers? Remember, this is JS we're talking

Re: Review problems

On 3/19/15 7:07 AM, David Rajchenbach-Teller wrote: - encourage developers to say no, either to high-priority features or to review requests, when they can't cope – this includes emulating bz' I do not accept review requests at the moment; Note that as of a week or so ago Bugzilla has a

Re: Does anybody know how to modify the source code in order to log the executions of the JavaScript functions?

On 1/23/15 10:33 AM, Tomasz wrote: cgThings.append(CGGeneric(' if (JS::CaptureCurrentStack(cx, stack, 1)) { \n')) cgThings.append(CGGeneric('JS::RootedJS::Value source(cx); \n')) Also, this is very very wrong.

Re: Intent to implement and ship extended FormData methods

On 1/29/15 4:56 PM, nsm.nik...@gmail.com wrote: The proposed patch does not add iterator support. Is there a bug tracking adding this? https://xhr.spec.whatwg.org/#interface-formdata I assume something defines what happens if you delete() while sending the formdata and that we implement

Re: Intent to implement and ship FormData on workers

On 1/29/15 5:10 PM, nsm.nik...@gmail.com wrote: Pref: I intend to hide this behind dom.fetch.enabled, which also controls the Fetch specification. May I ask why? This seems like a totally reasonable thing to expose independently of Fetch, and might be good to have it in a release before

Re: PSA: Upcoming changes to the creation of Necko channels

On 4/2/15 10:27 PM, Ehsan Akhgari wrote: Note that for the network connections that are used for our own purposes which do not belong to a specific web page, this value won't be used, so its value doesn't matter in practice, but as convention, please pass RequestContext::Internal/internal. I

Re: Is there anyway to parse XML in other thread?

On 4/3/15 8:35 AM, Xidorn Quan wrote: I think you can use XMLHttpRequest in a worker This actually proxies all the work to the main thread. The answer to the original question is that all the DOM code is very much main-thread-only right now. -Boris

Re: Is there anyway to parse XML in other thread?

On 4/3/15 9:31 AM, 罗勇刚(Yonggang Luo) wrote: Don't know if we can compile c expat to asm.js to running in a worker. If you just want an XML parser in JS, there are various options out there which are significantly more usable (and possibly faster) than trying to shoehorn expat into JS.

Re: Is MOZ_SHARK still used?

On 4/3/15 12:57 PM, Syd Polk wrote: We recently ran numbers on our user base (like about 3 weeks ago), and found that 10.10, 10.9 and 10.6 all had greater than 10% share of our Mac user base. 10.6 was still close to 19%. Right, but the question is how many people on 10.6 are (1) compiling

Intent to implement and ship: document.scrollingElement

Summary: A property that makes it possible for web pages to tell which element's scroll* attributes reflect the viewport scroll state. This is needed because currently web pages have different codepaths (using document.body vs document.documentElement) for different browsers based on UA

Re: Intent to deprecate: Insecure HTTP

On 4/13/15 5:11 PM, bryan.beic...@gmail.com wrote: After loosing a few forum posts or wiki edits to this bug in Firefox, you quickly insist on using unsecured HTTP as often as possible. This is only done in cases in which the page explicitly requires that nothing about the page be cached

Re: Intent to deprecate: Insecure HTTP

On 4/14/15 3:28 AM, Anne van Kesteren wrote: On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost kdub...@mozilla.com wrote: 1. You do not need to register a domain name to have a Web site (IP address) Name one site you visit regularly that doesn't have a domain name. My router's configuration UI.

Removing cruft preferences

We have a bunch of preferences controlling web-exposure of various things that are always true. canvas.path.enabled, for example. Some of these are there so that users or redistributors can turn off certain features, but some are just leftover cruft from when we used to only support the

Re: A question about do_QueryInterface()

On 4/30/15 2:25 PM, ISHIKAWA, Chiaki wrote: Is this to be expected? Sure. You're taking an _output_ stream and QIing it to nsI_Input_Stream. It might happen that some objects implement both interfaces (and looks like nsMsgFileStream does). The object returned by NS_BufferOutputStream does

Re: Using rust in Gecko. rust-url compatibility

On 5/1/15 12:41 PM, Jet Villegas wrote: I think the plan was to improve security and dogfood rust. If we're also signing up to increase spec compliance as part of the rewrite, that should be called out as an explicit goal--with a plan for dealing with non-compliant sites. And outright spec

Re: Using rust in Gecko. rust-url compatibility

On 5/5/15 9:58 PM, Doug Turner wrote: Performance. Note that performance has been a recurring problem in our current URI code. It's a bit (10%) slower than Chrome's, but about 2x slower than Safari's, and shows up a good bit in profiles. Some of this may be due to XPCOM strings, of

Re: Using rust in Gecko. rust-url compatibility

On 5/6/15 4:28 AM, David Rajchenbach-Teller wrote: Not sure that's part of the benchmarks, but creating a file:// or chrome:// URI currently causes main thread I/O (bug 890712, iirc). My measurements were on http:// URIs. And yes, others are even slower because of the protocol handler

Re: Intent to implement: Frame Timing API

On 5/11/15 3:32 PM, Ehsan Akhgari wrote: You can have style like: a href=...some content that is expensive to paint/composite/a and then have; a { display: none; } a:visited { display: inline; } And then time the painting/compositing of the said content. No, you can't. We

Re: Intent to implement: Frame Timing API

On 5/11/15 7:03 PM, Ilya Grigorik wrote: Boris, any chance you can also take a look at scenario in: https://github.com/w3c/frame-timing/issues/40#issuecomment-9795 For the situation described there, it seems like the right mitigation, conceptually, is to repaint the link when the href

Re: PSA: The mochitest ise() function is dead, please use is() instead

On 5/14/15 8:03 AM, Mike de Boer wrote: Same goes for Gecko wrapper objects, like `window`. When you want to use `deepEqual` with those, anyone should feel free to add support for it! Here's the thing. When comparing window objects, in what sense would anything other than === be useful?

Re: Changing the style guide's preference for loose over strict equality checks in non-test code

On 5/14/15 1:35 PM, Gijs Kruitbosch wrote: var foo = [1,2,3]; window.open('bar.html', '_blank', '', foo); in bar.html, checking the type of foo using instanceof with Array fails. For builtin Arrays we now have isArray, but this does not work for custom JS classes or DOM elements. Actually,

Re: PSA: The mochitest ise() function is dead, please use is() instead

On 5/13/15 7:35 PM, Gregory Szorc wrote: I would steer people in the direction of Assert.jsm, specifically Assert.deepEqual This should be used very very carefully. As a very simple example, using this (or worse yet notDeepEqual) in any test that tries to check for equality of Window objects

Re: Intent to deprecate: Insecure HTTP

On 4/14/15 11:53 AM, justin.kru...@gmail.com wrote: Dynamic DNS might be difficult to run on HTTPS as the IP address needs to change when say your cable modem IP updates. Justin, I'm not sure I follow the problem here. If I understand correctly, you're talking about a domain name, say

Re: New Developer Tools Feature: prettifying JSON

On 4/15/15 12:54 PM, Jan Odvarko wrote: This approach has one security implication, if the page uses default-src 'none' (or other security restrictions?) - injecting JS into it generates warnings: Content Security Policy: The page's settings blocked the loading of a resource at self (default-src

Re: New Developer Tools Feature: prettifying JSON

On 4/16/15 4:52 AM, Gijs Kruitbosch wrote: but that would still require that application/json loads as text in the browser, which I think it currently doesn't? Totally does ever since https://bugzilla.mozilla.org/show_bug.cgi?id=667533 (so about 3.5 years ago). ;) -Boris

Re: New Developer Tools Feature: prettifying JSON

On 4/16/15 4:30 AM, Frederik Braun wrote: Running our code in someone else's origin sounds undesired indeed. Not only because of CSP: What if someone puts this in a frame (or a popup) and interacts with this JSON viewer? So the way the XML viewer handles this is basically the following: 1)

Re: New Developer Tools Feature: prettifying JSON

On 4/16/15 4:37 AM, Jan Odvarko wrote: We are obviously trying to avoid C++ code in devtools Sure. We can add scriptable APIs as needed. For example, we already have one for adding anonymous content, right?. Not sure if there is yet another way how to manipulate content with a script

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On 4/12/15 2:58 AM, Anne van Kesteren wrote: On Sat, Apr 11, 2015 at 12:23 AM, Jonas Sicking jo...@sicking.cc wrote: Is there a reason to upgrade to File? I thought it'd be good to keep the object identities the same as much as possible (except for the sequence object itself of course). FWIW,

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On 4/11/15 4:53 AM, Jonas Sicking wrote: So that C++ callers, which go through the xpidl interface, would still get a real File wrapping the Blob C++ callers don't go through the xpidl interface. Though if we're only worried about internal C++ callers Precisely. -Boris

Re: PSA: Upcoming changes to the creation of Necko channels

On 4/6/15 1:29 PM, Ehsan Akhgari wrote: The current patches do not provide a default value. Well, they do for callers of newChannel(), right? Which is what extensions do -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On 4/10/15 6:23 PM, Jonas Sicking wrote: Is there a reason to upgrade to File? Yes. FileList claims to return Files. We could change that to have it return Blobs, of course, and then make sure that various consumers (at least the internal ones) can deal. -Boris

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On 4/10/15 7:43 PM, Jonas Sicking wrote: One option is to make the xpidl interface always return a File, but make the .webidl interface return files or blobs. Why, exactly? If we want to do this, just have them both return a Blob in terms of the IDL. If it happens to be a Blob that's also a

Re: Intent to implement and ship: Settable .files attribute on HTMLInputElement

On 4/10/15 10:15 PM, Boris Zbarsky wrote: I'm more worried about internal C++ consumers, honestly. Have to audit them all to make sure they're not assuming they can get a filename and such. For example, HTMLInputElement::GetValueInternal or HTMLInputElement::AfterSetFiles will do mFiles[0

Re: Intent to implement and ship: User timing API in workers

On 5/20/15 1:16 PM, Andrea Marchesini wrote: Link to standard: http://www.w3.org/TR/user-timing/ This standard does not define this API in workers. Have you reached out to the working group already? -Boris ___ dev-platform mailing list

Re: The War on Warnings

On 6/4/15 6:14 PM, Ehsan Akhgari wrote: They are both equally slow, but fatal assertions happen only once, by definition. ;-) Except that for some of our tests we restart after a crash (e.g. for web platform tests). So in that test harness, fatal assertions that are hit are much slower

Re: The War on Warnings

On 6/8/15 4:28 PM, David Rajchenbach-Teller wrote: Last time I looked at whitelisting non-fatal assertions, there was only the option to accept up-to a number of assertions. You can specify an exact number or a range. But you're right that you can't specify the assertion text involved...

Re: nsIAboutModule::URI_SAFE_FOR_UNTRUSTED_CONTENT and add-on chrome

On 6/8/15 6:57 AM, Geoff Lankow wrote: If I have an about page marked URI_SAFE_FOR_UNTRUSTED_CONTENT, it happily loads css/js from chrome://browser (in fact, about:home does this), but throws a security error loading from chrome://foo. Is this intentional? Whether untrusted content can load

Re: Use of 'auto'

On 6/2/15 6:12 PM, Seth Fowler wrote: If you write this: auto val = Bar(); Foo(val); I think to preserve the semantics of Foo(Bar()) you need: auto val = Bar(); Foo(val); but apart from that nit, I totally agree. -Boris ___ dev-platform

Re: Proposed W3C Charter: Web Performance Working Group

On 6/12/15 3:08 PM, L. David Baron wrote: http://www.w3.org/2015/05/webperf-charter.html So I have two main comments on the way this working group is operating. Not sure how these can/should be reflected in the charter. 1) The deliverables and their interrelationships are a bit of a

Re: Revisiting modelines in source files

On 6/17/15 6:53 AM, Mike Hommey wrote: - emacs has the same security implication, and AIUI, opening a file with a modeline makes emacs ask questions to the user. Or ignore them in batch mode. That depends on what's in the modeline. Pretty sure our typical Mode: C++; tab-width: 8;

Re: Revisiting modelines in source files

On 6/17/15 10:01 AM, Mike Hommey wrote: modelines don't express those half-indent either. Also, they're not in the mozilla codying style, which, by the way uses 2-spaces indentations, not 4-spaces. Note that SpiderMonkey is almost entirely 4-space indent. mozilla~% grep -r c-basic-offset: 4

Re: Secure contexts required for new web platform features

On 7/1/15 2:49 AM, Anne van Kesteren wrote: Platform. There was no strong opposition to the Intent to deprecate: Insecure HTTP thread and in Whistler everyone attending the deprecating non-secure HTTP session agreed. Do you think this needs to be approached differently? Yes. Because taken at

Re: Secure contexts required for new web platform features

On 7/1/15 4:43 AM, Anne van Kesteren wrote: I hope that we can get somewhat better on this. It is rather useful to have a somewhat large set of people have insight as to what goes into Platform. Sure. I'm just saying that I suspect people underestimate the number of features we add, the

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On 7/7/15 11:49 AM, Mike Conley wrote: I suspect that knowing what things were passed into a method or function is something that can be divined via static analysis. Aren't there tools for our (admittedly varied) editors / IDEs And debuggers. And dxr and blame views? -Boris

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On 7/7/15 11:36 AM, Jeff Muizelaar wrote: FWIW, I did a quick poll of the people in our Gfx daily. Here are the results: To add some more split opinions to the situation, I rather like the aArgument form precisely because it makes it easier to trace dataflow. Though the fact that some

Re: New Telemetry dashboards!

On 7/7/15 2:26 PM, Vladan Djeric wrote: Let us know if you find bugs, notice missing functionality, or if anything is ambiguous or counter-intuitive. When I first load https://telemetry.mozilla.org/ it says, in the console: ReferenceError: CustomSelector is not defined dashboard.js:674:5

Re: Secure contexts required for new web platform features

On 6/30/15 5:00 PM, Richard Barnes wrote: Second, when we implement new web platform features, they will be enabled only on secure contexts. Might I ask who this we is (I don't recall general DOM module owner buy-in on this, but maybe I missed it?) what the definition of new web platform

Re: Use of 'auto'

On 8/2/15 7:34 AM, Hubert Figuière wrote: This is also part of why I'd suggest having an construction method that will return a smart pointer - preventing the use of raw pointers. Returning an already_AddRefed would prevent the use of raw pointers, but would leak if the caller used auto,

Re: Implement Fetch?

On 7/23/15 11:36 AM, Anne van Kesteren wrote: By SVG resource document do you mean one that is fetched as an image? In Gecko's case I specifically mean one fetched as a paint server. It's somewhat of an implementation detail, possibly; the reason we do it is that we had a bunch of code that

Intent to implement: disallowing definition of non-configurable properties on a window

A bit belated, since I just landed this on inbound, but... Summary: In ES2015, there is a certain set of invariants that an object is supposed to maintain. One of those is that a non-configurable property can't just disappear. Window objects obviously can't maintain that invariant, so they

Re: Should the entire JS structure be Object.freeze()'d if it's exposed through a read only property?

On 7/13/15 2:40 AM, Tim Guan-tin Chien wrote: In that case, the right question to ask would be (A) should DOMApplication#manifest be a recursive frozen JS structure Is it a plain vanilla object with nothing hanging off it that has getter/setters? If so, that would not be unreasonable. and

Re: Intent to implement HTMLMediaElement.srcObject partially

On 7/15/15 3:42 PM, Jan-Ivar Bruaroey wrote: This means it will support get/set of: MediaStream objects. This means it will throw TypeError on set of: MediaSource objects, Blob objects, and File objects, for now. Jan-Ivar, Do you happen to know whether other UAs support this unprefixed and

Re: Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)

On 7/16/15 11:33 PM, Mike Taylor wrote: Will we ever run into the same problems with unprefixing rAF raised on blink-dev[1]? I see 932322 was partially backed out and 943958 seems to describe the `var requestAnimationFrame = window.requestAnimationFrame` problem. Mike, Thank you for checking

Re: Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)

On 7/16/15 9:04 PM, Boris Zbarsky wrote: On 7/16/15 8:34 PM, Kyle Huey wrote: There are a handful of uses in Gaia. Oh, gah. I keep forgetting gaia's on a separate mxr repo. I'll get together a pull request. Good catch. Actually, I just looked, and I had in fact checked on those

Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)

Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=909154 APIs to be removed: mozRequestAnimationFrame, mozAnimationStartTime, mozCancelAnimationFrame. As of today, they are not used in our tree. Web compat impact for mozRequestAnimationFrame/mozCancelAnimationFrame: Not known for

Re: Intent to unship: Prefixed mozRequestAnimationFrame and related APIs (mozAnimationStartTime, mozCancelAnimationFrame)

On 7/16/15 8:34 PM, Kyle Huey wrote: There are a handful of uses in Gaia. Oh, gah. I keep forgetting gaia's on a separate mxr repo. I'll get together a pull request. Good catch. -Boris ___ dev-platform mailing list

Re: W3C Proposed Recommendations: Canvas 2D Context & W3C DOM4

On 10/20/15 6:13 PM, L. David Baron wrote: Two W3C Proposed Recommendations are available for the membership of W3C (including Mozilla) to vote on, before they proceed to the final stage of being W3C Recomendation: Do you happen have links to the test suite results for these? -Boris

Re: Intent to ship: WebVR

On 10/29/15 1:10 PM, vladi...@mozilla.com wrote: The intent to ship here is a bit premature; the intent is to pref it on in nightly & aurora, not ship it all the way to release. OK. The patches in the "enable it" bugs are enabling on all branches; we should probably scale that back to just

Re: Merging comm-central into mozilla-central

On 10/23/15 8:32 PM, Robert O'Callahan wrote: I support merging c-c into m-c. For what it's worth, I do as well. Of course I also do some due diligence about not breaking Thunderbird before landing patches, just like I do for Firefox extensions and whatnot and I feel that that is the

Re: Merging comm-central into mozilla-central

On 10/27/15 3:17 PM, Joshua Cranmer  wrote: [1] An example from just this morning is the emasculation of nsIDOMWindow. It's clear at this point that all of our binary code has to be linked into libxul Why can you not use nsPIDOMWindow? If there are particular APIs it's missing that you

Re: Merging comm-central into mozilla-central

On 10/27/15 3:55 PM, Joshua Cranmer  wrote: We did replace our uses with nsPIDOMWindow, but it's an example of an API that can be used external to libxul being replaced with one that can't be. Just to be clear, we're happy to make things on nsPIDOMWindow virtual or exported as needed to the

Re: Where can i download firefox-sdk

On 11/8/15 3:56 PM, ales.rozman...@gmail.com wrote: Because we use gecko internals in the component. A bunch of nsI* classes. I believe that's the part that's not supported. You can have a binary blob that's self-contained and that you talk to via ctypes, but it shouldn't be touching nsI*.

Re: W3C Proposed Recommendations: Canvas 2D Context & W3C DOM4

On 11/2/15 1:43 AM, L. David Baron wrote: Based on this feedback, my current intention is to explicitly abstain from the review, with the following comment: That sounds great, thanks! -Boris ___ dev-platform mailing list

Re: Please do not use the Date type in Web IDL APIs

On 10/16/15 2:00 PM, Martin Thomson wrote: On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: I'm not sure what custom code you're talking about. What exactly are you proposing? Date is fundamentally just an integer when you get down to it. Treat it li

Re: Intent to unship: jar: URIs from content

On 10/16/15 1:13 PM, Gregory Szorc wrote: On Thu, Oct 15, 2015 at 4:08 PM, Robert O'Callahan wrote: I'm sad that I won't be able to use jar: URLs to load testcases in ZIP files uploaded to Bugzilla, but this sounds like the right thing to do. If this is a common use

Re: Please do not use the Date type in Web IDL APIs

On 10/16/15 12:54 PM, Anne van Kesteren wrote: We could maybe special case the existing usage and prevent new usage? Yes. Most simply by renaming it in our bindings to LegacyDateDoNotUse. ;) But that involves reviewers catching new uses, hence this thread. -Boris

Re: Decommissioning "dumbmake"

On 10/18/15 7:14 PM, Nicholas Nethercote wrote: Eventually |mach build| should just do the right thing, no matter what files you've touched... The problem is that definitions of "right thing" differ depending on the goal, right? -Boris ___

Please do not use the Date type in Web IDL APIs

This is especially a reminder to reviewers, but also to anyone participating in spec discussions. For context, see . You should consider the Date type deprecated and not use it in new specifications. You should _especially_ not create

Re: Intent to unship: jar: URIs from content

On 10/19/15 4:07 PM, Gregory Szorc wrote: Or you could register a custom content type handler (possibly via a special "Gecko Hackers" Firefox add-on) that runs an appropriate mach command when said file is downloaded. This ignores the point about running the file after downloading having

Re: Intent to implement and ship: webkitMatchesSelector

On 10/19/15 12:46 PM, Anne van Kesteren wrote: On Mon, Oct 19, 2015 at 6:36 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: Summary: The web more or less depends on one of the prefixed versions of matchesSelector (being implemented). I think you mean matches() is being implemented, while t

Re: Please do not use the Date type in Web IDL APIs

On 10/16/15 12:20 PM, Martin Thomson wrote: https://github.com/w3c/webrtc-pc/issues/324 Yes, that is what prompted my mail. ;) I didn't read all the discussion, but what is wrong with treating Date as a primitive type that happens to have methods? The fact that in JS it's not? It's an

Re: mozilla::RefPtr is dead, long live ::RefPtr

On 10/18/15 10:43 AM, Nathan Froyd wrote: Bug 1207245 has landed on mozilla-central. Are we sure enough this will stick that we should update documentation (e.g. ) to refer to RefPtr instead of nsRefPtr? -Boris

Re: mozilla::RefPtr is dead, long live ::RefPtr

On 10/18/15 11:11 AM, Kyle Huey wrote: When are you going to do nsCOMPtr? ;) Are we sure there is no codesize hit when moving from nsCOMPtr (which tries to share implementation via nsCOMPtr_base) to RefPtr? -Boris ___ dev-platform mailing list

Intent to implement and ship: webkitMatchesSelector

Summary: The web more or less depends on one of the prefixed versions of matchesSelector (being implemented). We might as well implement the webkit one and drop the moz one. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1216193 Standard:

Re: Shortening Crash Signatures: Dropping Argument Lists

On 10/13/15 2:11 PM, Robert Kaiser wrote: Please let me know of any issues with those changes (as well as any other questions about or issues with crash analysis), and thanks to Lars, Byron (glob) and others who helped with those changes! Just to make sure, crash-stats will still have the full

Re: Should the entire JS structure be Object.freeze()'d if it's exposed through a read only property?

On 7/9/15 4:48 AM, Tim Guan-tin Chien wrote: In this case, I modified the manifest object passed from mozApp API, and the object was subsequently removed by the platform, so did my modifications. Fabrice said I should not be modified the object since it's marked as read only in WebIDL.

Re: Allowing web apps to delay layout/rendering on startup

On 8/6/15 4:09 AM, Jonas Sicking wrote: Agreed. Would it work to define that they behave like inside of a display:none layout tree? Or will that still force some cascade calculations to happen? If you getComputedStyle then you'll still end up doing style computation in display:none subtrees.

Re: I think XUL overlays should also ignore query strings.

On 8/17/15 2:06 PM, Philip Chee wrote: Yes we now have a CloneIgnoringRef. How difficult is it to make a clone-ignoring-query? More difficult than one would assume, because any time nsIURI is changed we have to jump through hoops to keep the serialization/deserialization code in principals

Re: Selectors to Standardize

On 8/19/15 4:33 PM, fantasai wrote: :-moz-first-node :-moz-last-node These are only used as part of our quirks stylesheet. That said, the quirks mode spec may need something like these or an equivalent. -Boris ___ dev-platform mailing list

Re: StructuredCloneHelper

On 9/4/15 4:12 AM, Andrea Marchesini wrote: 1. we had many postMessage() methods fully out of sync in terms of which clonable/transferable objects we were supporting. Now MessagePort, BroadcastChannel, window and worker and (partially) IPC share the same code base. Thank you for doing that!

Re: Alternative to Bonsai?

On 9/15/15 11:11 AM, Ben Hearsum wrote: I'm pretty sure https://github.com/mozilla/gecko-dev has full history. Though note that it doesn't have working blame for a lot of files in our source tree (and especially the ones you'd _want_ to get blame for, in my experience), so it's of pretty

Re: Alternative to Bonsai?

On 9/16/15 2:01 PM, Ehsan Akhgari wrote: Out of curiosity, which files are you mentioning here? Here are some lovely links that all produce "This blame took too long to generate. Sorry about that." for me:

Re: Alternative to Bonsai?

On 9/16/15 3:02 PM, Jeff Muizelaar wrote: Blame does work on those files locally. Sure. Locally everything is fine. As soon as there is good integration between dxr/mxr and local stuff, and as soon as I can send someone a sane text representation of a local blame display, we can just drop

Re: Alternative to Bonsai?

On 9/16/15 2:38 AM, Philip Chee wrote: But we don't have a working CVS repository any more right? I could be confused, but I believe the CVS repo exists. It can certainly be used in a read-only mode. I don't know whether it allows commits. -Boris

Re: Changes in chrome JS code due to ES6 global lexical scope

On 9/17/15 8:26 PM, Shu-yu Guo wrote: ​The first call to f() does not throw. It actually does, because the bareword lookup for "x" fails. You get "ReferenceError: x is not defined". If you replaced "x" with "window.x" or "self.x" or "this.x" or something I think you'd get the behavior you

Re: Content sniffing: seeking reliable protection of a text HTTP resource

On 10/1/15 5:36 PM, Incnis Mrsi wrote: First is “media type (a.k.a. MIME) sniffing”, when browser overrides media type/subtype. This is implemented in toolkit/components/mediasniffer/nsMediaSniffer.cpp component (and possibly others, don’t know). Note that these are generally very conservative

Re: Intent to implement and ship: FIDO U2F APIU

On 12/2/15 5:42 PM, Ryan Sleevi wrote: On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote: I don't understand how 1) could be implemented when the spec has left the key piece undefined, as far as I see. As the spec puts it "This specification does not describe how such a port is

<    1   2   3   4   5   6   7   8   9   10   >