Re: Moving Windows MSVC Builds Back To Tier 1
As was noted in the bug, deciding to explicitly un-support MSVC is a decision which merits wider discussion and is not something I wanted to tackle in that bug. -Ryan On 10/12/2018 4:08 PM, Dave Townsend wrote: If we've made the decision to stick with clang-cl, why would we continue to support MSVC builds going forwards? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moving Windows MSVC Builds Back To Tier 1
If we've made the decision to stick with clang-cl, why would we continue to support MSVC builds going forwards? On Fri, Oct 12, 2018 at 1:06 PM Ryan VanderMeulen wrote: > When we made the decision to switch to clang-cl for our Windows builds, > MSVC builds and tests were kept running as Tier 2 jobs in CI to ensure that > they continued working in the event of an emergency switch-back caused by > any last-minute clang-cl compatibility issues. Thankfully, no such issues > have arisen and we are on track to ship clang-cl builds with the release of > Firefox 63 on October 23rd. > > However, these Tier 2 MSVC builds have been an ongoing source of confusion > for developers since they don't run across all trees all the time and have > been known to break on a fairly regular basis as a result. Also, treating > MSVC as supported but Tier 2 is inconsistent with how we've handled other > compilers, such as GCC, which are still considered Tier 1 in our > infrastructure. > > As a result, to avoid confusion and to have a more consistent policy, I've > landed by way of bug 1496059 some changes to how MSVC builds are treated: > * They're now Tier 1 builds, meaning they run across *all* supported > branches on every push and breakage will lead to immediate backout. They > are of course also available for Try pushes as needed. > * Tests no longer run on these builds. This is in line with GCC builds and > was deemed acceptable now that we're past the point of considering > reverting back to MSVC from clang-cl in the builds we ship. > > Thanks, > Ryan > ___ > 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
Moving Windows MSVC Builds Back To Tier 1
When we made the decision to switch to clang-cl for our Windows builds, MSVC builds and tests were kept running as Tier 2 jobs in CI to ensure that they continued working in the event of an emergency switch-back caused by any last-minute clang-cl compatibility issues. Thankfully, no such issues have arisen and we are on track to ship clang-cl builds with the release of Firefox 63 on October 23rd. However, these Tier 2 MSVC builds have been an ongoing source of confusion for developers since they don't run across all trees all the time and have been known to break on a fairly regular basis as a result. Also, treating MSVC as supported but Tier 2 is inconsistent with how we've handled other compilers, such as GCC, which are still considered Tier 1 in our infrastructure. As a result, to avoid confusion and to have a more consistent policy, I've landed by way of bug 1496059 some changes to how MSVC builds are treated: * They're now Tier 1 builds, meaning they run across *all* supported branches on every push and breakage will lead to immediate backout. They are of course also available for Try pushes as needed. * Tests no longer run on these builds. This is in line with GCC builds and was deemed acceptable now that we're past the point of considering reverting back to MSVC from clang-cl in the builds we ship. Thanks, Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: HTMLMarqueeElement
On 10/12/18 1:56 PM, Brian Grinstead wrote: Summary: Motion is a key component of modern web design, and is the premier... Fire. The premier fire so we can have fire and motion [1]. Or maybe it's just a dumpster fire? ;) The proposed change looks great to me. -Boris [1] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: HTMLMarqueeElement
Summary: Motion is a key component of modern web design, and is the premier... just kidding. Gecko currently ships as an HTMLDivElement with the web-exposed properties attached via in-content XBL [0][1]. As part of the process of removing in-content XBL, I intend to implement and ship HTMLMarqueeElement. This will allow us to expose properties on the element through WebIDL instead of through ``. This will lead to behavior changes with the current implementation (https://bugzilla.mozilla.org/show_bug.cgi?id=1425874#c10), although those changes will generally bring Firefox into compliance with the spec and with other implementations - many currently failing web platform tests should start passing [2][3]. The event handlers (onbounce, onfinish, onstart) will still be implemented in XBL for the time being - the actual XBL removal will happen in subsequent bugs. There's an open question about how to treat the `loop` property. As outlined at https://bugzilla.mozilla.org/show_bug.cgi?id=1425874#c14, the spec defines a no-op when setting `loop` to a number that is <= 0 and not -1, which is similar to what our current implementation does. In this case Chrome, Safari, and Edge throw, so we may want to adapt this behavior. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1425874 Link to standard: https://html.spec.whatwg.org/multipage/obsolete.html#the-marquee-element Platform coverage: All Target Release: 65 Preference behind which this will be implemented: None Is this feature enabled by default in sandboxed iframes? Yes DevTools bug: None Do other browser engines implement this? - Chrome: since version 1 - Edge: yes - IE: since version 2 - Safari: since version 1.2 web-platform-tests: https://github.com/web-platform-tests/wpt/tree/master/html/obsolete/requirements-for-implementations/the-marquee-element-0 Is this feature restricted to secure contexts? No Brian [0]: https://searchfox.org/mozilla-central/source/dom/html/HTMLDivElement.cpp [1]: https://searchfox.org/mozilla-central/search?q=xbl-marquee.xml= [2]: https://searchfox.org/mozilla-central/rev/28fe656de6a022d1fc01bbd3811023fca99cf223/testing/web-platform/meta/html/dom/interfaces.https.html.ini#628-746 [3]: https://searchfox.org/mozilla-central/rev/1ce4e8a5601da8e744ca6eda69e782318afab54d/testing/web-platform/meta/html/dom/reflection-obsolete.html.ini#8-2829 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: WebP image support
On 11/10/2018 6:03 PM, Tom Ritter wrote: Are we bringing in a new third party library for this? (Seems like yes?) Who else uses it/audits it? Does anyone else fuzz it? Is it in OSS-fuzz? Are we fuzzing it? How does upstream behave? Do they cut releases or do they just have continual development and downstreams grab random versions of it? How do we plan to track security issues upstream? How do we plan to update it (mechanically and how often)? -tom We have been discussing implementation details such that webp would be using the media decoder framework to demux and decode the images. As such, webp support would automatically gain sandbox control (going through the same out of process decoding codepath like we will do with AV1). Doing it that way would also greatly help adding support for images like AVIF or even using videos (mp4, webm) inside an object. Though there seems to be an urgency in shipping it now, meaning that the implementation details I describe above won't likely be in the first release. JY ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: WebP image support
On Thu, Oct 11, 2018 at 5:43 PM Andrew Osmond wrote: > Is this feature restricted to secure contexts?: No, it isn't. This is not a > new API, instead it is just accepting more types of content via existing > channels. This isn't the rationale you're looking for. New formats would generally be expected to be restricted. New formats already shipped by other browsers and likely in use on insecure contexts however probably deserve an exception. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
