Re: Use-case for consideration, which will be difficult post-NPAPI
I would look over the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=988781 regarding future SC support via the WebCrypto JS APIs. I would hope that having a W3C spec for a smartcard API would encourage a common, cross-browser way to do this without plugins or addons. /a On 6/25/15 22:29, James May wrote: Have you considered using a local web server? That way you can use any native code you want, and it's a reasonably common approach. On many platforms you can even use socket activation to avoid the need for a always running server process. On 25 June 2015 at 21:04, Alex Taylor alex.tay...@referencepoint.co.uk wrote: Good morning. I have a use-case which will be difficult to reproduce in the post-NPAPI world: The use-case is a Java/NPAPI applet which uses the javax.smartcardio library to communicate with USB-connected contactless smartcard readers, from a web-page. Extremely useful functionality for our customers. Currently the applet will work in Firefox, Chrome and IE. With the deprecation of NPAPI, we are looking into ways to continue offering that functionality, and need to continue to target all three of those browsers if possible. For Chrome, I have looked into re-implementing the Java applet as a Chrome App, or using NaCl/PPAPI etc. I have not found any equivalent technology for Firefox as yet. Chrome Apps can connect to USB ports via the chrome.usb API, but there is currently no implementation of PC/SC for it (the smartcard access specifications that javax.smartcardio is also built on). Due to time constraints, re-implementing PC/SC ourselves is an option we would only choose as a last resort. In any case, that would only solve the problem for Chrome, not Firefox. Unfortunately, no technology I have looked into so far to solve this problem is able to offer the cross-browser support that Java/NPAPI enjoyed, and has an available PC/SC library. I flag this use-case for consideration in a future web-platform. I am sure we are not the only company who have combined smartcard io functionality with the web, and wish to continue doing so. If anyone knows of any technology or open-source project which might be useful for this situation, please let me know. Alex Taylor | Lead Developer [logo-291px] T: +44 (0)1753 27 99 27tel:+441753279927 | DD: +44 (0)1753 378 144tel: +441753378144 E: alex.tay...@referencepoint.co.ukmailto: alex.tay...@referencepoint.co.uk | Lync: alex.tay...@referencepoint.co.uk sip:alex.tay...@referencepoint.co.uk W: www.referencepoint.co.ukhttp://www.referencepoint.co.uk/ A: Reference Point Limited, Technology House, 2-4 High Street, Chalfont St. Peter, Gerrards Cross, SL9 9QA Right People. Right Skills. Right Place. Right Time. Registered in England No. 02156356 ___ 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 -- Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data and a new Browser API event
Removing dev-webapi since it's (near) dead. On Thu, Jun 25, 2015 at 7:19 PM, Benjamin Francis bfran...@mozilla.com wrote: Unless there's a really good reason not to do so, I'm going to file the bugs and look towards getting this implemented on the Browser API as soon as possible. What you outlined still seems like a rather giant hack to get this one thing working. Is the idea to just keep adding events for each bit of information we might need from a document? -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data and a new Browser API event
Le 26 juin 2015 à 08:00, Anne van Kesteren ann...@annevk.nl a écrit : What you outlined still seems like a rather giant hack to get this one thing working. Is the idea to just keep adding events for each bit of information we might need from a document? Maybe there is a way to start small. Iterate. Look at the results. And push further in the direction which appears to be meaningful. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: State synchronization - use cases?
On Fri, Jun 26, 2015 at 10:38 AM, Richard Barnes rbar...@mozilla.com wrote: Hey dev.platform folks, Some of us in the security engineering group have been chatting with cloud services about making an improved way to maintain state in the browser. Our use cases are things like: - Revoked certificates (OneCRL) - HSTS / HPKP preloads We're trying to get an idea of how big a data set we might want to maintain, so I wanted to see if anyone else had use cases that might benefit from such a mechanism. The critical properties for your data set to be suitable are: 1. You want every browser to have the same set of data 2. The data change relatively slowly (we are aiming for ~24hr deliveries) If anyone has use cases in addition to the above, please let me know. Thanks a lot, --Richar ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform UA overrides? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
State synchronization - use cases?
Hey dev.platform folks, Some of us in the security engineering group have been chatting with cloud services about making an improved way to maintain state in the browser. Our use cases are things like: - Revoked certificates (OneCRL) - HSTS / HPKP preloads We're trying to get an idea of how big a data set we might want to maintain, so I wanted to see if anyone else had use cases that might benefit from such a mechanism. The critical properties for your data set to be suitable are: 1. You want every browser to have the same set of data 2. The data change relatively slowly (we are aiming for ~24hr deliveries) If anyone has use cases in addition to the above, please let me know. Thanks a lot, --Richar ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: State synchronization - use cases?
The blocklist service also downloads about once a day On Fri, Jun 26, 2015 at 10:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 26, 2015 at 10:38 AM, Richard Barnes rbar...@mozilla.com wrote: If anyone has use cases in addition to the above, please let me know. Public suffix? Getting that updated more frequently would be good. Especially now sites like GitHub can use it to silo user data. -- 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: State synchronization - use cases?
On Fri, Jun 26, 2015 at 10:38 AM, Richard Barnes rbar...@mozilla.com wrote: If anyone has use cases in addition to the above, please let me know. Public suffix? Getting that updated more frequently would be good. Especially now sites like GitHub can use it to silo user data. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: State synchronization - use cases?
Tracking protection exceptions. I wrote a bug for this last night: https://bugzilla.mozilla.org/show_bug.cgi?id=1177641 On Fri, Jun 26, 2015 at 11:22 AM, Kyle Huey m...@kylehuey.com wrote: On Fri, Jun 26, 2015 at 10:38 AM, Richard Barnes rbar...@mozilla.com wrote: Hey dev.platform folks, Some of us in the security engineering group have been chatting with cloud services about making an improved way to maintain state in the browser. Our use cases are things like: - Revoked certificates (OneCRL) - HSTS / HPKP preloads We're trying to get an idea of how big a data set we might want to maintain, so I wanted to see if anyone else had use cases that might benefit from such a mechanism. The critical properties for your data set to be suitable are: 1. You want every browser to have the same set of data 2. The data change relatively slowly (we are aiming for ~24hr deliveries) If anyone has use cases in addition to the above, please let me know. Thanks a lot, --Richar ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform UA overrides? - Kyle ___ 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: Linked Data must die. (was: Linked Data and a new Browser API event)
On 26 June 2015 at 12:58, Ted Clancy tcla...@mozilla.com wrote: My apologies for the fact that this is such an essay, but I think this has become necessary. Firefox OS 2.5 will be unveiling a new feature called Pinning The Web, and there's been some discussion about whether we should leverage technologies like RDFa, Microdata, JSON-LD, Open Graph, and Microformats for this purpose. First, I'd like to give some background on these technologies. In 2001, Tim Berners-Lee said that the Semantic Web was the future of the web and was going to revolutionize our world. ( http://www.scientificamerican.com/article/the-semantic-web/) The Semantic Web was a doomed idea, for reasons best articulated in essay by Cory Doctorow entitled Metacrap, also written in 2001. ( http://www.well.com/~doctorow/metacrap.htm) After 14 years of the Semantic Web not revolutionizing our world, I think history suggests that Cory Doctorow was right. But because the Semantic Web was the next big thing, millions of dollars were poured into it (mostly in the form of research grants and crappy specs, from what I can gather). In 2004, RDFa became the first big standard to emerge from this work. RDFa is a W3C Recommendation, and work is still proceeding on it. JSON-LD was started in 2008 as a JSON-based alternative to RDFa. As the author of JSON-LD, Manu Sporny, states: RDF is a shitty data model. It doesn’t have native support for lists. LISTS for fuck’s sake! [...] to work with RDF you typically needed a quad store, a SPARQL engine, and some hefty libraries. Your standard web developer has no interest in that toolchain because it adds more complexity to the solution than is necessary. ( http://manu.sporny.org/2014/json-ld-origins-2/) However, though it originally wanted to distance itself from RDFa, JSON-LD ended up being chosen as a serialization for RDFa: Around mid-2012, the JSON-LD stuff was going pretty well and the newly chartered RDF Working Group was going to start work on RDF 1.1. One of the work items was a serialization of RDF for JSON. [...] The biggest problem being that many of the participants in the RDF Working Group at the time didn’t understand JSON. (ibid) (I just want everyone to note that in 2012, *THE AUTHORS OF RDFa DID NOT KNOW JSON*. This is in a spec that casually throws around propositional logic terms like entails, and subject-predicate-object triples.) JSON-LD is now a W3C recommendation, and has undergone added complexity to align it with RDFa. As Manu Sporny states, Nobody was happy with the result (ibid). Microdata is similar to RDFa, but without the benefit of being a W3C recommendation. Open Graph is a technology developed by Facebook. It's putatively a subset of RDFa. There is a small subset of Open Graph tags (og:title, og:type, og:url, and og:image) which are widely used for sharing content on social media like Facebook and Twitter. RDFa, Microdata, and JSON-LD can collectively be described as Linked Data technologies, so called because their intention is that semantic objects across different web pages would link to each other to create a Semantic Web. Microformats was developed circa 2005 as a lightweight way of putting semantic information into web pages, but does not aim to be a Linked Data or Semantic Web technology. It does not have an official standards body behind it, instead being maintained by a community of volunteers. One of our Mozilla employees, Tantek Çelik, was instrumental in its development. Thanks for the history lesson :) When I started to research this area I learnt very quickly that there are a lot of strong feelings on all sides about which format is the best, and many formats claim to supersede each other. The reality is that there's still no clear winner on the web. So what I've tried to do is to take a data driven approach to look at which syntaxes and vocabularies are getting the most traction according to research papers based on the Common Crawl corpus, the Bing corpus and the Yahoo corpus (all the data I've found so far). There are two high level requirements for the Pin the Web features: 1) Getting the most possible user value out of the data that already exists on the web today 2) Finding the best solution for the use cases we have in Gaia apps which can be implemented in the time frame we have for the 2.5 release (Feature Landing on 21st September) Based on the data available and the level of effort of implementation my most recent conclusions for those requirements were: 1) Open Graph 2) JSON-LD However, there's also a case for bonus points for a solution that we as Mozilla actually want to see used in the future! Okay, now I'd like to discuss whether or not we should use these technologies for Pinning The Web. Open Graph: I think we need to use the four tags og:title, og:type, og:url and og:image, since they are widely used. Apart from that, I don't think we need to support the rest of
Linked Data must die. (was: Linked Data and a new Browser API event)
My apologies for the fact that this is such an essay, but I think this has become necessary. Firefox OS 2.5 will be unveiling a new feature called Pinning The Web, and there's been some discussion about whether we should leverage technologies like RDFa, Microdata, JSON-LD, Open Graph, and Microformats for this purpose. First, I'd like to give some background on these technologies. In 2001, Tim Berners-Lee said that the Semantic Web was the future of the web and was going to revolutionize our world. ( http://www.scientificamerican.com/article/the-semantic-web/) The Semantic Web was a doomed idea, for reasons best articulated in essay by Cory Doctorow entitled Metacrap, also written in 2001. ( http://www.well.com/~doctorow/metacrap.htm) After 14 years of the Semantic Web not revolutionizing our world, I think history suggests that Cory Doctorow was right. But because the Semantic Web was the next big thing, millions of dollars were poured into it (mostly in the form of research grants and crappy specs, from what I can gather). In 2004, RDFa became the first big standard to emerge from this work. RDFa is a W3C Recommendation, and work is still proceeding on it. JSON-LD was started in 2008 as a JSON-based alternative to RDFa. As the author of JSON-LD, Manu Sporny, states: RDF is a shitty data model. It doesn’t have native support for lists. LISTS for fuck’s sake! [...] to work with RDF you typically needed a quad store, a SPARQL engine, and some hefty libraries. Your standard web developer has no interest in that toolchain because it adds more complexity to the solution than is necessary. ( http://manu.sporny.org/2014/json-ld-origins-2/) However, though it originally wanted to distance itself from RDFa, JSON-LD ended up being chosen as a serialization for RDFa: Around mid-2012, the JSON-LD stuff was going pretty well and the newly chartered RDF Working Group was going to start work on RDF 1.1. One of the work items was a serialization of RDF for JSON. [...] The biggest problem being that many of the participants in the RDF Working Group at the time didn’t understand JSON. (ibid) (I just want everyone to note that in 2012, *THE AUTHORS OF RDFa DID NOT KNOW JSON*. This is in a spec that casually throws around propositional logic terms like entails, and subject-predicate-object triples.) JSON-LD is now a W3C recommendation, and has undergone added complexity to align it with RDFa. As Manu Sporny states, Nobody was happy with the result (ibid). Microdata is similar to RDFa, but without the benefit of being a W3C recommendation. Open Graph is a technology developed by Facebook. It's putatively a subset of RDFa. There is a small subset of Open Graph tags (og:title, og:type, og:url, and og:image) which are widely used for sharing content on social media like Facebook and Twitter. RDFa, Microdata, and JSON-LD can collectively be described as Linked Data technologies, so called because their intention is that semantic objects across different web pages would link to each other to create a Semantic Web. Microformats was developed circa 2005 as a lightweight way of putting semantic information into web pages, but does not aim to be a Linked Data or Semantic Web technology. It does not have an official standards body behind it, instead being maintained by a community of volunteers. One of our Mozilla employees, Tantek Çelik, was instrumental in its development. Okay, now I'd like to discuss whether or not we should use these technologies for Pinning The Web. Open Graph: I think we need to use the four tags og:title, og:type, og:url and og:image, since they are widely used. Apart from that, I don't think we need to support the rest of Open Graph. RDFa, Microdata, and JSON-LD: I'd be afraid of using these. They were designed for something much bigger and more complicated than just pinning websites/contacts/events. I'd be afraid of people getting the idea that Mozilla supports RDFa, because that would give the wrong idea and just lead to disappointment and/or headache. Also, they are complex, and our developer effort is limited. JSON-LD has the additional problem that it exists separately from the content of the webpage, meaning that the JSON-LD data can get out-of-sync with the webpage, leading to confusion for users. (We've all see the way code comments quickly get out-of-sync with the code they purport to describe.) The argument has been made on this discussion list that RDFa and Microdata data is abundant, and so we should take advantage of it. But it's questionable how much of that data is actually good. The main use of RDFa and Microdata right now is for search engine optimization, which means the data isn't necessarily in a form presentable to the user. (Also, it might be all lies.) Microformats: Yes, we should use these. We've had support for Microformats in Firefox since Firefox 3 ( https://developer.mozilla.org/en-US/docs/Using_microformats), so it's just a matter of updating and expanding
Re: Linked Data and a new Browser API event
On 26 June 2015 at 08:29, Karl Dubost kdub...@mozilla.com wrote: Maybe there is a way to start small. Iterate. Look at the results. And push further in the direction which appears to be meaningful. Exactly, I'm looking for a solid MVP that we can iterate on. More detailed response to Ted's post coming... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Revisiting modelines in source files
On 18 June 2015 at 07:28, kgu...@mozilla.com wrote: 1) Comments that exceed the 80-char limit get wrapped blindly, rather than being rewrapped properly. This results in comment blocks that look like this: I sidestepped this issue by making Clang-Format ignore all comments. See bug 961541. Cheers, Biru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: Use-case for consideration, which will be difficult post-NPAPI
Adam – Thanks for that. Yes, including PC/SC in WebCrypto or another JS API would be ideal. Also hopefully FireBreath 2.0 will provide a useable cross-browser abstraction for the various new proprietary extension technologies, at which point using something like Adrian Castillo’s Smart Card Browser Plugin would become a possibility again. I don’t see that happening for a while though. Until then we may have to look at a thick-client/web-service solution as a fall-back, as we’ve done in the past. James – Using a local web server isn’t really an option in the environments we target, but thanks for the idea. Regards, Alex From: Adam Roach [mailto:a...@mozilla.com] Sent: 26 June 2015 07:05 To: James May; Alex Taylor Cc: dev-platform@lists.mozilla.org Subject: Re: Use-case for consideration, which will be difficult post-NPAPI I would look over the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=988781 regarding future SC support via the WebCrypto JS APIs. I would hope that having a W3C spec for a smartcard API would encourage a common, cross-browser way to do this without plugins or addons. /a On 6/25/15 22:29, James May wrote: Have you considered using a local web server? That way you can use any native code you want, and it's a reasonably common approach. On many platforms you can even use socket activation to avoid the need for a always running server process. On 25 June 2015 at 21:04, Alex Taylor alex.tay...@referencepoint.co.ukmailto:alex.tay...@referencepoint.co.uk wrote: Good morning. I have a use-case which will be difficult to reproduce in the post-NPAPI world: The use-case is a Java/NPAPI applet which uses the javax.smartcardio library to communicate with USB-connected contactless smartcard readers, from a web-page. Extremely useful functionality for our customers. Currently the applet will work in Firefox, Chrome and IE. With the deprecation of NPAPI, we are looking into ways to continue offering that functionality, and need to continue to target all three of those browsers if possible. For Chrome, I have looked into re-implementing the Java applet as a Chrome App, or using NaCl/PPAPI etc. I have not found any equivalent technology for Firefox as yet. Chrome Apps can connect to USB ports via the chrome.usb API, but there is currently no implementation of PC/SC for it (the smartcard access specifications that javax.smartcardio is also built on). Due to time constraints, re-implementing PC/SC ourselves is an option we would only choose as a last resort. In any case, that would only solve the problem for Chrome, not Firefox. Unfortunately, no technology I have looked into so far to solve this problem is able to offer the cross-browser support that Java/NPAPI enjoyed, and has an available PC/SC library. I flag this use-case for consideration in a future web-platform. I am sure we are not the only company who have combined smartcard io functionality with the web, and wish to continue doing so. If anyone knows of any technology or open-source project which might be useful for this situation, please let me know. Alex Taylor | Lead Developer [logo-291px] T: +44 (0)1753 27 99 27tel:+441753279927tel:+441753279927 | DD: +44 (0)1753 378 144tel:tel:+441753378144 +441753378144tel:+441753378144 E: alex.tay...@referencepoint.co.ukmailto:alex.tay...@referencepoint.co.ukmailto:mailto:alex.tay...@referencepoint.co.uk alex.tay...@referencepoint.co.ukmailto:alex.tay...@referencepoint.co.uk | Lync: alex.tay...@referencepoint.co.ukmailto:alex.tay...@referencepoint.co.uk sip:alex.tay...@referencepoint.co.ukmailto:sip:alex.tay...@referencepoint.co.uk W: www.referencepoint.co.ukhttp://www.referencepoint.co.ukhttp://www.referencepoint.co.uk/http://www.referencepoint.co.uk/ A: Reference Point Limited, Technology House, 2-4 High Street, Chalfont St. Peter, Gerrards Cross, SL9 9QA Right People. Right Skills. Right Place. Right Time. Registered in England No. 02156356 ___ dev-platform mailing list dev-platform@lists.mozilla.orgmailto:dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.orgmailto:dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Adam Roach Principal Platform Engineer a...@mozilla.commailto:a...@mozilla.com +1 650 903 0800 x863 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: State synchronization - use cases?
- gfx's GPU blocklist? - Shumway's SWF whitelist On 6/26/15 10:38 AM, Richard Barnes wrote: Hey dev.platform folks, Some of us in the security engineering group have been chatting with cloud services about making an improved way to maintain state in the browser. Our use cases are things like: - Revoked certificates (OneCRL) - HSTS / HPKP preloads We're trying to get an idea of how big a data set we might want to maintain, so I wanted to see if anyone else had use cases that might benefit from such a mechanism. The critical properties for your data set to be suitable are: 1. You want every browser to have the same set of data 2. The data change relatively slowly (we are aiming for ~24hr deliveries) If anyone has use cases in addition to the above, please let me know. Thanks a lot, --Richar ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data must die. (was: Linked Data and a new Browser API event)
On Fri, Jun 26, 2015 at 2:18 PM, Benjamin Francis bfran...@mozilla.com wrote: When I look at RDFa, Microdata and JSON-LD I see formal W3C recommendations, extensive vocabularies which (at least on the surface) are agreed on by all the big search engines, and I see a clean engineering solution (albeit fairly complex). Based on this kind of reasoning we almost ended up with XForms. I would encourage you to go a little deeper. Let's make it clear for all of dev.platform, a W3C Recommendation means nothing. Pretty much anyone can get one. We need to judge standards on their merits and not jump on the next XForms/XML/WS-*/SVG bandwagon. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
From your blog post: Heavy activity in background tabs badly affects desktop Firefox’s scrolling performance1 (much worse than other browsers — we need E10S) I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. Have we ever considered building something like the unload tab addon into the platform or Firefox directly? I know we do some throttling of timeouts, but perhaps we should also consider this heavier handed approach when there are many tabs open. https://addons.mozilla.org/en-US/firefox/addon/unloadtab/ An essential add-on for power users that have many tabs open. Curb your resource usage by unloading tabs that you haven't visited for a while. An unloaded tab is restored back to its original state when you need it again. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data must die. (was: Linked Data and a new Browser API event)
On 26 June 2015 at 17:02, Anne van Kesteren ann...@annevk.nl wrote: I would encourage you to go a little deeper... We need to judge standards on their merits I did look deeper. I read most of all the specifications and several papers on their adoption. My personal conclusion was that not only does Microformats appear to be used less widely than other competing formats, but that from a technical point of view just adding h- prefixes to class names seems like a massive hack. Many of the arguments I've heard in favour of Microformats are that it's the grassroots or non-evil solution. It's equally true that not being a W3C recommendation doesn't automatically make something better either. But I'm not the person that will have to implement this, and the people who are think we should use Microformats. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: State synchronization - use cases?
At last! Hallelujah! :-) On 26/06/15 10:38, Richard Barnes wrote: 1. You want every browser to have the same set of data 2. The data change relatively slowly (we are aiming for ~24hr deliveries) If anyone has use cases in addition to the above, please let me know. * The Public Suffix List. * User Agent overrides. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data and a new Browser API event
On 26 June 2015 at 08:00, Anne van Kesteren ann...@annevk.nl wrote: Is the idea to just keep adding events for each bit of information we might need from a document? That is how the Browser API works. Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. That's right, but we also tested e10s in the process-per-tab configuration Have we ever considered building something like the unload tab addon into the platform or Firefox directly? We have talked about it (BarTab Heavy is another example) and the code that Yoric wrote for measuring per-compartment main-thread CPU-usage in about:performance could be used for this. It's unclear how to prioritize it though because doing 100% reliable heavy tab detection will require non-trivial effort (see issues with slow-addon info bar) and the background tab problem will mostly be mitigated by process-per-tab e10s. On Fri, Jun 26, 2015 at 5:12 PM, Nick Fitzgerald nfitzger...@mozilla.com wrote: From your blog post: Heavy activity in background tabs badly affects desktop Firefox’s scrolling performance1 (much worse than other browsers — we need E10S) I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. Have we ever considered building something like the unload tab addon into the platform or Firefox directly? I know we do some throttling of timeouts, but perhaps we should also consider this heavier handed approach when there are many tabs open. https://addons.mozilla.org/en-US/firefox/addon/unloadtab/ An essential add-on for power users that have many tabs open. Curb your resource usage by unloading tabs that you haven't visited for a while. An unloaded tab is restored back to its original state when you need it again. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data and a new Browser API event
On Thu, Jun 25, 2015 at 7:19 PM, Benjamin Francis bfran...@mozilla.com wrote: and JSON-LD (because it supports Gaia's more complex use cases). Hi Ben, My only concern here is that if you pin a contact, it seems to me that it would be good if the name and picture of that homescreen UI should be quickly updated if the user changes the name/picture of the contact. So I think that for pins of contacts, we should call into the contacts API rather than rely on the metadata extracted from the webpage. I'm not sure if we might still need JSON-LD for other gaia use cases though, like pinning a song from the music app or an image from the gallery? / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: State synchronization - use cases?
Yes; that is what we currently use for OneCRL. The idea here is to make something that's more generic, in order to more easily support pushing new types of data. That said, I suppose we could envision moving the add on block list to this service if it happens. But that might not be a priority, because it already exists. Sent from my iPhone. Please excuse brevity. On Jun 26, 2015, at 10:56, Dave Townsend dtowns...@mozilla.com wrote: The blocklist service also downloads about once a day On Fri, Jun 26, 2015 at 10:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 26, 2015 at 10:38 AM, Richard Barnes rbar...@mozilla.com wrote: If anyone has use cases in addition to the above, please let me know. Public suffix? Getting that updated more frequently would be good. Especially now sites like GitHub can use it to silo user data. -- 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Announcing the Content Performance program
Aaron Klotz, Avi Halachmi and I have been studying Firefox's performance on Android Windows over the last few weeks as part of an effort to evaluate Firefox content performance and find actionable issues. We're analyzing and measuring how well Firefox scrolls pages, loads sites, and navigates between pages. At first, we're focusing on 3 reference sites: Twitter, Facebook, and Yahoo Search. We're trying to find reproducible, meaningful, and common use cases on popular sites which result in noticeable performance problems or where Firefox performs significantly worse than competitors. These use cases will be broken down into tests or profiles, and shared with platform teams for optimization (feeding into Platform's 60fps initiative). This Content Performance project is part of the larger organizational effort to improve Firefox quality. This is the first progress update: https://blog.mozilla.org/vdjeric/2015/06/26/announcing-the-content-performance-program/ I'll try to regularly post about our progress. You can can also track our efforts on our mailing list and IRC channel: Mailing list: https://mail.mozilla.org/listinfo/contentperf IRC channel: #contentperf Project wiki page: https://wiki.mozilla.org/Firefox/Content_Performance_Program ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data and a new Browser API event
On Fri, Jun 26, 2015 at 5:37 PM, Benjamin Francis bfran...@mozilla.com wrote: On 26 June 2015 at 08:00, Anne van Kesteren ann...@annevk.nl wrote: Is the idea to just keep adding events for each bit of information we might need from a document? That is how the Browser API works. I don't think that we should be terribly worried about what the browser API does or does not do. The main consumer of the browser API is the Gaia system app. The system app is for most intents end purposes part of Gecko. And it is absolutely part of the UA. Som from this point of view the Browser API is no different from an internal Gecko API like nsIWebProgressListener. We do also expose the browser API to signed 3rd party content. But it has relatively few consumers and thanks to the signing if we need to deprecate all or parts of the API we can reach out to all those consumers and work out a deprecation plan. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
