Re: Fido U2F, two-factor authentication support
On 18/11/15 19:26, phow...@ccvschools.com wrote: > This is definitely an important feature, but I'm not holding my > breath. I have had a lot of experience with Mozilla over the years > and I really doubt anything will materialize in the near future. Feeling particularly entitled today, are we? >From the look of the bug, it seems like patches are certainly being accepted. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is that possible to implement Sqlite.jsm with ctypes so that is can works in the worker?
It could be improved a bit, but the real issue is that JavaScript is a high-level, garbage-collected, dynamic programming language, while C is a low-level, memory-unsafe, type-unsafe, statically compiled programming language. I have heard a few ideas floating around on how this could be improved, by using a radical redesign of js-ctypes based on asm.js/WebAsm, but at the moment, I don't think that anybody is working on it. Cheers, David On 20/11/15 12:03, Philip Chee wrote: > On 18/11/2015 16:04, David Rajchenbach-Teller wrote: >> Well, the main problem is that js-ctypes is very hard to use, even >> harder to use without causing memory leaks or crashing the process. >> Think the worst parts of both C and JavaScript together. > > Are these problems inherent in ctypes or is it just that our > implementation is broken? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: HTML and tags
Ting-Yu Lin: > Summary: The is used as a disclosure widget from which the user > can > obtain additional information or controls. is used as a summary or > legend of the details. To expand the details, the user could click on the > summary or by adding a bool attribute 'open' to the details. > > An example: Open the example in Chrome or Safari. http://simpl.info/details/ > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=591737 Great work Ting-Yu, and thanks very much for picking this up! -- Cameron McCormack ≝ http://mcc.id.au/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is that possible to implement Sqlite.jsm with ctypes so that is can works in the worker?
On 18/11/2015 16:04, David Rajchenbach-Teller wrote: > Well, the main problem is that js-ctypes is very hard to use, even > harder to use without causing memory leaks or crashing the process. > Think the worst parts of both C and JavaScript together. Are these problems inherent in ctypes or is it just that our implementation is broken? > Cheers, > David > > On 18/11/15 08:57, Philip Chee wrote: >> On 14/11/2015 18:21, David Rajchenbach-Teller wrote: >>> Actually, Sqlite.jsm does most of its work off the main thread. >>> >>> But yes, it would clearly be possible to reimplement Sqlite.jsm using >>> js-ctypes for workers. If you wish to work on this, I can try and help >>> mentoring. >> >> I thought people were being encouraged to avoid using js-ctypes because >> of "problems". However nobody has gone into detail about what those >> alleged problems are. >> >> Phil >> -- -==- Philip Chee, http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: FYI: updating yasm on build machines
Chris Peterson wrote: mozilla-build tools already use 1.3 When did it get upgraded? (My mozilla-build only has yasm 1.1) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Faster Windows builds on Try
<3<3<3 On 11/19/2015 3:23 PM, Chris AtLee wrote: Over the past months we've been working on migrating our Windows builds from the legacy hardware machines into Amazon. I'm very happy to announce that we've wrapped up the initial work here, and all our Windows builds on Try are now happening in Amazon. The biggest win from this is that our Windows builds are now nearly 30 minutes faster than they used to be. As of today, windows builds on try generally take around 50 minutes to complete, down from 1h20 before. Our next step is to migrate the non-try builds onto Amazon as well. Big thanks to Rob, Mark, and the rest of our Release Engineering and Operations team for making this possible! Cheers, Chris https://bugzilla.mozilla.org/show_bug.cgi?id=1199267 ___ 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
Fwd: [Planned] Tree Closing Window 2015-11-21 0600-1630 PST 2015-11-21 06:00 PST 330 mins
FYI: Trees will be closed during our normal Tree Closing Window. However, some of the work mentioned below has been deferred, so trees should be reopened by 11:30 PT. -- Forwarded message -- From:Date: Mon, Nov 16, 2015 at 8:54 AM Subject: [Planned] TCW 2015-11-21 0600-1630 PST 2015-11-21 06:00 PST 630 mins To: all-moco-m...@mozilla.com Issue Status: Upcoming Short Summary: IT will be performing the following work during the Nov 21, 2015 TCW 1217405 reset the 10ge optic in border2.scl3 xe-1/1/0 1223832 reboot buildbot master DB in scl3 1223956 Change pvtbuilds NFS mount 1223592 restart of all buildbot masters 1222532 Upgrade Zeus/Stingray/Steelapp to 10.2 1224590 replace card fw1.scl3 1210275 Reconfigure switch1.r301-4.ops.scl3 for LACP 1210276 Reconfigure switch1.r302-2.ops.scl3 for LACP 1210277 Reconfigure switch1.r302-1.ops.scl3 for LACP 1210278 Reconfigure switch1.r301-5.ops.scl3 for LACP 1210279 Reconfigure switch1.r302-4.ops.scl3 for LACP Mozilla IT Maintenance Notification: -- Issue Status: Upcoming Bug IDs: 1214712 Start Date:2015-11-21 Start Time:06:00 PST Site: All Services: Tree Closure Impact of Work:During the bug work above brief disruptions (less than 5 minutes) to sites and services will occur. If you have any questions or concerns please address them to...@mozilla.com or visit #moc in IRC Also, visit whistlepig.mozilla.org for all notifications. -- m...@mozilla.com - m...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: FYI: updating yasm on build machines
On 11/20/15 5:09 AM, Neil wrote: Chris Peterson wrote: mozilla-build tools already use 1.3 When did it get upgraded? (My mozilla-build only has yasm 1.1) Last year according to bug 1113450: https://bugzilla.mozilla.org/show_bug.cgi?id=1113450 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Service Workers with FetchEvent
In Firefox 44 we intend to enable Service Workers and FetchEvents by default on desktop and android. These features will not be enabled on Firefox OS yet. They has been developed behind the following preferences: dom.serviceWorkers.enabled dom.serviceWorkers.interception.enabled dom.serviceWorkers.interception.opaque.enabled Chrome has been shipping Service Workers with FetchEvent since Chrome 40. Unfortunately, I can't find a previous intent to implement for service workers. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1226686 Standard: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html Please let me know if you have any questions are concerns. Thanks. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Service Workers with FetchEvent
On 11/20/15 3:21 PM, Ben Kelly wrote: The spec is converging to a stable v1, but things are still changing. The core functionality has been stable for a while, though. OK. I guess my question is whether, for example, waiting for another release cycle would significantly improve things here or not. I'm not saying we necessarily should, just trying to understand the tradeoffs. There are some corner cases where we differ or might differ depending on release schedules. For example, the spec now says that navigations should set a RequestMode of "navigate", but neither chrome or firefox do this. We set "same-origin" as the spec used to say. I believe chrome has patches in flight to change, but we have not started yet. OK. That sort of thing is going to happen, as long as the spec is in flux. Another compat issue we need to fix is returning the same ServiceWorkerRegistration object repeatedly from certain APIs. This was something that changed a few times in both the spec and chrome. Fixing these minor compat issues is on our todo list for the rest of the 45 cycle leading up to orlando. OK. Are there plans to uplift any of this to 44? The webkit project's 5 year plan includes service workers: Great, thanks. I don't think we are missing anything significant in the service worker spec. Other features building on top of service workers like push, background-sync, etc are in separate specs. Gotcha. Is there risk in pages assuming that if we implement the piece we implement then we also implement this other stuff? I believe all these APIs are feature detectable. Great, that should help with people not assuming stuff. Overall I expect to get reports of compat issues. That's fair. Again, the main question I have is whether giving our impl and the spec more bake time would help with this or just push it off while leaving the scope of the problem about the same. It sounds like you don't think it would really help, right? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Service Workers with FetchEvent
On Fri, Nov 20, 2015 at 3:30 PM, Boris Zbarskywrote: > > Another compat issue we need to fix is returning the same >> ServiceWorkerRegistration object repeatedly from certain APIs. This was >> something that changed a few times in both the spec and chrome. >> >> Fixing these minor compat issues is on our todo list for the rest of the >> 45 >> cycle leading up to orlando. >> > > OK. Are there plans to uplift any of this to 44? > No. I think what we have works on the sites/demos/wpt tests available today. We feel its compatible enough to ship. We'll fix further compat issues using our standard train model. > Overall I expect to get reports of compat issues. >> > > That's fair. Again, the main question I have is whether giving our impl > and the spec more bake time would help with this or just push it off while > leaving the scope of the problem about the same. It sounds like you don't > think it would really help, right? I think the best thing we can do right now is get a second implementation into wide circulation. This will highlight compat issues yes, but also help avoid baking chrome specific behavior into all the sites using service workers. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Service Workers with FetchEvent
On 11/20/15 3:42 PM, Ben Kelly wrote: No. I think what we have works on the sites/demos/wpt tests available today. We feel its compatible enough to ship. We'll fix further compat issues using our standard train model. OK. I think the best thing we can do right now is get a second implementation into wide circulation. This will highlight compat issues yes, but also help avoid baking chrome specific behavior into all the sites using service workers. Alright. Sounds scary, but I trust you've thought this stuff through. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Service Workers with FetchEvent
Also, webconsole logging for Service Workers is preffed behind devtools.webconsole.filter.serviceworkers, which will be enabled by default in https://bugzilla.mozilla.org/show_bug.cgi?id=1201962. Brian > On Nov 20, 2015, at 10:34 AM, Ben Kellywrote: > > In Firefox 44 we intend to enable Service Workers and FetchEvents by > default on desktop and android. These features will not be enabled on > Firefox OS yet. > > They has been developed behind the following preferences: > > dom.serviceWorkers.enabled > dom.serviceWorkers.interception.enabled > dom.serviceWorkers.interception.opaque.enabled > > Chrome has been shipping Service Workers with FetchEvent since Chrome 40. > > Unfortunately, I can't find a previous intent to implement for service > workers. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1226686 > Standard: > https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html > > Please let me know if you have any questions are concerns. > > Thanks. > > Ben > ___ > 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: Intent to ship: Service Workers with FetchEvent
On 11/20/15 1:34 PM, Ben Kelly wrote: Please let me know if you have any questions are concerns. I actually have a few questions. 1) How confident are we that the spec is stable/correct? 2) How confident are we that our implementation, Chrome's, and the spec all match? I know we were working on importing some of their tests, so I'm guessing fairly confident, but just wanted to check. 3) Have we heard anything from Apple or Microsoft about their plans, or lack thereof, for Service Workers? 4) Are there significant parts of the spec we're not shipping yet? Is Chrome shipping those parts? Is support for those feature-detectable? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Service Workers with FetchEvent
On Fri, Nov 20, 2015 at 3:21 PM, Ben Kellywrote: > > On Fri, Nov 20, 2015 at 3:01 PM, Boris Zbarsky wrote: > >> >> 1) How confident are we that the spec is stable/correct? >> > > The spec is converging to a stable v1, but things are still changing. The > core functionality has been stable for a while, though. > I guess I should mention the biggest change in the spec that has not been implemented by either chrome or firefox. The spec now exposes the Response.url passed to the FetchEvent.respondWith() to the outer network request. So base URLs for stylesheets and workers will have a different URL. A window doing fetch() will see a different Response.url. This was changed so that relative path subresources in stylesheets and workers will continue to work. I've mentioned to google it would be helpful to do a coordinated release for this particular spec change. Here is the chrome issue: https://code.google.com/p/chromium/issues/detail?id=553535 Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Service Workers with FetchEvent
On 11/20/15 3:26 PM, Ben Kelly wrote: I guess I should mention the biggest change in the spec that has not been implemented by either chrome or firefox. The spec now exposes the Response.url passed to the FetchEvent.respondWith() to the outer network request. So base URLs for stylesheets and workers will have a different URL. A window doing fetch() will see a different Response.url. This was changed so that relative path subresources in stylesheets and workers will continue to work. OK. So here the main risk that we'll ship something that has one relative path behavior, people will start using it, then we will switch it, right? Do we have a timeframe on when we could do the switch, ignoring for hte moment coordination problems with Google? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Service Workers with FetchEvent
On Fri, Nov 20, 2015 at 3:01 PM, Boris Zbarskywrote: > > 1) How confident are we that the spec is stable/correct? > The spec is converging to a stable v1, but things are still changing. The core functionality has been stable for a while, though. > 2) How confident are we that our implementation, Chrome's, and the spec > all match? I know we were working on importing some of their tests, so I'm > guessing fairly confident, but just wanted to check. > We imported blink's web-platform-tests. We found some spec issues with them and tried to flow them all back to both spec and google. There are some corner cases where we differ or might differ depending on release schedules. For example, the spec now says that navigations should set a RequestMode of "navigate", but neither chrome or firefox do this. We set "same-origin" as the spec used to say. I believe chrome has patches in flight to change, but we have not started yet. Another compat issue we need to fix is returning the same ServiceWorkerRegistration object repeatedly from certain APIs. This was something that changed a few times in both the spec and chrome. Fixing these minor compat issues is on our todo list for the rest of the 45 cycle leading up to orlando. Also, we have implemented more of the spec in some areas than chrome. For example, I believe chrome's Cache API is still not complete on their release channel. We have a complete Cache API already shipped in FF39. > 3) Have we heard anything from Apple or Microsoft about their plans, or > lack thereof, for Service Workers? > They have been attending face-to-face meetings, but no official implementation announcements as far as I know. The webkit project's 5 year plan includes service workers: http://trac.webkit.org/wiki/FiveYearPlanFall2015 > 4) Are there significant parts of the spec we're not shipping yet? Is > Chrome shipping those parts? Is support for those feature-detectable? > I don't think we are missing anything significant in the service worker spec. Other features building on top of service workers like push, background-sync, etc are in separate specs. Fetch body streams is something that was spec'd recently. Chrome has it partly implemented, but I don't think their shipping implementation is spec compatible. I believe all these APIs are feature detectable. Overall I expect to get reports of compat issues. I think thats inevitable with such a large feature and complex feature. We'll have to hash it out in spec issues, write WPT tests, and ship the fix. I'm not sure how else to realistically move forward, though. I hope that answers your questions. Thanks. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Performance.translateTime
On Thu, Nov 19, 2015 at 5:38 PM, Boris Zbarskywrote: >> Though Service Workers do actually have a 'client' object which >> represent window objects. So we could enable passing those as global >> to the translate function. > > That's a good idea. Want to raise it with the webperf WG? Seems like it > wouldn't be that hard to implement. I'd be quite happy if someone else would :) / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Service Workers with FetchEvent
On Sat, Nov 21, 2015 at 9:42 AM, Ben Kellywrote: > I think the best thing we can do right now is get a second implementation > into wide circulation. This will highlight compat issues yes, but also > help avoid baking chrome specific behavior into all the sites using service > workers. > Yes. This is incredibly important. Just look at the messaging in http://recode.net/2015/11/09/indias-flipkart-google-launch-chrome-mobile-website-replicate-apps/ 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