Re: Terminating xulrunner?
Wow. All this just as I'm trying to get XULRunner repaired and stabilized for good with automated tests. I put a lot of effort into reviving the damn thing, and I'm close to getting it working again on the Mac. (More to the point, I'm obsessed with getting it working on the Mac again - and I know I'm getting close. There are heartbeats, I'm telling you.) I'm willing to own XULRunner and actively maintain it. People on this thread know I've been an advocate for it, and that I've submitted several patches to bring it back. I have been working with XULRunner for two years. If you are going to kill XULRunner off entirely in favor of firefox -app, then do it, *get it over with*, and write a XULRunner Considered Harmful blog post on planet mozilla. I don't know. Maybe building an SDK based on Firefox is the right thing; honestly, I just want something that works. But I put a lot of effort into this over the last two years. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On Tue, Jan 14, 2014 at 12:55:03AM -0800, ajvinc...@gmail.com wrote: Wow. All this just as I'm trying to get XULRunner repaired and stabilized for good with automated tests. I put a lot of effort into reviving the damn thing, and I'm close to getting it working again on the Mac. (More to the point, I'm obsessed with getting it working on the Mac again - and I know I'm getting close. There are heartbeats, I'm telling you.) I'm willing to own XULRunner and actively maintain it. People on this thread know I've been an advocate for it, and that I've submitted several patches to bring it back. I have been working with XULRunner for two years. If you are going to kill XULRunner off entirely in favor of firefox -app, then do it, *get it over with*, and write a XULRunner Considered Harmful blog post on planet mozilla. I don't know. Maybe building an SDK based on Firefox is the right thing; honestly, I just want something that works. But I put a lot of effort into this over the last two years. FWIW, I packaged xulrunner in Debian in 2006 and have been maintaining it since then. Iceweasel (rebranded Firefox) has been built against xulrunner since 2008. I put a lot of effort into xulrunner over the last eight years. It's time to face the truth and let go. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reftests execute differently on Android or b2g?
On Wed, Jan 8, 2014 at 9:22 PM, Neil n...@parkwaycc.co.uk wrote: Ah, but it makes a subtle difference to the way XHR works; from a server, it will parse according to the MIME type, which was HTML in my case, but from a file:// URL, it always parses in XML, even if the document would normally load as HTML (i.e. you XHR for a .html document). I certainly found this behaviour unexpected, even if it isn't a bug. There's a method called overrideMimeType() on XHR. This then triggered another unexpected behaviour, which is that XHR's XML parsing blocks onload but its HTML parsing does not. A more likely explanation is that some of our channel types, including file:, can file OnStartRequest, OnDataAvailable and OnStopRequest without spinning the event loop in between. I think this is harmful because it deviates from how http[s] channels work, but changing Necko to make this not be the case isn't really my area. The HTML parser sends the data to another thread, so even when a channel behaves badly, the HTML parser cannot finish without the event loop spinning before stuff can come back from the other thread. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reftests execute differently on Android or b2g?
Henri Sivonen wrote: On Wed, Jan 8, 2014 at 9:22 PM, Neil n...@parkwaycc.co.uk wrote: Ah, but it makes a subtle difference to the way XHR works; from a server, it will parse according to the MIME type, which was HTML in my case, but from a file:// URL, it always parses in XML, even if the document would normally load as HTML (i.e. you XHR for a .html document). I certainly found this behaviour unexpected, even if it isn't a bug. There's a method called overrideMimeType() on XHR. Sure, but I wasn't expecting to have to override the MIME type to the type that gets used when you load the file in the browser. This then triggered another unexpected behaviour, which is that XHR's XML parsing blocks onload but its HTML parsing does not. A more likely explanation is that some of our channel types, including file:, can file OnStartRequest, OnDataAvailable and OnStopRequest without spinning the event loop in between. Indeed, the XML parsing didn't block when I switched to serving the reftest from the HTTP server, and I had to add a dummy progress listener to restore blocking behaviour. (Android and b2g reftests detected this for me because they always serve from HTTP.) I can't remember whether I tried HTML parsing over HTTP with a progress listener. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
- Original Message - I don't know. Maybe building an SDK based on Firefox is the right thing; honestly, I just want something that works. But I put a lot of effort into this over the last two years. FWIW, I packaged xulrunner in Debian in 2006 and have been maintaining it since then. Iceweasel (rebranded Firefox) has been built against xulrunner since 2008. I put a lot of effort into xulrunner over the last eight years. It's time to face the truth and let go. I will be sad to see XULRunner go too. It's the reason I started using Mozilla-tech, and eventually joined Mozilla. We've know something for a long time: If Mozilla is not using a tech/project in Firefox, support for the tech/project will wither. However, sometimes we can create a different version of the tech/project that *is* used by Firefox and therefore much better supported by Mozilla. It's not a guarantee, but it helps. That's why I loved seeing | firefox --app | happen and continue to evolve. The new webapprt is a strong replacement for Prism/Chromeless. We even started an Android embedding widget (GeckoView) to power Firefox for Android. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reftests execute differently on Android or b2g?
On 14/01/14 12:45, Neil wrote: Indeed, the XML parsing didn't block when I switched to serving the reftest from the HTTP server, and I had to add a dummy progress listener to restore blocking behaviour. Progress listeners blocking onload is a bug. Please don't rely on it in tests (or outside of tests). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Target Milestone field in bugzilla
On Friday, January 10, 2014 4:56:45 PM UTC-5, David Lawrence wrote: Currently Bugzilla does not support relabeling of fields in the UI based on some criteria. They are pretty well hard coded with the names. It would be a non-trivial amount of work to add the support and it would definitely not be something we could shift upstream. So we would need to maintain the customization going forward. To further clarify what I meant when I said this was not an easy change in the BMO code, I did not mean to say it was technically difficult. It is just that the target milestone label is hard coded in more than just the standard bug view. It is also in the email notifications sent out, the search form, the columns in a results page for a search, webservice data that is returned, the activity page for a bug, all documentation, and other places I may have missed. To do this properly we would need to update most of those places as well to change the label based on the product value. And of course it it proves to be useful then other projects will want different labels for their products and it may not end with target milestone. I was just saying that we should look at all options before we commit to going that route. dkl ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Target Milestone field in bugzilla
After some discussion with other BMO devs, how about this proposal? We add a (info) link next to the Milestone label on the show_bug.cgi page that has some custom documentation explaining the purpose of the field for the selected product? We can make the text different for different products as needed. We already do something similar for Product and component if you want to see an example in place. Thoughts? dkl ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Target Milestone field in bugzilla
That sounds pretty reasonable to me. Cheers, kats On 14-01-14 10:59 , dklaw...@gmail.com wrote: After some discussion with other BMO devs, how about this proposal? We add a (info) link next to the Milestone label on the show_bug.cgi page that has some custom documentation explaining the purpose of the field for the selected product? We can make the text different for different products as needed. We already do something similar for Product and component if you want to see an example in place. Thoughts? dkl ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
I have a couple concerns. 1. It makes it much more difficult to ship a site specific browser that can be installed alongside Firefox (especially if that browser might need to be different than the installed Firefox, like based on the ESR). It would seem that the best method would be to take a firefox install, remove any bits that are Firefox and install that. I'm not sure legal would like that. 2. It creates licensing issues. Previously, we would ship XULRunner and there were no Firefox trademarks involved. If we are shipping actual Firefox with modifications for our application, I would assume it would have to go through Firefox legal. I think the stub to launch the app is a must have. I do not want to ship firefox.exe to customer that need a site specific browser and create an icon that launches firefox with -app. I need to be able to deliver them a named EXE just like any other application. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
Guys, I get it. I'm not happy about it, especially having wasted a lot of the last two years on it, but I get it. One day, the beast cast its eye on its unruly cousin, and lost his patience. Many fine people tried to spare the cousin, but the beast swallowed its cousin whole. Its belch was like a volcano erupting, and traveled as fast as the fox itself. Even so, many lamented at the time the loss of a dream... unwisely in the eyes of several high priests. For the betterment of all, the reconciliation was swift to arrive and comforting to all. -- not every passage from the Book of Mozilla can be a happy one. I'm idly wondering when I became timeless, the guy who fights the wisdom of his peers most futilely. :-) (I know him, so I can say that.) On Tue, Jan 14, 2014 at 6:16 AM, Mark Finkle mfin...@mozilla.com wrote: -- I don't know. Maybe building an SDK based on Firefox is the right thing; honestly, I just want something that works. But I put a lot of effort into this over the last two years. FWIW, I packaged xulrunner in Debian in 2006 and have been maintaining it since then. Iceweasel (rebranded Firefox) has been built against xulrunner since 2008. I put a lot of effort into xulrunner over the last eight years. It's time to face the truth and let go. I will be sad to see XULRunner go too. It's the reason I started using Mozilla-tech, and eventually joined Mozilla. We've know something for a long time: If Mozilla is not using a tech/project in Firefox, support for the tech/project will wither. However, sometimes we can create a different version of the tech/project that *is* used by Firefox and therefore much better supported by Mozilla. It's not a guarantee, but it helps. That's why I loved seeing | firefox --app | happen and continue to evolve. The new webapprt is a strong replacement for Prism/Chromeless. We even started an Android embedding widget (GeckoView) to power Firefox for Android. -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
One more thought. How will updating work? If you are running an app with application.ini, it's not going to get it's updates through the Firefox update service, even though you have Firefox installed. So you'll have to somehow rebundle Firefox with your application and send that as an update? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On 1/14/2014 2:30 PM, mka...@gmail.com wrote: On Tuesday, January 14, 2014 1:06:19 PM UTC-6, Benjamin Smedberg wrote: Or do a repack to remove the Firefox-specific files from a Firefox install. Certainly without branding issues it's not a problem anyway, right? So in my testing, this worked perfectly. If we could solve the stub problem, I don't see why this can't be a perfect replacement for xulrunner. I don't think we need to solve the stub problem to implement this plan; I'll take patches which compile a generic stub into the SDK. firefox.exe is after basically the stub already with embedded icons and whatnot. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On Tuesday, January 14, 2014 1:40:13 PM UTC-6, Benjamin Smedberg wrote: On 1/14/2014 2:30 PM, mka...@gmail.com wrote: On Tuesday, January 14, 2014 1:06:19 PM UTC-6, Benjamin Smedberg wrote: If we could solve the stub problem, I don't see why this can't be a perfect replacement for xulrunner. I don't think we need to solve the stub problem to implement this plan; I'll take patches which compile a generic stub into the SDK. firefox.exe is after basically the stub already with embedded icons and whatnot. The reason the stub is important is because of Windows jumplists. Even if you use a resource editor to change all of the internals of the Firefox executable, if Firefox is installed on that machine, you'll end up with Firefox and the firefox logo on the jump list and when you select Firefox it will try to start Firefox using the loaded instance. So you'll get a profile manager XUL error if you've removed all the Firefox cruft. We need a stub executable to make sure this never happens. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On Sunday, January 12, 2014 4:34:54 PM UTC-8, Mike Hommey wrote: - We could include the xulrunner and xulrunner-stub executables as part of firefox. xulrunner-stub is small and self-contained, and xulrunner could be replaced by something that calls firefox -app. Or we could make the firefox executable check under what name it's called and act accordingly. As I stated earlier, if we get this going quickly, I have no long-term objection. That said, it's almost time for an ESR cycle on mozilla-central, and that is cause for concern. I'd like to get a clarified list of requirements for the Firefox SDK: * Will we support a stub executable? * Will we support an install-app capability in the SDK? * Will Mac SDK users be able to create .app files that actually work? * Will they have a XUL.framework in them? * Will we still publish headers, binary tools, etc. in a convenient package for component developers to use? * Can we import Philipp Kewisch's wonderful remote debugger extension, so that Firefox can remotely debug the XULRunner app? (By the way, that works in XR apps now.) * Will we have automated regression tests run daily to make sure the SDK is still viable? * What obvious requirements am I missing from this list? * Can we get everything in place and make an ESR SDK as well? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On 1/14/2014 3:17 PM, ajvinc...@gmail.com wrote: I'd like to get a clarified list of requirements for the Firefox SDK: * Will we support a stub executable? If somebody writes a patch to include a stub executable in the SDK, I will accept that patch. If you include automated tests for it, I'll count that as a form of support. But if it breaks, we wouldn't close the tree or block the release on it. * Will we support an install-app capability in the SDK? If you want to include those scripts in the SDK, I'll review it. * Will Mac SDK users be able to create .app files that actually work? I don't know. If somebody does the work, sure! * Will they have a XUL.framework in them? Probably not. * Will we still publish headers, binary tools, etc. in a convenient package for component developers to use? We will continue to publish the SDK. * Can we import Philipp Kewisch's wonderful remote debugger extension, so that Firefox can remotely debug the XULRunner app? (By the way, that works in XR apps now.) Maybe? * Will we have automated regression tests run daily to make sure the SDK is still viable? Probably not. Even if somebody wrote the test framework, this is low priority compared with other tasks that automation or releng have. * Can we get everything in place and make an ESR SDK as well? I don't think it matters. The SDK isn't supposed to change between security dot releases, so typically you wouldn't need a new one; you'd just keep using the base version for the life of the ESR release. But at the same time, if the SDK is a byproduct of the Firefox build, we'll get it for free with the Firefox ESR builds. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: Progress Events
On Wednesday 2013-12-18 12:50 +, Anne van Kesteren wrote: On Mon, Dec 16, 2013 at 6:23 PM, Kyle Huey m...@kylehuey.com wrote: Should we be explicitly voting in favor of this one too? I suppose. We implement it :-) OK, I've done so (without further comments). -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
W3C Proposed Recommendations: RDF 1.1
There are eight W3C Proposed Recommendations for RDF 1.1 (two of which are actually Proposed Edited Recommendations): RDF Schema 1.1: W3C Proposed Edited Recommendation 09 January 2014 http://www.w3.org/TR/rdf-schema/ RDF 1.1 XML Syntax: W3C Proposed Edited Recommendation 09 January 2014 http://www.w3.org/TR/rdf-syntax-grammar/ RDF 1.1 N-Quads: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/n-quads/ RDF 1.1 N-Triples: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/n-triples/ RDF 1.1 Concepts and Abstract Syntax: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/rdf11-concepts/ RDF 1.1 Semantics: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/rdf11-mt/ RDF 1.1 TriG: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/trig/ RDF 1.1 Turtle: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/turtle/ There's a call for review to W3C member companies (of which Mozilla is one) open until February 9. If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) My inclination is to explicitly abstain to indicate this is something we're not interested or involved in. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendations: RDF 1.1
As, still, module owner of RDF, I think that's the right thing for us to do. I haven't actually followed the development of the specs, but I'm positive that the development of those specifications doesn't impact us as a browser vendor. The impact of RDF is in the web application and addons system. Axel On 1/14/14 11:04 PM, L. David Baron wrote: There are eight W3C Proposed Recommendations for RDF 1.1 (two of which are actually Proposed Edited Recommendations): RDF Schema 1.1: W3C Proposed Edited Recommendation 09 January 2014 http://www.w3.org/TR/rdf-schema/ RDF 1.1 XML Syntax: W3C Proposed Edited Recommendation 09 January 2014 http://www.w3.org/TR/rdf-syntax-grammar/ RDF 1.1 N-Quads: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/n-quads/ RDF 1.1 N-Triples: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/n-triples/ RDF 1.1 Concepts and Abstract Syntax: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/rdf11-concepts/ RDF 1.1 Semantics: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/rdf11-mt/ RDF 1.1 TriG: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/trig/ RDF 1.1 Turtle: W3C Proposed Recommendation 09 January 2014 http://www.w3.org/TR/turtle/ There's a call for review to W3C member companies (of which Mozilla is one) open until February 9. If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) My inclination is to explicitly abstain to indicate this is something we're not interested or involved in. -David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
