Re: Standardized assertion methods

On 2014-06-06, 10:31 PM, Jonas Sicking wrote: But rather than making the implementation of is() be more complex and/or more relaxed, could we instead convert those tests to either is_relaxed(a, b) or ok(a == b) Yes, we could. It's a largish number of tests (several hundred; a number have mult

Re: Standardized assertion methods

On 2014-06-06, 4:11 PM, Boris Zbarsky wrote: On 6/6/14, 3:19 PM, Ehsan Akhgari wrote: Can we make is() do those checks explicitly and if neither of these cases apply, fall back to a non-strict equality check? Yes. As in, we could make it special-case the number-to-string compare and use == fo

Re: Standardized assertion methods

On Fri, Jun 6, 2014 at 7:10 PM, Boris Zbarsky wrote: > On 6/6/14, 8:42 PM, Jonas Sicking wrote: >> >> I definitely understand that it'll be a pain to convert existing tests >> that rely on the relaxed matching. > > > Yes. We have about 3300 failing test assertions with is() using ===, and > the v

Re: Standardized assertion methods

On 6/6/14, 8:42 PM, Jonas Sicking wrote: I definitely understand that it'll be a pain to convert existing tests that rely on the relaxed matching. Yes. We have about 3300 failing test assertions with is() using ===, and the vast majority are string-vs-number. All I'm saying is that we could

Re: Standardized assertion methods

On Fri, Jun 6, 2014 at 1:11 PM, Boris Zbarsky wrote: > On 6/6/14, 3:19 PM, Ehsan Akhgari wrote: >> >> Can we make is() do those checks explicitly and if neither of these >> cases apply, fall back to a non-strict equality check? > > > Yes. As in, we could make it special-case the number-to-string

Re: Intent to implement: DOMMatrix

On Jun 6, 2014, at 11:38 PM, Rik Cabanier wrote: > > > > On Fri, Jun 6, 2014 at 2:34 PM, Dirk Schulze wrote: > > On Jun 6, 2014, at 11:22 PM, Rik Cabanier wrote: > > > > > The issue is not that "isIdentity()" is confusing. The problem is that you > > shouldn't make decisions based on it.

Re: Intent to implement: DOMMatrix

On Fri, Jun 6, 2014 at 2:34 PM, Dirk Schulze wrote: > > On Jun 6, 2014, at 11:22 PM, Rik Cabanier wrote: > > > > > The issue is not that "isIdentity()" is confusing. The problem is that > you > > shouldn't make decisions based on it. From earlier in the thread: > > > > The isIdentity() method ha

Re: Intent to implement: DOMMatrix

On Jun 6, 2014, at 11:22 PM, Rik Cabanier wrote: > > The issue is not that "isIdentity()" is confusing. The problem is that you > shouldn't make decisions based on it. From earlier in the thread: > > The isIdentity() method has the same issue as was described about is2D() > above: as matrices

Re: Intent to implement: DOMMatrix

On Jun 6, 2014, at 11:10 PM, Neil wrote: > Rik Cabanier wrote: > >> 1. isIdentity() >> We settled that this should mean that the matrix was never changed to a non >> identity state. >> > Are you doing something similar for the 2d/3d case? This is already in the specification[1]. As Rik menti

Re: Intent to implement: DOMMatrix

On Fri, Jun 6, 2014 at 2:10 PM, Neil wrote: > Rik Cabanier wrote: > > 1. isIdentity() >> We settled that this should mean that the matrix was never changed to a >> non identity state. >> >> Are you doing something similar for the 2d/3d case? Yes, once a matrix becomes 3d, it will always be a

Re: Intent to implement: DOMMatrix

On Fri, Jun 6, 2014 at 1:52 PM, Kip Gilbert wrote: > > On 2014-06-06, 1:23 PM, Rik Cabanier wrote: > > >> >> >> On Fri, Jun 6, 2014 at 12:18 PM, Kip Gilbert > > wrote: >> >> Hello, >> >> From a game programmer's perspective, isIdentity would normally be >>

