Re: status-firefox41: affected
Bugzilla has defaulted to marking new bugs as status-firefoxXX: affected. I'm not sure when it started but this is why. Hope that helps, Jared On Sat, May 30, 2015 at 11:58 AM, Philip Chee wrote: > Why are these SeaMonkey bugs flagged status-firefox41: affected > > https://bugzilla.mozilla.org/buglist.cgi?f1=cf_status_firefox41&list_id=12290852&o1=anyexact&query_format=advanced&f2=OP&v1=affected&product=SeaMonkey > > Why are these SeaMonkey bugs flagged status-firefox40: affected > > https://bugzilla.mozilla.org/buglist.cgi?f1=cf_status_firefox40&list_id=12290852&o1=anyexact&query_format=advanced&f2=OP&v1=affected&product=SeaMonkey > > Thunderbird: > > https://bugzilla.mozilla.org/buglist.cgi?j_top=OR&list_id=12290869&o1=equals&v1=affected&f1=cf_status_firefox40&o3=equals&v3=affected&query_format=advanced&f3=cf_status_firefox40&f2=OP&product=MailNews > Core&product=Thunderbird > > History doesn't show anyone manually marking these bugs > status-firefox40/status-firefox41 > > Some filter rule going bonkers? > > 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 > ___ 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
We should consider a series of fallbacks for this internal API. The metadata story for things like icon, title, description, hero images, is complicated. Implementation in the follows real-world use cases like posting rich snippets to Facebook or getting an image to show up on Twitter, rather than some standard. I think it would be best to think of this kind of API as a sort of light "scraper" that crawls through a collection of known in-the-wild patterns to provide a good-enough answer. --- Gordon Brander Sr Design Strategist Mozilla > On May 30, 2015, at 13:09, Jonas Sicking wrote: > > We should use whatever formats people are using to mark up pages. If that > is microdata we should use that. If it's RDF we should use that. If its > JSONLD we should use that. > > The API that is used to extract the data is irrelevant. That will be an > internal API anyway. Effectively we should think of the browser api as an > internal api. There is no way it will be standardized in any relevant > timeframe. > > / Jonas >> On May 29, 2015 16:57, "Anne van Kesteren" wrote: >> >> On Fri, May 29, 2015 at 2:55 AM, Benjamin Francis >> wrote: >>> Actually what might make more sense is a getLinkedData() method on the >> API >>> which returns a Promise that resolves with the JSON data, as I think >> we're >>> also going to need a getManifest() method which could work in a similar >> way. >> >> We've bitten ourselves before going down the RDF rathole (see >> extensions et al). Not sure we should so rapidly start again. Why >> can't you use the Microdata API? >> >> >> -- >> https://annevankesteren.nl/ >> ___ >> dev-webapi mailing list >> dev-web...@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-webapi > ___ > dev-webapi mailing list > dev-web...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-webapi ___ 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
We should use whatever formats people are using to mark up pages. If that is microdata we should use that. If it's RDF we should use that. If its JSONLD we should use that. The API that is used to extract the data is irrelevant. That will be an internal API anyway. Effectively we should think of the browser api as an internal api. There is no way it will be standardized in any relevant timeframe. / Jonas On May 29, 2015 16:57, "Anne van Kesteren" wrote: > On Fri, May 29, 2015 at 2:55 AM, Benjamin Francis > wrote: > > Actually what might make more sense is a getLinkedData() method on the > API > > which returns a Promise that resolves with the JSON data, as I think > we're > > also going to need a getManifest() method which could work in a similar > way. > > We've bitten ourselves before going down the RDF rathole (see > extensions et al). Not sure we should so rapidly start again. Why > can't you use the Microdata API? > > > -- > https://annevankesteren.nl/ > ___ > dev-webapi mailing list > dev-web...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-webapi > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: DBM code too old (Re: mozmill test: Hightail ???)
On 29/05/2015 22:31, ISHIKAWA, Chiaki wrote: > I figured out the particular cause of > test-cloudfile-backend-hightail.js. > experienced during |make mozmill| when I simulated "short read" and > "short write" to files > under the profile directory used by the test was that > *.db files managed by Berkeley DB 1.85 (presumably by the code below > mozilla/security/nss/lib/dbm/src/) experienced failures. According to Google, current versions of NSS can use SQLite for its backend. Butt the file names are different: key3.db -> key4.db cert8.db -> cert9.db secmod.db -> pkcs11.txt https://wiki.mozilla.org/NSS_Shared_DB https://blogs.oracle.com/meena/entry/what_s_new_in_nss1 Advantage is that Firefox/Thunderbird/SeaMonkey can all share the same files > However, now that Sleepycat has been bought by Oracle, I am not sure > what is the good option left. I think v5 of Berkeley DB is still under the Sleepycat licence. 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
status-firefox41: affected
Why are these SeaMonkey bugs flagged status-firefox41: affected https://bugzilla.mozilla.org/buglist.cgi?f1=cf_status_firefox41&list_id=12290852&o1=anyexact&query_format=advanced&f2=OP&v1=affected&product=SeaMonkey Why are these SeaMonkey bugs flagged status-firefox40: affected https://bugzilla.mozilla.org/buglist.cgi?f1=cf_status_firefox40&list_id=12290852&o1=anyexact&query_format=advanced&f2=OP&v1=affected&product=SeaMonkey Thunderbird: https://bugzilla.mozilla.org/buglist.cgi?j_top=OR&list_id=12290869&o1=equals&v1=affected&f1=cf_status_firefox40&o3=equals&v3=affected&query_format=advanced&f3=cf_status_firefox40&f2=OP&product=MailNews Core&product=Thunderbird History doesn't show anyone manually marking these bugs status-firefox40/status-firefox41 Some filter rule going bonkers? 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: Linked Data and a new Browser API event
On 30 May 2015 at 00:56, Anne van Kesteren wrote: > We've bitten ourselves before going down the RDF rathole (see > extensions et al). Not sure we should so rapidly start again. Why > can't you use the Microdata API? > Is this already supported in Gecko? I can't find it documented anywhere, except a partial implementation in bug 591467 and a suggestion to remove it again in bug 909633. If it was then that would help, but it wouldn't quite solve the problem we're trying to solve here. We need to get the Linked Data from an embedded mozbrowser iframe for use in the system app and we don't have access the Document object (hence the Browser API). If there was an implementation of the Microdata DOM API I guess we could hook up a getLinkedData() method to that inside Gecko. But Microdata is only one of the formats widely used on the web today. I'd like to see some evidence-based discussion on which format(s) we should support to get the most possible value out of what already exists on the web. The examples we used in our prototype all use Open Graph, which seems quite widely used (mainly due to Facebook and Twitter) and is based on RDFa. JSON-LD seems like a convenient format which can express them all, and is useful in its own right. We could quite easily detect script tags in the DOM like
