Re: Intent to implement: DOMMatrix

On Fri, May 30, 2014 at 9:00 PM, Benoit Jacob wrote: > I never seem to be able to discourage people from dragging the W3C into > specialist topics that are outside its area of expertise. Let me try again. > > Objection #1: > > The skew* methods are out of place there, because, contrary to the res

Re: Intent to implement: DOMMatrix

Since DOMMatrix is replacing SVGMatrix, I don't see a way to implement it behind a flag. Should I wait to make that change and leave both SVGMatrix and DOMMatrix in the code for now? On Fri, May 30, 2014 at 8:53 PM, Robert O'Callahan wrote: > I'm all for it! :-) > > Rob > -- > Jtehsauts tshaei

Re: Intent to implement: DOMMatrix

I never seem to be able to discourage people from dragging the W3C into specialist topics that are outside its area of expertise. Let me try again. Objection #1: The skew* methods are out of place there, because, contrary to the rest, they are not geometric transformations, they are just arithmet

Re: Intent to implement: DOMMatrix

I'm all for it! :-) Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph ean

Re: Intent to implement: DOMMatrix

I'll defer to the layout folks for this one. / Jonas On Fri, May 30, 2014 at 5:02 PM, Rik Cabanier wrote: > Primary eng emails > caban...@adobe.com, dschu...@adobe.com > > *Proposal* > *http://dev.w3.org/fxtf/geometry/#DOMMatrix > * > > *Summary* > Exp

Intent to implement: DOMMatrix

Primary eng emails caban...@adobe.com, dschu...@adobe.com *Proposal* *http://dev.w3.org/fxtf/geometry/#DOMMatrix * *Summary* Expose new global objects named 'DOMMatrix' and 'DOMMatrixReadOnly' that offer a matrix abstraction. *Motivation* The DOMMatrix

Intent to implement: New HTMLInputElement.autocomplete values

Summary: I am implementing support for @autocomplete values other than "off"/"on" for HTMLInputElement.autocomplete. This allows web developers to indicate how UAs should autocomplete/auto-fill values in the fields (if they choose to do so) so they don't have to use heuristics to guess what dat

Re: Intent to implement: CSSOM-View scroll-behavior property

On Sunday, 25 May 2014 14:57:13 UTC-7, Robert O'Callahan wrote: > On Mon, May 26, 2014 at 9:47 AM, Robert O'Callahan > wrote: > > > > > On Sun, May 25, 2014 at 4:59 PM, L. David Baron wrote: > > > > > >> On Saturday 2014-05-24 20:00 -0700, Jonas Sicking wrote: > > >> > I guess what I'm arg

Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates

