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

On Fri, Oct 16, 2015 at 6:33 PM, Boris Zbarsky wrote: > On 10/16/15 12:23 PM, Jonas Sicking wrote: >> Should we try to remove support for "Date" from our webidl implementation? > > I would love to do that, yet. Getting there might be complicated. We could maybe special case

Changes to third-party access for Mozilla organizations on GitHub

For security reasons, we will be making changes to third-party application access for Mozilla organizations on GitHub. This means that GitHub applications not run by Mozilla will have to go through a more formal approval process by Mozilla GitHub organization owners before they are added (not

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

WFM. I'll see what I can do about fixing RTCCertificate. I think that the breakage should be minimal if I just change it. On Fri, Oct 16, 2015 at 11:44 AM, Boris Zbarsky wrote: > On 10/16/15 2:00 PM, Martin Thomson wrote: >> >> On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky

Re: Decommissioning "dumbmake"

On Thu, Oct 15, 2015 at 6:37 PM, Nicholas Nethercote wrote: > On Fri, Oct 16, 2015 at 11:37 AM, Bobby Holley > wrote: > > > > |mach build binaries| is much slower for me than the present behavior, > > because I often hack on header files that are

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

On Fri, Oct 16, 2015 at 9:55 AM, Boris Zbarsky wrote: > 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

Virtual crash debugging team to fill in for David Major

Hi all, David Major is leaving Mozilla, so I've formed a virtual team composed of other Mozilla devs with crash debugging skills to fill in for David while we search for a new stability engineer. If you need help analyzing top crashes, you can reach this virtual team at crashde...@mozilla.com A

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 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 like one. An

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: Please do not use the Date type in Web IDL APIs

On Fri, Oct 16, 2015 at 9:30 AM, Boris Zbarsky 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 like one. An integer value is copied when you return it, so

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

On 2015-10-16 12:16 PM, Justin Dolske wrote: On 10/16/15 7:20 AM, Ehsan Akhgari wrote: On 2015-10-15 5:00 PM, Mike Conley wrote: Note that this should not affect Gecko’s behaviour when the is displayed “inline” (for example, when the has a “multiple” attribute, or a “size” attribute with a

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

>> That makes no sense to me! It might make no sense, but it's what Chromium has been shipping for (at least) the last while. Not saying it's right, just saying that's where it is. I've updated my testcase[1] to demonstrate. There is now a click event handler on the "Friday" , and the defaults

Re: Intent to unship: jar: URIs from content

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 case, then `mach test` should be able to

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

On Fri, Oct 16, 2015 at 11:44 AM, Boris Zbarsky wrote: > So if you want to have value type like behavior, use a value type; for now > long long (in IDL terms; Number in JS terms) is good FWIW, when the problems with using Date objects in attributes were raised with TC39, their

Re: PSA: Local static analysis builds on Linux and Mac OS X

On Fri, Oct 16, 2015 at 5:13 AM, Ehsan Akhgari wrote: >> >> Is there an easy way to determine if that package has been installed? > > The easiest way is to turn it on in a build and see if the build succeeds. On my stock Ubuntu 15.04 box it failed... >> And if it's not

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

On Thu, Oct 15, 2015 at 11:00 PM, Mike Conley wrote: > Are there any objections or thoughts about this plan? You should check what the HTML standard says and file an issue if it doesn't match what you want browsers to do. -- https://annevankesteren.nl/

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

On Sat, Oct 10, 2015 at 9:26 PM, wrote: > On Saturday, October 10, 2015 at 4:28:30 AM UTC-7, Mounir Lamouri wrote: >> On Sat, 10 Oct 2015, at 02:02, zbranie...@mozilla.com wrote: >> > On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote: >> > > As far as

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

On Thu, Oct 8, 2015 at 6:10 PM, Mounir Lamouri wrote: > Note that Chrome 46 has a way to work around the white screen while a > page load using a new property in the Manifest. If a website added to > the homescreen on Chrome Android has a background_color information, it >

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

Is that possible to use Cc["@mozilla.org/docshell; 1"] to downloading html URI as blob?

For example, I am using the following code to fetch the mime parsed HTML flie: let messageService = MailServices.messenger.messageServiceFromURI(uri); let docshell = Cc["@mozilla.org/docshell;1"].createInstance(Ci.nsIDocShell); messageService.DisplayMessage(uri, docshell, MailServices.msgWindow,

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

Hi Mike, On 10/15/15 4:00 PM, Mike Conley wrote: That’s when I found out that event behaviour for ’s is not spec’d out, and the way in which events are fired differs widely from browser to browser. I tested Firefox Nightly (non-e10s), Safari, Chrome, Internet Explorer and Edge, and posted my

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

>> Why should the behavior be different with non-drop-down select elements? The difference in behaviour is something that the other browsers _do_ seem to agree upon. When the elements are inline (with the multiple attribute, or size attribute set to > 1), it seems from my testing that all

Re: PSA: Local static analysis builds on Linux and Mac OS X

On 2015-10-16 2:09 AM, Nicholas Nethercote wrote: On Fri, Oct 16, 2015 at 5:13 AM, Ehsan Akhgari wrote: Is there an easy way to determine if that package has been installed? The easiest way is to turn it on in a build and see if the build succeeds. On my stock

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

On 2015-10-15 5:00 PM, Mike Conley wrote: Note that this should not affect Gecko’s behaviour when the is displayed “inline” (for example, when the has a “multiple” attribute, or a “size” attribute with a value greater than 1). I'm only concerned with the dropdown case. Why should the

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

>> You should check what the HTML standard says and file an issue if it> >> doesn't match what you want browsers to do. Unfortunately, the HTML standard doesn't say much with respect to what events elements are supposed to fire, and when. Once we come to a conclusion here, perhaps I'll work

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

On Fri, Oct 16, 2015 at 6:39 AM, Boris Zbarsky wrote: > You should _especially_ not create attributes of type Date. Well, that's interesting. I think that I might have to eat crow: https://github.com/w3c/webrtc-pc/issues/324 I didn't read all the discussion, but what is

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

On Friday, October 16, 2015 at 3:12:05 PM UTC-4, Jonas Sicking wrote: > On Fri, Oct 16, 2015 at 11:44 AM, Boris Zbarsky wrote: > > So if you want to have value type like behavior, use a value type; for now > > long long (in IDL terms; Number in JS terms) is good > > FWIW, when

Re: Intent to unship: jar: URIs from content

On Sat, Oct 17, 2015 at 6:13 AM, 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

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

On Fri, Oct 16, 2015 at 9:20 AM, Martin Thomson wrote: > On Fri, Oct 16, 2015 at 6:39 AM, Boris Zbarsky wrote: >> You should _especially_ not create attributes of type Date. > > > Well, that's interesting. I think that I might have to eat crow: >

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