Re: did mozilla postponed electrlolysis firefox to version 42?
On Mon, Dec 29, 2014 at 11:28 PM, Yaron Kahanovitch yaronkahanovi...@gmail.com wrote: Firefox 2015 roadmap states that e10 will be released with fireox42. I thought that e10 will be released with firefox 36. Does anyone knows where to get more detail information about that? Sorry to get your hopes up, but we never planned to release e10s with Firefox 36. We're holding e10s on the nightly channel until it's stable enough to roll out to aurora. So we disabled e10s about a week before 36 merged to aurora and then we re-enabled it on nightly shortly after the merge. We'll probably do the same thing when 37 merges to aurora. We have a set of eight milestones for Electrolysis. Milestones 1 through 3 are finished and we're working on milestone 4. When milestone 6 is complete, we'll roll out on aurora. When milestone 8 is complete, we'll roll out to beta. You can track the progress of each milestone by searching for bugs in bugzilla with a given tracking-e10s value. For example, tracking-e10s=m4+ is for milestone 4 bugs. -Bill ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: did mozilla postponed electrlolysis firefox to version 42?
hi, thanks for the reply. It seems that I need to confirm rumors about about firefox with bugzilla. On Tuesday, December 30, 2014 10:27:19 AM UTC+2, William McCloskey wrote: On Mon, Dec 29, 2014 at 11:28 PM, Yaron Kahanovitch yaronkahanovitch... wrote: Firefox 2015 roadmap states that e10 will be released with fireox42. I thought that e10 will be released with firefox 36. Does anyone knows where to get more detail information about that? Sorry to get your hopes up, but we never planned to release e10s with Firefox 36. We're holding e10s on the nightly channel until it's stable enough to roll out to aurora. So we disabled e10s about a week before 36 merged to aurora and then we re-enabled it on nightly shortly after the merge. We'll probably do the same thing when 37 merges to aurora. We have a set of eight milestones for Electrolysis. Milestones 1 through 3 are finished and we're working on milestone 4. When milestone 6 is complete, we'll roll out on aurora. When milestone 8 is complete, we'll roll out to beta. You can track the progress of each milestone by searching for bugs in bugzilla with a given tracking-e10s value. For example, tracking-e10s=m4+ is for milestone 4 bugs. -Bill ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Win64 builds tests coming soon!
hi Chris, we are waiting for firefox 64 bit. Do you know what will be the first firefox version to be officially released to 64 bits? thanks yaron kahanovitch On Tuesday, October 21, 2014 11:02:02 PM UTC+3, Chris AtLee wrote: Hi, Just a quick note that we're hoping to enable 64-bit windows builds tests across most trunk branches this week. This includes branches such as mozilla-central, mozilla-inbound, fx-team, etc. In order to get adequate test coverage without at the same time overwhelming our windows test infrastructure, we've decided to disable 32-bit windows 8 testing on these branches and enable 64-bit windows 8 testing instead. Work is being tracked in bug 1080134 [1]. Please follow up there, or find me in #releng. Cheers, Chris [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1080134 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules
Is there a bug for the changes being discussed here, and is it marked with dev-doc-needed? Sounds like there will be, at a minimum, a few tweaks to the discussion about how this stuff works. Thanks! Eric Shepherd Developer Documentation Lead Mozilla http://www.bitstampede.com/ On Dec 27, 2014, at 8:50 PM, L. David Baron dba...@dbaron.org wrote: On Sunday 2014-12-28 03:04 +0900, Michael[tm] Smith wrote: So as long as the spec is going to require UAs to resort to magic behavior, I think the magic could instead just be autohide any ruby annotations for kana characters. And then you could just have simpler markup like this: ruby振り仮名rtふりがな/rt/ruby ...and UAs would display as expected -- with no annotation for the り. I don't see how UAs could determine which kana to eliminate. What if the markup were instead: ruby振り仮名rtふりりがな/rt/ruby (After all, many characters need more than one kana for their ruby.) How would the browser know whether to center ふり over 振, hide the second り, and center がな over 仮名, or whether to center ふ over 振, hide the first り, and center りがな over 仮名? The split between container and annotation is what gives the browser the information to do that separation correctly. -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) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform smime.p7s Description: S/MIME cryptographic signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules
On Tuesday 2014-12-30 12:14 -0500, Eric Shepherd wrote: Is there a bug for the changes being discussed here, and is it marked with dev-doc-needed? Sounds like there will be, at a minimum, a few tweaks to the discussion about how this stuff works. From the message at the start of the thread (six months ago): https://bugzilla.mozilla.org/show_bug.cgi?id=664104 -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
Intent to implement: Sub-resource Integrity (SRI)
Summary: Allow web authors to add integrity checks to sub-resources. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=992096 Spec: http://www.w3.org/TR/SRI/ Platforms: all Estimated or target release: Q1 of 2015 Preference behind which this will be implemented: security.subResourceIntegrity.enable Background: The best way to explain this is through an example. If you have the following: script src=https://code.jquery.com/jquery-1.10.2.min.js; integrity=ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=application/javascript then the browser will refuse to execute the script if someone has gained access to the jQuery servers and has replaced the script with a malicious one (the hash won't match the expected one). Our initial implementation will be limited to integrity checks for script tags and stylesheets. While the spec is still evolving, we expect to cover everything that ends up in level 1 of the spec. Feel free to contact me if you have any questions. Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Sub-resource Integrity (SRI)
LGTM, what's the status wrt other browsers supporting this? Thanks, Johnny On Tue, Dec 30, 2014 at 9:40 PM, Francois Marier franc...@mozilla.com wrote: Summary: Allow web authors to add integrity checks to sub-resources. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=992096 Spec: http://www.w3.org/TR/SRI/ Platforms: all Estimated or target release: Q1 of 2015 Preference behind which this will be implemented: security.subResourceIntegrity.enable Background: The best way to explain this is through an example. If you have the following: script src=https://code.jquery.com/jquery-1.10.2.min.js; integrity=ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=application/javascript then the browser will refuse to execute the script if someone has gained access to the jQuery servers and has replaced the script with a malicious one (the hash won't match the expected one). Our initial implementation will be limited to integrity checks for script tags and stylesheets. While the spec is still evolving, we expect to cover everything that ends up in level 1 of the spec. Feel free to contact me if you have any questions. Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- jst ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Sub-resource Integrity (SRI)
On Wednesday 2014-12-31 18:40 +1300, Francois Marier wrote: Summary: Allow web authors to add integrity checks to sub-resources. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=992096 Spec: http://www.w3.org/TR/SRI/ The TR draft of that spec looks a bit out-of-date. Will you be referring to the editor's draft, and tracking the progress in the working group, or be in touch with others who are? It looks like perhaps an early-ish draft. Does the working group believe it's stable enough to implement and ship? Or is the plan to implement and hold off on shipping until it's more stable? (And presumably you're also implementing http://tools.ietf.org/html/rfc6920 , but that looks more stable.) -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