On 5/30/2014 12:00 PM, Gervase Markham wrote: On 28/05/14 17:49, Joshua Cranmer 🐧 wrote: We have an excellent chance to try to rethink CA infrastructure in this process beyond the notion of a trusted third-party CA system (which is already more or less broken, but that's beside the point). My ow

Re: Intent to implement: CSSOM-View scroll-behavior property

On Tuesday, 27 May 2014 15:12:56 UTC-7, Robert O'Callahan wrote: > On Wed, May 28, 2014 at 6:14 AM, wrote: > > > > > Is this behavior acceptable or would it be more desirable to always return > > the actual scroll position in DOM methods? > > All DOM methods that depend on the scroll position

Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates

On 28/05/14 17:49, Joshua Cranmer 🐧 wrote: > * Insufficiently secure certificate (e.g., certificates that violate > CA/Browser Forum rules or the like. I don't know if we actually consider > this a failure right now, but it's a reasonable distinct failure class > IMHO) We would refuse e.g. a cert

Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates

On 29/05/14 07:01, Mike Hoye wrote: > It's become clear in the last few months that the overwhelmingly most > frequent users of MITM attacks are state actors with privileged network > positions either obtaining or coercing keys from CAs, I don't think that's clear at all. Citation needed. I think

Re: Intent to Implement: Encrypted Media Extensions

On 27/05/14 19:44, Chris Pearce wrote: > Encrypted Media Extensions specifies a JavaScript interface for > interacting with plugins that can be used to facilitate playback of DRM > protected media content. We will also be implementing the plugin > interface itself. We will be working in partnership

Re: OMTC on Windows

On Friday, May 30, 2014 6:16:53 PM UTC+3, andre...@gmail.com wrote: > Please read my email again. It was provided as an objective data and subjective assessment - and not as an opinion, in reply for your request for more info on systems where we suck, if I understood your request correctly. FWI

Re: Update on sheriff-assisted checkin-needed bugs

Just as a quick follow-up to this - we're already seeing much lower checkin-needed backout rates since this change went into affect, so thank you all for your help! -Ryan - Original Message - From: "Ryan VanderMeulen" To: "dev-b2g" , "dev.platform" , dev-g...@lists.mozilla.org Cc: "Sh

Re: OMTC on Windows

Please read my email again. This kind of animation cannot be rendered with high FPS by any engine. It's simply conceptually expensive and inefficient for the DOM rendering model. We will work on matching other engines if we are slightly slower than we could be, but you will never reach solid per

Re: Intent to land: Voice/video client ("Loop")

On 5/30/14 10:14, Anne van Kesteren wrote: On Fri, May 30, 2014 at 5:03 PM, Adam Roach wrote: Link to standard: N/A I take it this means there's no web-exposed API? That is correct. This is a browser feature, not accessible from content. -- Adam Roach Principal Platform Engineer a...@moz

Re: Intent to land: Voice/video client ("Loop")

On Fri, May 30, 2014 at 5:03 PM, Adam Roach wrote: > Link to standard: N/A I take it this means there's no web-exposed API? -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/

Intent to land: Voice/video client ("Loop")

Summary: The Loop project aims to create a user-visible real-time communications service for existing Mozilla products, leveraging the WebRTC platform. One version of the client will be integrated with Firefox Desktop. It is intended to be interoperable with a Firefox OS application (not part

Re: OMTC on Windows

On Friday, May 30, 2014 5:48:26 PM UTC+3, avi...@gmail.com wrote: > On all these systems, Firefox is far behind IE on this front, but with > margins getting lower as the systems get stronger (i.e. in order of > presentation - old atom, new atom, i7+hd4000). And just to complete the picture, the

Re: OMTC on Windows

On Friday, May 30, 2014 5:06:52 PM UTC+3, Gabriele Svelto wrote: > On 30/05/2014 14:19, Andreas Gal wrote: > If you can point us to some specific hardware we really suck on we can > definitely look into this. Sure, and the hardware specs are also available at bug 894128 comment 0. 100% smooth sc

Re: OMTC on Windows

On 30.05.2014 07:28, Matt Woodrow wrote: I definitely agree with this, but we also need OMTAnimations to be finished and enabled before any of the interesting parts of the UI can be converted. Given that, I don't think we can have this conversation at the expense of trying to fix the current set

Re: OMTC on Windows

On 30/05/2014 14:19, Andreas Gal wrote: > Now for Intel hardware being slow there could be a couple reasons, and APZ > might fix them actually. If I remember correctly Atom GPUs are PowerVR based, > which is a tile based rendering architecture. It splits the frame buffer in > small tiles and ren

Re: OMTC on Windows

There are likely two causes here. First, until we have APZ enabled its very unlikely that we can ever maintain a high frame-rate scrolling on low-end hardware. OMTC is a prerequisite for APZ (async pan/zoom). Low end hardware is simply not fast enough to repaint and buffer-rotate with 60FPS.

Re: PSA: Refcounted classes should have a non-public destructor & should be MOZ_FINAL where possible

On Thu, May 29, 2014 at 12:27 AM, Daniel Holbert wrote: > For now, our code isn't clean enough for this sort of static_assert to > be doable. :-/ And we have at least one instance of a refcounted class > that's semi-intentionally (albeit carefully) declared on the stack: > gfxContext, per https://

Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates

On (2014年05月29日 23:01), Mike Hoye wrote: > On 2014-05-28, 9:07 PM, Joshua Cranmer 🐧 wrote: >> >> Two more possible rationales: >> 1. The administrator is unwilling to pay for an SSL certificate and >> unaware of low-cost or free SSL certificate providers. >> 2. The administrator has philosophical b

Re: OMTC on Windows

On Friday, May 30, 2014 1:25:33 PM UTC+3, avi...@gmail.com wrote: > FWIW, IE is able to maintain 100% smooth scrolling on some really complex > pages even on a _very_ low end Atom system (Intel iGPU), while Firefox > doesn't come anywhere near it. Of course, I'm hoping that APZ and maybe tiling

Re: OMTC on Windows

On Friday, May 30, 2014 8:22:25 AM UTC+3, Matt Woodrow wrote: > Thanks Avi! > > > > I can reproduce a regression like this (~100% slower on > > iconFade-close-DPIcurrent.all) with my machine forced to use the intel > > GPU, but not with the Nvidia one. Indeed, and it's not the first time we

Re: Retina display support

On 30.05.14 08:38, bhargava.animes...@gmail.com wrote: Hi, I have two different applications , both of them use gecko SDK version 2.0 for embedded browser. On retina machine , one of the applications shows clear retina supported text while other browser on other application shows blurred tex

Re: Uncaught rejections in xpcshell will now cause orange (part 2)

== Example Consider the following XPCShell test: function doSomething() { OS.File.writeAtomic("/a path that doesn't exist", "foo"); } add_test(function() { // ... doSomething(); // ... }); This test raises an error and fails to catch it. Until now, this test used to pass with a warning.