Re: Intent to implement: DOMMatrix

Rik Cabanier wrote: 1. isIdentity() We settled that this should mean that the matrix was never changed to a non identity state. Are you doing something similar for the 2d/3d case? -- Warning: May contain traces of nuts. ___ dev-platform mailing lis

Re: Intent to implement: DOMMatrix

On 2014-06-06, 1:23 PM, Rik Cabanier wrote: On Fri, Jun 6, 2014 at 12:18 PM, Kip Gilbert > wrote: Hello, From a game programmer's perspective, isIdentity would normally be used to cull out work. In these cases, it is expected that isIdentity wi

Re: Intent to implement: DOMMatrix

On Jun 6, 2014, at 10:23 PM, Rik Cabanier wrote: > On Fri, Jun 6, 2014 at 12:18 PM, Kip Gilbert wrote: > >> Hello, >> >> From a game programmer's perspective, isIdentity would normally be used to >> cull out work. In these cases, it is expected that isIdentity will return >> true only when t

Re: Intent to implement: DOMMatrix

On Fri, Jun 6, 2014 at 12:18 PM, Kip Gilbert wrote: > Hello, > > From a game programmer's perspective, isIdentity would normally be used to > cull out work. In these cases, it is expected that isIdentity will return > true only when the matrix is exactly equal to the identity matrix. Due to > t

Re: Standardized assertion methods

On 6/6/14, 3:19 PM, Ehsan Akhgari wrote: Can we make is() do those checks explicitly and if neither of these cases apply, fall back to a non-strict equality check? Yes. As in, we could make it special-case the number-to-string compare and use == for that, and use === for everything else. -B

Re: Standardized assertion methods

On 2014-06-06, 1:35 PM, Boris Zbarsky wrote: On 6/6/14, 12:21 PM, Boris Zbarsky wrote: That will be the big question, yes. https://tbpl.mozilla.org/?tree=Try&rev=e26ab6d5e1e0 says we have quite a number of things that are in fact assuming that 5 and "5" should test is(). I'm not sure how much

Re: Intent to implement: DOMMatrix

Hello, From a game programmer's perspective, isIdentity would normally be used to cull out work. In these cases, it is expected that isIdentity will return true only when the matrix is exactly equal to the identity matrix. Due to the nature of floating point, the isIdentity will only likely

Re: Standardized assertion methods

On 2014-06-05, 2:08 AM, Boris Zbarsky wrote: On 6/4/14, 11:30 PM, Gavin Sharp wrote: - benefits to shared API/implementation seem uncontroversial Agreed. - specifically, consistency between mochitest/SimpleTest-based harnesses (mochitest-plain/mochitest-chrome/mochitest-browser) and xpcshell

Re: Standardized assertion methods

On 6/6/14, 12:21 PM, Boris Zbarsky wrote: That will be the big question, yes. https://tbpl.mozilla.org/?tree=Try&rev=e26ab6d5e1e0 says we have quite a number of things that are in fact assuming that 5 and "5" should test is(). I'm not sure how much I like throwing in tons of toString() for

Re: DOMWindowCreated not fired for some frames

On Friday, June 6, 2014 6:49:55 PM UTC+2, Boris Zbarsky wrote: > That shouldn't be an issue. The cycle collector should handle it. Just > make sure you don't have a reference to that event handler on any > long-lived chrome objects. OK well I'm using beforescriptexecute and hopefully it should

Re: Intent to implement: DOMMatrix

On Jun 6, 2014, at 6:12 PM, Rik Cabanier wrote: > > > > On Fri, Jun 6, 2014 at 8:57 AM, Milan Sreckovic > wrote: > On Jun 5, 2014, at 18:34 , Rik Cabanier wrote: > >> On Thu, Jun 5, 2014 at 3:28 PM, Robert O'Callahan >> wrote: >> >>> On Fri, Jun 6, 2014 at 9:07 AM, Rik Cabanier wrote:

Re: DOMWindowCreated not fired for some frames

On 6/6/14, 12:42 PM, Matthew Gertner wrote: On Friday, June 6, 2014 6:33:27 PM UTC+2, Boris Zbarsky wrote: The about:blank document is quite real, sadly... From what I'm seeing, the document object that ends up there (window.document) is not the same one as when DOMWindowCreated is fired.

Re: DOMWindowCreated not fired for some frames

On Friday, June 6, 2014 6:33:27 PM UTC+2, Boris Zbarsky wrote: > The about:blank document is quite real, sadly... > > I'm not seeing anything obvious that gets fired when we reuse an inner > for a new document. At least nothing obvious in the window code. >From what I'm seeing, the document obj

Re: DOMWindowCreated not fired for some frames

On 6/6/14, 11:55 AM, Matthew Gertner wrote: So what's the best way to hook into the window so I am notified when the real document is created? The about:blank document is quite real, sadly... I'm not seeing anything obvious that gets fired when we reuse an inner for a new document. At least

Re: Standardized assertion methods

On 6/6/14, 12:21 PM, Boris Zbarsky wrote: Yeah, I've been dealing a lot with edge cases of DOM APIs for the last year or two Case in point. I got some try results, and here's one of the failures: 748 INFO TEST-UNEXPECTED-FAIL | /tests/dom/indexedDB/test/test_multientry.html | exhausted

Re: Standardized assertion methods

