Re: XULRunner future and ownership
I’d like to finetune my earlier statement - after talking things over a bit with Benjamin - to say: I’d like to volunteer if there’s no one else moving forward to take this project on. The reason is that I’m not currently working on or using XULRunner tech, so my level of engagement is low. I’m only really interested in a gecko bootstrap binary (called ‘xulrunner-stub’ at the moment) to continue to exist for my future projects. If there’s someone who’s using XULRunner frequently for their projects, I’m sure she or he will be a much better fit! Please step forward. :-) Cheers, Mike. On 29 Jul 2015, at 23:46, Mike de Boer mdeb...@mozilla.com wrote: I’d like to volunteer. Not much more to say, really :-) Cheers, Mike. On 29 Jul 2015, at 20:30, Benjamin Smedberg benja...@smedbergs.us wrote: The Mozilla project no longer sees XULRunner as a priority project. It's not core to advancing the open web or any of our current or planned products. As Ben Hearsum noted a couple weeks ago, we are turning off automated XULRunner builds and so XULRunner will probably quickly cease to work. In order to keep XULRunner in the tree, we need an owner who wants to keep it building and running properly. Currently, I am the nominal owner of the XULRunner code, but I have no desire to do this work or even really to review the necessary patches. I am looking to see whether there is an alternate owner who is interested in the task of keeping XULRunner building and running properly and reviewing patches to XULRuner-specific code. Please contact me if you want to nominate yourself or somebody else for this role. If I do not find a suitable owner in the next two weeks, I intend to remove the XULRunner code from the mozilla-central repository on 14-August. --BDS ___ 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: XULRunner future and ownership
On Wednesday, July 29, 2015 at 8:44:57 PM UTC-6, Eric Shepherd wrote: Benjamin Smedberg wrote: I am looking to see whether there is an alternate owner who is interested in the task of keeping XULRunner building and running properly and reviewing patches to XULRuner-specific code. Please contact me if you want to nominate yourself or somebody else for this role. I should note also that the MDN staff can't put any time into helping with XULRunner specific documentation anymore, so any documentation work would have to be taken up by the person or people that pick up the project. I would, however, be quite happy to spend some time helping whoever takes on that work -- or whoever picks up writing work for it -- on exactly how to contribute the needed material to MDN. -- Eric Shepherd Senior Technical Writer Mozilla https://www.mozilla.org/ Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy Check my Availability https://freebusy.io/esheph...@mozilla.com I'll volunteer to help out with documentation. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Allowing web apps to delay layout/rendering on startup
There are some forces at play in a web app that point to wanting to delay layout and rendering until a web app gives a signal that it should start: * ECMAScript modules, and even developer constructed JS module systems today, rely on async loading of scripts. * Custom elements need their JS registered with the browser before they are fully useful. * Apps can have dependencies on async IDB operations to know what UI to first show. For instance, if the user does not have a saved account, show the sign in view instead of the app data view. * We want fast app startups in B2G/Gaia. Typically we lose layout/render/paint time while we wait for these async mechanisms to finish, and the paints are not useful for the user in the meantime. In addition, there is a possibility that custom elements may take a path of synchronous construction with no later upgrades, which means the JS for the custom element needs to be registered before any custom element is used in the DOM. A similar case surfaced a while back in the context of B2G, and at the time I filed bug 863499[2], which focused on a document.mozDelayLoadEvent / document.mozStopDelayingLoadEvent JS API around controlling the load event firing. At that time, the concern was about losing times to wasted renders and the effects on screen shots. However, I believe the main concern now is getting enough JS and app data loaded to allow layout to be effective in fewer passes than strictly about the final render and load event. So maybe the API should be more about delaying layout than about the load event? In talking to Wilson Page, he mentioned something like a document.pauseLayout() document.resumeLayout(), not sure if there are existing thoughts around that. If that seemed workable, maybe also a html mozPauseLayout type of attribute, so the browser knows as soon as possible to pause its work, instead of relying on a JS API. For Gaia apps, we use a CSP policy that does not allow inline scripts, so the attribute on a tag is more appealing for that reason. A nonced script might be a workable alternative for the CSP case, if an attribute was too much of a stretch. Happy to hear about any suggestions for the general goal, James [1] Service workers help a bit here, but do not help the other aync forces. [2] https://bugzilla.mozilla.org/show_bug.cgi?id=863499 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
Can't you just make everything display:none until you're ready to show it? -Jeff On Thu, Jul 30, 2015 at 4:20 PM, James Burke jbu...@mozilla.com wrote: There are some forces at play in a web app that point to wanting to delay layout and rendering until a web app gives a signal that it should start: * ECMAScript modules, and even developer constructed JS module systems today, rely on async loading of scripts. * Custom elements need their JS registered with the browser before they are fully useful. * Apps can have dependencies on async IDB operations to know what UI to first show. For instance, if the user does not have a saved account, show the sign in view instead of the app data view. * We want fast app startups in B2G/Gaia. Typically we lose layout/render/paint time while we wait for these async mechanisms to finish, and the paints are not useful for the user in the meantime. In addition, there is a possibility that custom elements may take a path of synchronous construction with no later upgrades, which means the JS for the custom element needs to be registered before any custom element is used in the DOM. A similar case surfaced a while back in the context of B2G, and at the time I filed bug 863499[2], which focused on a document.mozDelayLoadEvent / document.mozStopDelayingLoadEvent JS API around controlling the load event firing. At that time, the concern was about losing times to wasted renders and the effects on screen shots. However, I believe the main concern now is getting enough JS and app data loaded to allow layout to be effective in fewer passes than strictly about the final render and load event. So maybe the API should be more about delaying layout than about the load event? In talking to Wilson Page, he mentioned something like a document.pauseLayout() document.resumeLayout(), not sure if there are existing thoughts around that. If that seemed workable, maybe also a html mozPauseLayout type of attribute, so the browser knows as soon as possible to pause its work, instead of relying on a JS API. For Gaia apps, we use a CSP policy that does not allow inline scripts, so the attribute on a tag is more appealing for that reason. A nonced script might be a workable alternative for the CSP case, if an attribute was too much of a stretch. Happy to hear about any suggestions for the general goal, James [1] Service workers help a bit here, but do not help the other aync forces. [2] https://bugzilla.mozilla.org/show_bug.cgi?id=863499 ___ 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: layers.async-pan-zoom.enabled amazing performance increase
On Thu, Jul 30, 2015 at 10:15 AM webko...@gmail.com wrote: Problem it this introduced some bugs, like disabling scrolling completely on some pages, such as a google search page. Did you report a bug on this yet? I find this can be reproduced reliably by loading in more log history in an application like IRCCloud, and then scrolling up. Superficially it seems to have to do with overflow: auto not respecting the z-index. I'm quite sure this can be distilled down to a reproducible test case. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DXR: the new_one
A reminder that my presentation is less than an hour away! It'll be live in MV commons as well as streamed on AirMo at 3pm PDT; tune in to hear the latest on what's happening in DXR land. Thanks, Peter On Tue, Jul 28, 2015 at 8:33 AM, Peter Elmers pelm...@mozilla.com wrote: Hello! I'm Peter (:new_one), this summer's DXR intern. My internship is drawing to a close, and with that comes my final presentation. This Thursday (July 30) at 3pm PDT from the MV commons, I'll be giving a 10-minute overview of what DXR is, what's planned, and three things I've done over the last couple of months: permalinks, path promotion, and XPIDL support. I'll be happy for you to attend! Thanks, Peter ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
I can't speak about the validity of the requirement, but in terms of API, we probably want something more compositional, if several codepaths need to stop rendering. And then, we end up with the possibility that someone forgets to enable rendering, with all the ensuing debugging joy. Since this is exactly the kind of issue we fight with Async Shutdown, I would suggest an API that looks more like document.mozLayout.addBlocker(Hey, I need to finish looking at IDB, somePromise); This will let the DevTools inspect the state, either to find out which of the blockers is slow to respond, or to find which of the blockers doesn't respond at all. Cheers, David On 30/07/15 22:20, James Burke wrote: In talking to Wilson Page, he mentioned something like a document.pauseLayout() document.resumeLayout(), not sure if there are existing thoughts around that. If that seemed workable, maybe also a html mozPauseLayout type of attribute, so the browser knows as soon as possible to pause its work, instead of relying on a JS API. For Gaia apps, we use a CSP policy that does not allow inline scripts, so the attribute on a tag is more appealing for that reason. A nonced script might be a workable alternative for the CSP case, if an attribute was too much of a stretch. Happy to hear about any suggestions for the general goal, James [1] Service workers help a bit here, but do not help the other aync forces. [2] https://bugzilla.mozilla.org/show_bug.cgi?id=863499 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: layers.async-pan-zoom.enabled amazing performance increase
The OP filed bug 1189237 for this issue, but it seems like it was reported on Firefox 39 where we don't support async-pan-zoom. If you can reproduce this issue in a Nightly build please file a new bug. Thanks, kats On Thu, Jul 30, 2015 at 5:32 PM, Andreas Tolfsen a...@mozilla.com wrote: On Thu, Jul 30, 2015 at 10:15 AM webko...@gmail.com wrote: Problem it this introduced some bugs, like disabling scrolling completely on some pages, such as a google search page. Did you report a bug on this yet? I find this can be reproduced reliably by loading in more log history in an application like IRCCloud, and then scrolling up. Superficially it seems to have to do with overflow: auto not respecting the z-index. I'm quite sure this can be distilled down to a reproducible test case. ___ 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: Allowing web apps to delay layout/rendering on startup
On Thu, Jul 30, 2015 at 4:27 PM, James Burke jbu...@mozilla.com wrote: On Thu, Jul 30, 2015 at 1:28 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: Can't you just make everything display:none until you're ready to show it? Just using display: none seems like it will run into the same problem that prompted bug 863499, where the browser did some render/paints of a white page, which took time away from the async work completing. So maybe I should not frame it as just pausing layout? I was hoping it would also delay render and maybe paints that happen during startup, so more time is given up front to the async activities. Painting a document with display:none on the body should be more or less free, I'd think. If it isn't, please file a bug. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
On Thu, Jul 30, 2015 at 1:28 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: Can't you just make everything display:none until you're ready to show it? Just using display: none seems like it will run into the same problem that prompted bug 863499, where the browser did some render/paints of a white page, which took time away from the async work completing. So maybe I should not frame it as just pausing layout? I was hoping it would also delay render and maybe paints that happen during startup, so more time is given up front to the async activities. James ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Allowing web apps to delay layout/rendering on startup
James Burke writes: On Thu, Jul 30, 2015 at 1:28 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: Can't you just make everything display:none until you're ready to show it? Just using display: none seems like it will run into the same problem that prompted bug 863499, where the browser did some render/paints of a white page, which took time away from the async work completing. So maybe I should not frame it as just pausing layout? I was hoping it would also delay render and maybe paints that happen during startup, so more time is given up front to the async activities. If the window is shown, then something will be rendered. Perhaps you want to delay showing the window? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On the future of keygen and application/x-x509-*-cert MIME handling
On Thu, Jul 30, 2015 at 1:35 AM, David Keeler dkee...@mozilla.com wrote: I therefore propose we follow suit and begin the process of deprecating and removing these features. The intention of this post is to begin a discussion to determine the feasibility of doing so. Deprecating and adding counters seems meaningful. It's not supported across all browsers and it seems unlikely to ever be successful. If we can make that clear to more folks by console warnings and some outreach that seems like a good thing to do for the web. Safari still supporting it is somewhat worrisome. We're in the process of implementing and standardizing many -webkit- features due to Safari's dominance on mobile. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should the entire JS structure be Object.freeze()'d if it's exposed through a read only property?
On Thu, Jul 30, 2015 at 9:00 AM, Tim Guan-tin Chien timdr...@mozilla.com wrote: This is not as convenient as a keyword in WebIDL but I think it's good enough. You might want to chime in on https://www.w3.org/Bugs/Public/show_bug.cgi?id=29004 which is asking for something similar (though more scoped). Note though that frozen in JavaScript only freezes the properties. If the object has private state that can still be modified through other means. E.g., freezing a Set or Map might not do what you expect it to do. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On the future of keygen and application/x-x509-*-cert MIME handling
On Thu, Jul 30, 2015 at 6:33 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jul 30, 2015 at 12:28 PM, Teoli news.fakeaddress@localhost.invalid wrote: Do you think it is already worth to flag it as deprecated in the MDN documentation as Google plans to remove it too? Yeah, seems worth a note at least given that Microsoft doesn't ship it either (nor plans to ever). I'll probably get the HTML Standard updated too in due course. +1 -- https://annevankesteren.nl/ ___ 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: On the future of keygen and application/x-x509-*-cert MIME handling
On Thu, Jul 30, 2015 at 6:53 AM, Hubert Kario hka...@redhat.com wrote: On Wednesday 29 July 2015 16:35:41 David Keeler wrote: [cc'd to dev-security for visibility. This discussion is intended to happen on dev-platform; please reply to that list.] Ryan Sleevi recently announced the pre-intention to deprecate and eventually remove support for the keygen element and special-case handling of the application/x-x509-*-cert MIME types from the blink platform (i.e. Chrome). Rather than reiterate his detailed analysis, I'll refer to the post here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMG JZAMJ snarky sarcasm Well, gmail doesn't support S/MIME or GPG/MIME so obviously keygen is useless and should be removed. /snarky sarcasm Much, if not all, of that reasoning applies to gecko as well. Furthermore, it would be a considerable architectural improvement if gecko were to remove these features (particularly with respect to e10s). Additionally, if they were removed from blink, the compatibility impact of removing them from gecko would be lessened. I therefore propose we follow suit and begin the process of deprecating and removing these features. The intention of this post is to begin a discussion to determine the feasibility of doing so. because pushing people to use Internet Explorer^W^W Spartan^W Edge in enterprise networks is a good plan to continue loosing market share for Mozilla products! /s lack of easy, cross-application certificate deployment is the _reason_ for low rates of deployment of client certificates, but where they are deployed, they are _critical_ keygen doesn't help you with cross-application deployment. After all, IE doesn't support it. you really suggest I should tell regular people to copy paste CSR's, keep safe their private keys and be able to pair keys to certs when even programmers and system administrators have problems with current certificate deployments? (user certs vs web server certs) The point has been made a couple of times that you can pretty effectively polyfill keygen with either WebCrypto or JS crypto libraries. You can do the whole key generation and enrollment process that way, and the only manual step is to download the cert and import it into the browser. Do it with JS, and you can support far more browsers than keygen supports today. --Richard suggesting removal of such a feature because is not often used is like suggesting removal of mains valve because it is not used often And I say it as a former sysadmin, not Red Hat employee. -- Regards, Hubert Kario ___ 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: XULRunner future and ownership
reverendli...@gmail.com mailto:reverendli...@gmail.com July 30, 2015 at 10:17 AM I'll volunteer to help out with documentation. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform Benjamin Smedberg mailto:benja...@smedbergs.us July 29, 2015 at 2:30 PM The Mozilla project no longer sees XULRunner as a priority project. It's not core to advancing the open web or any of our current or planned products. As Ben Hearsum noted a couple weeks ago, we are turning off automated XULRunner builds and so XULRunner will probably quickly cease to work. In order to keep XULRunner in the tree, we need an owner who wants to keep it building and running properly. Currently, I am the nominal owner of the XULRunner code, but I have no desire to do this work or even really to review the necessary patches. I am looking to see whether there is an alternate owner who is interested in the task of keeping XULRunner building and running properly and reviewing patches to XULRuner-specific code. Please contact me if you want to nominate yourself or somebody else for this role. If I do not find a suitable owner in the next two weeks, I intend to remove the XULRunner code from the mozilla-central repository on 14-August. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform Awesome! Hopefully you'll be able to have no serious trouble keeping up the XULRunner docs. Please do have a look at our content and style guide: https://developer.mozilla.org/en-US/docs/MDN/Contribute/Content And if you or anyone else helping with XULRunner docs needs help getting going with editing on MDN, our starter guide is here: https://developer.mozilla.org/en-US/docs/MDN/Getting_started Please feel free to ping me any time by email or on IRC if you'd like to talk about it. I've been at this stuff for a long time so I may have useful advice to offer if you need it. -- Eric Shepherd Senior Technical Writer Mozilla https://www.mozilla.org/ Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy Check my Availability https://freebusy.io/esheph...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On the future of keygen and application/x-x509-*-cert MIME handling
On Thu, Jul 30, 2015 at 12:28 PM, Teoli news.fakeaddress@localhost.invalid wrote: Do you think it is already worth to flag it as deprecated in the MDN documentation as Google plans to remove it too? Yeah, seems worth a note at least given that Microsoft doesn't ship it either (nor plans to ever). I'll probably get the HTML Standard updated too in due course. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On the future of keygen and application/x-x509-*-cert MIME handling
On Wednesday 29 July 2015 16:35:41 David Keeler wrote: [cc'd to dev-security for visibility. This discussion is intended to happen on dev-platform; please reply to that list.] Ryan Sleevi recently announced the pre-intention to deprecate and eventually remove support for the keygen element and special-case handling of the application/x-x509-*-cert MIME types from the blink platform (i.e. Chrome). Rather than reiterate his detailed analysis, I'll refer to the post here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMG JZAMJ snarky sarcasm Well, gmail doesn't support S/MIME or GPG/MIME so obviously keygen is useless and should be removed. /snarky sarcasm Much, if not all, of that reasoning applies to gecko as well. Furthermore, it would be a considerable architectural improvement if gecko were to remove these features (particularly with respect to e10s). Additionally, if they were removed from blink, the compatibility impact of removing them from gecko would be lessened. I therefore propose we follow suit and begin the process of deprecating and removing these features. The intention of this post is to begin a discussion to determine the feasibility of doing so. because pushing people to use Internet Explorer^W^W Spartan^W Edge in enterprise networks is a good plan to continue loosing market share for Mozilla products! /s lack of easy, cross-application certificate deployment is the _reason_ for low rates of deployment of client certificates, but where they are deployed, they are _critical_ you really suggest I should tell regular people to copy paste CSR's, keep safe their private keys and be able to pair keys to certs when even programmers and system administrators have problems with current certificate deployments? (user certs vs web server certs) suggesting removal of such a feature because is not often used is like suggesting removal of mains valve because it is not used often And I say it as a former sysadmin, not Red Hat employee. -- Regards, Hubert Kario signature.asc Description: This is a digitally signed message part. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On the future of keygen and application/x-x509-*-cert MIME handling
On 30/07/2015 08:58, Anne van Kesteren wrote: On Thu, Jul 30, 2015 at 1:35 AM, David Keeler dkee...@mozilla.com wrote: I therefore propose we follow suit and begin the process of deprecating and removing these features. The intention of this post is to begin a discussion to determine the feasibility of doing so. Deprecating and adding counters seems meaningful. It's not supported across all browsers and it seems unlikely to ever be successful. If we can make that clear to more folks by console warnings and some outreach that seems like a good thing to do for the web. Safari still supporting it is somewhat worrisome. We're in the process of implementing and standardizing many -webkit- features due to Safari's dominance on mobile. Do you think it is already worth to flag it as deprecated in the MDN documentation as Google plans to remove it too? Or should we wait until we add a message in the console when met (I guess that is what will happen). [In that case don't forget the dev-doc-need on that bug ;-) ] -- Jean-Yves ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: layers.async-pan-zoom.enabled amazing performance increase
On Thursday, July 30, 2015 at 11:13:57 AM UTC+2, webk...@gmail.com wrote: Hi, i enabled layers.async-pan-zoom.enabled in firefox on Mac OSX Yosemite, and noticed dramatic performance increase. Problem it this introduced some bugs, like disabling scrolling completely on some pages, such as a google search page. Is this the proper place to report such bugs ? I'd like to contribute to this, because the performance increase is such great. Note: I was referring to scrolling smoothness performance increase. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: layers.async-pan-zoom.enabled amazing performance increase
On Thu, Jul 30, 2015 at 9:13 PM, webko...@gmail.com wrote: Hi, i enabled layers.async-pan-zoom.enabled in firefox on Mac OSX Yosemite, and noticed dramatic performance increase. Great! Problem it this introduced some bugs, like disabling scrolling completely on some pages, such as a google search page. Is this the proper place to report such bugs ? Please file bugs in Bugzilla! https://bugzilla.mozilla.org/enter_bug.cgi?product=Core in the Panning and Zooming component. Thanks! Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
layers.async-pan-zoom.enabled amazing performance increase
Hi, i enabled layers.async-pan-zoom.enabled in firefox on Mac OSX Yosemite, and noticed dramatic performance increase. Problem it this introduced some bugs, like disabling scrolling completely on some pages, such as a google search page. Is this the proper place to report such bugs ? I'd like to contribute to this, because the performance increase is such great. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
