Re: Intent to implement: DOMMatrix
On Sat, Jun 7, 2014 at 9:38 PM, Benoit Jacob wrote: > > > > 2014-06-07 12:49 GMT-04:00 L. David Baron : > > On Monday 2014-06-02 20:45 -0700, Rik Cabanier wrote: >> > - change isIdentity() so it's a flag. >> >> I'm a little worried about this one at first glance. >> >> I suspect isIdentity is going to be used primarily for optimization. >> But we want optimizations on the Web to be good -- we should care >> about making it easy for authors to care about performance. And I'm >> worried that a flag-based isIdentity will not be useful for >> optimization because it won't hit many of the cases that authors >> care about, e.g., translating and un-translating, or scaling and >> un-scaling. >> > > Note that the current way that isIdentity() works also fails to offer that > characteristic, outside of accidental cases, due to how floating point > works. > > The point of this optimizations is not so much to detect when a generic > transformation happens to be of a special form, it is rather to represent > transformations as a kind of variant type where "matrix transformation" is > one possible variant type, and exists alongside the default, more optimized > type, "identity transformation". > > Earlier in this thread I pleaded for the removal of isIdentity(). What I > mean is that as it only is defensible as a "variant" optimization as > described above, it doesn't make sense in a _matrix_ class. If we want to > have such a variant type, we should call it a name that does not contain > the word "matrix", and we should have it one level above where we actually > do matrix arithmetic. > > Strawman class diagram: > > Transformation > / | \ > / | \ > /|\ >/ | \ > Identity MatrixOther transform types >e.g. Translation > > In such a world, the class containing the word "Matrix" in its name would > not have a isIdentity() method; and for use cases where having a "variant > type" that can avoid being a full blown matrix is meaningful, we would have > such a variant type, like "Transformation" in the above diagram, and the > isIdentity() method there would be merely asking the variant type for its > type field. > Note that DOMMatrix implements the following under the hood: DOMMatrix / | \ / | \ /|\ / | \ Identity 2D-Matrix 3D-Matrix ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
2014-06-07 12:49 GMT-04:00 L. David Baron : > On Monday 2014-06-02 20:45 -0700, Rik Cabanier wrote: > > - change isIdentity() so it's a flag. > > I'm a little worried about this one at first glance. > > I suspect isIdentity is going to be used primarily for optimization. > But we want optimizations on the Web to be good -- we should care > about making it easy for authors to care about performance. And I'm > worried that a flag-based isIdentity will not be useful for > optimization because it won't hit many of the cases that authors > care about, e.g., translating and un-translating, or scaling and > un-scaling. > Note that the current way that isIdentity() works also fails to offer that characteristic, outside of accidental cases, due to how floating point works. The point of this optimizations is not so much to detect when a generic transformation happens to be of a special form, it is rather to represent transformations as a kind of variant type where "matrix transformation" is one possible variant type, and exists alongside the default, more optimized type, "identity transformation". Earlier in this thread I pleaded for the removal of isIdentity(). What I mean is that as it only is defensible as a "variant" optimization as described above, it doesn't make sense in a _matrix_ class. If we want to have such a variant type, we should call it a name that does not contain the word "matrix", and we should have it one level above where we actually do matrix arithmetic. Strawman class diagram: Transformation / | \ / | \ /|\ / | \ Identity MatrixOther transform types e.g. Translation In such a world, the class containing the word "Matrix" in its name would not have a isIdentity() method; and for use cases where having a "variant type" that can avoid being a full blown matrix is meaningful, we would have such a variant type, like "Transformation" in the above diagram, and the isIdentity() method there would be merely asking the variant type for its type field. Benoit > > -David > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Overriding the CSP for privileged protocols
Sounds like you would use nsIDOMWindowUtils.loadSheet for that. -Tom On Sat, Jun 7, 2014 at 8:27 PM, L. David Baron wrote: > On Friday 2014-06-06 00:30 -0700, Matthew Gertner wrote: > > As things stand, it should be possible for responsible extensions such > as ours (we implement our own nsIContentPolicy for our protocol) to do > things like inject CSS into pages. > > We should probably have mechanisms for addons to inject CSS into > pages without having to insert a into the document, though. > > Injecting link elements can be observed by the page, could break > page script (I've seen scripts looking for the first/last style > sheet link to add a rule to it), and can presumably be undone by the > page if it wants to break the addon. > > Having a more distinct mechanism for this might avoid these CSP > issues. > > -David > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On Wednesday 2014-06-04 14:10 -0400, Boris Zbarsky wrote: > For example, should mochitest-plain be consistent with > mochitest-chrome? I would argue yes; the distinction between which > tests go in which one is more or less arbitrarily decided by what > APIs we do or don't have on SpecialPowers. > > Maybe the right answer is that pure-JS tests like xpcshell and > mochitest-browser should be consistent and combined JS-and-markup > tests like mochitest-plain and mochitest-chrome should (separately) > be consistent but we shouldn't worry about consistency between the > two groups of tests? > > I would very much welcome us actually having this discussion and > deciding _this_ point first, before we start deciding which APIs > should be deprecated and which should be preferred in which test > harness. I strongly agree here about wanting consistency between mochitest-plain and mochitest-chrome because the distinction between them is very small. As a somewhat unusually but actually probably not all that extreme example, when writing content/canvas/test/test_drawWindow.html, I realized most of the way through writing the test -- i.e., when figuring out why the test I'd written didn't show the without-patch failures that were expected -- that half of the test needed to move to mochitest-chrome. So there are now two files, one in mochitest-plain and the other (content/canvas/test/chrome/test_drawWindow_widget_layers.html) in mochitest-chrome that share between them a common JS file containing the actual test assertions. (I believe I didn't want to move the whole test, because, if my memory is correct (I'm writing this offline), we run mochitest-chrome on fewer platforms than mochitest-plain.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: DOMMatrix
On Monday 2014-06-02 20:45 -0700, Rik Cabanier wrote: > - change isIdentity() so it's a flag. I'm a little worried about this one at first glance. I suspect isIdentity is going to be used primarily for optimization. But we want optimizations on the Web to be good -- we should care about making it easy for authors to care about performance. And I'm worried that a flag-based isIdentity will not be useful for optimization because it won't hit many of the cases that authors care about, e.g., translating and un-translating, or scaling and un-scaling. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On Friday 2014-06-06 17:42 -0700, Jonas Sicking wrote: > I definitely understand that it'll be a pain to convert existing tests > that rely on the relaxed matching. 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) Ideally it seems like we want to convert the existing tests to test the correct equality, but that requires some knowledge of what they're supposed to be testing, and also somewhat more manual changes to the tests. Temporarily converting them to is_relaxed (or maybe a scarier sounding name, like deprecated_relaxed_is) might help in fixing the 99% case so that we don't add more problems on top of our existing ones, though. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Overriding the CSP for privileged protocols
On Friday 2014-06-06 00:30 -0700, Matthew Gertner wrote: > As things stand, it should be possible for responsible extensions such as > ours (we implement our own nsIContentPolicy for our protocol) to do things > like inject CSS into pages. We should probably have mechanisms for addons to inject CSS into pages without having to insert a into the document, though. Injecting link elements can be observed by the page, could break page script (I've seen scripts looking for the first/last style sheet link to add a rule to it), and can presumably be undone by the page if it wants to break the addon. Having a more distinct mechanism for this might avoid these CSP issues. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Ship: navigator.doNotTrack returns { "0", "1", "unspecified" }
Hi, In Firefox 32, instead of returning "yes" or "unspecified", navigator.doNotTrack will start returning "1", "0" or "unspecified", making it closer to the specification in some aspects - returning "1" and "0" is what the specification requires, not "yes". It will also fix a nasty bug where asking to be tracked would be exposed as navigator.doNotTrack == "yes". There is compatibility risk in using "1" instead of "yes" but the specification requires "1" and other implementations matches. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: upcoming Vibration API behaviour change in Firefox 32
Hi, Note: this is not an Intent to Ship because it is a minor change but given that it is still a content visible change, I want to make sure dev-platform is aware of it. I've landed a patch last week to update the vibration API implementation to match the current specification. The changes make vibrate() less pedantic and instead of failing if the array is too long or an element of the array is too large, it will truncate the input and continue. The rationale being that those limitations (array size and array element value) are platform specifics and a failure would just give a hint to the developer that she/he should try with a lower value. The compatibility risk is very low and it is very unlikely that any content out there depend on the current behaviour. The new behaviour should be shipping in Firefox 32. -- Mounir ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 07/06/2014 03:40, Ehsan Akhgari wrote: 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 == for that, and use === for everything else. r=me :-) Indeed. I'm happy to review and/or help write patches for tests that still need updating because of other reasons (of which there still seem to be a few, like the location == string thing). ~ Gijs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