On 6/6/14, 11:04 AM, Gijs Kruitbosch wrote: I'm interested in the API exposure case (bug link please? :-) I'd have to search, sorry. :( I would have assumed that you would test that kind of thing by checking if the relevant API property is enumerable from the object, rather than checking for

Re: Intent to implement: DOMMatrix

On Fri, Jun 6, 2014 at 8:57 AM, Milan Sreckovic wrote: > On Jun 5, 2014, at 18:34 , Rik Cabanier wrote: > > On Thu, Jun 5, 2014 at 3:28 PM, Robert O'Callahan > wrote: > > On Fri, Jun 6, 2014 at 9:07 AM, Rik Cabanier wrote: > > ... > > > > Then there's this case: > var m = new DOMMatrix(); > m.

Re: DOMWindowCreated not fired for some frames

On Friday, June 6, 2014 4:28:35 PM UTC+2, Boris Zbarsky wrote: > On 6/6/14, 10:00 AM, Matthew Gertner wrote: > It's by design: when you ask for a window and we haven't actually > created one yet (because this is a new subframe that's doing its initial > load, say), we have to go ahead and create

Re: Intent to implement: DOMMatrix

On Jun 5, 2014, at 18:34 , Rik Cabanier wrote: > On Thu, Jun 5, 2014 at 3:28 PM, Robert O'Callahan > wrote: > >> On Fri, Jun 6, 2014 at 9:07 AM, Rik Cabanier wrote: >> >>> ... > > >> Then there's this case: >> var m = new DOMMatrix(); >> m.translate(-1,-1); >> m.translate(1,1); >> m.isIdent

Re: Standardized assertion methods

On 06/06/2014 15:26, Boris Zbarsky wrote: On 6/6/14, 7:12 AM, Gijs Kruitbosch wrote: No, I think that in 99.99% of cases, I don't care about the type, and therefore I would normally use is() and not care that it's using non-strict equality. I think the case where there is (a) a possibility that

Re: Intent to unship: javascript: execution outside navigation contexts

On Fri, Jun 6, 2014 at 4:33 PM, Boris Zbarsky wrote: > I'm planning to remove this sandbox stuff from javascript:. Either it'll be > running in a navigation context (toplevel window, iframe, data="javascript:">) or it won't run at all. And return the equivalent of a network error? Sounds great

Intent to unship: javascript: execution outside navigation contexts

Currently we support things like , as well as and @import(url("javascript:stuff")). What these do is run the script in a sandbox and then if it returns a value other than undefined treat that value as data for the load. I believe at this point we're the only UA that does this, and it causes

Re: Standardized assertion methods

On 6/6/14, 7:12 AM, Gijs Kruitbosch wrote: No, I think that in 99.99% of cases, I don't care about the type, and therefore I would normally use is() and not care that it's using non-strict equality. I think the case where there is (a) a possibility that I could get '5' instead of 5 when code is m

Re: DOMWindowCreated not fired for some frames

On 6/6/14, 10:00 AM, Matthew Gertner wrote: Is this a Firefox bug or somehow by design? It's by design: when you ask for a window and we haven't actually created one yet (because this is a new subframe that's doing its initial load, say), we have to go ahead and create an about:blank one to r

Re: DOMWindowCreated not fired for some frames

On Tuesday, March 25, 2014 7:34:27 PM UTC+1, Boris Zbarsky wrote: > Is the url about:blank when the window is created, perhaps? It's hard > to say without knowing exactly what you're logging/measuring. I spent some more time looking into this. The problem is apparently that we are observing htt

Re: Overriding the CSP for privileged protocols

On Thursday, June 5, 2014 5:50:23 PM UTC+2, Boris Zbarsky wrote: > The CSP implementation should be using protocol flags here instead of > hardcoding (and if it's not, bugs should be filed). And then your > protocol can set the relevant flags. Bug filed: https://bugzilla.mozilla.org/show_bug.cg

Re: Standardized assertion methods

On Fri, Jun 6, 2014 at 11:12 PM, Gijs Kruitbosch wrote: > No, I think that in 99.99% of cases, I don't care about the type, and > therefore I would normally use is() and not care that it's using non-strict > equality. I think the case where there is (a) a possibility that I could > get '5' instea

Re: Standardized assertion methods

On 06/06/2014 11:56, James Graham wrote: On 06/06/14 11:41, Gijs Kruitbosch wrote: On 06/06/2014 10:29, James Graham wrote: On 05/06/14 10:38, Mike de Boer wrote: As I tried to explain, the CommonJS API naively made sense to me at the time. To others as well, because we’re happily using it. A

Re: Standardized assertion methods

On 06/06/14 11:41, Gijs Kruitbosch wrote: > On 06/06/2014 10:29, James Graham wrote: >> On 05/06/14 10:38, Mike de Boer wrote: >> >>> As I tried to explain, the CommonJS API naively made sense to me at >>> the time. To others as well, because we’re happily using it. As I now >>> understand, some of

Re: Standardized assertion methods

On 06/06/2014 10:29, James Graham wrote: On 05/06/14 10:38, Mike de Boer wrote: As I tried to explain, the CommonJS API naively made sense to me at the time. To others as well, because we’re happily using it. As I now understand, some of us are very attached to a specific, different, API. FWI

Re: Standardized assertion methods

On Fri, Jun 6, 2014 at 2:29 AM, James Graham wrote: > * All the todo stuff is mixing concerns. It forces you into a mode of > test writing where properties of a single implementation are hardcoded > into the testcases. This isn't a huge problem when there is only a > single relevant implementation

Re: Standardized assertion methods

On 05/06/14 10:38, Mike de Boer wrote: > As I tried to explain, the CommonJS API naively made sense to me at > the time. To others as well, because we’re happily using it. As I now > understand, some of us are very attached to a specific, different, > API. FWIW I don't think that I am attached to

Re: Overriding the CSP for privileged protocols

On Thursday, June 5, 2014 5:50:23 PM UTC+2, Boris Zbarsky wrote: > The CSP implementation should be using protocol flags here instead of > hardcoding (and if it's not, bugs should be filed). And then your > protocol can set the relevant flags. I'll confirm (going to dive deeper into the CSP cod