web-platform-tests now running in automation

The web-platform-tests testsuite has just landed on Mozilla-Central. It is an import of a testsuite collated by the W3C [1], which we intend to keep up-to-date with upstream. The tests are located in /testing/web-platform/tests/ and are now running in automation. Initially the testsuite, excluding

Re: web-platform-tests now running in automation

On 05/09/14 18:00, Boris Zbarsky wrote: > On 9/5/14, 11:55 AM, James Graham wrote: >> The web-platform-tests testsuite has just landed on >> Mozilla-Central. > > This is fantastic. Thank you! > > Does this obsolete our existing "imptests" tests, or is this

Re: web-platform-tests now running in automation

On 06/09/14 05:05, Boris Zbarsky wrote: > On 9/5/14, 11:55 AM, James Graham wrote: >> Instructions for performing the updates are in the README file >> [2]. There is tooling available to help in the update process. > > Is there a way to document the spec or test suite bugs

Re: web-platform-tests now running in automation

On 07/09/14 12:34, Aryeh Gregor wrote: > On Fri, Sep 5, 2014 at 8:23 PM, James Graham wrote: >> I think Ms2ger has a better answer here, but I believe it obsoletes most >> of them, except a few that never got submitted to web-platform-tests >> (the editing tests are in th

Re: web-platform-tests now running in automation

On 08/09/14 19:42, Ehsan Akhgari wrote: >> I think unreviewed tests should still be run by browsers' automated >> testing framework (obviously unless they take too long, are >> unreliable, etc.). They just shouldn't be counted toward any claims >> of conformance. Even if the expected values are e

Re: web-platform-tests now running in automation

On 10/09/14 19:32, Aryeh Gregor wrote: > On Tue, Sep 9, 2014 at 3:44 PM, James Graham wrote: >> Yes, I agree too. One option I had considered was making a suite >> "web-platform-tests-mozilla" for things that we can't push upstream e.g. >> because the API

Re: W3C Proposed Recommendation: HTML5

On 20/09/14 03:46, Boris Zbarsky wrote: > On 9/19/14, 8:23 PM, L. David Baron wrote: >> W3C recently published the following proposed recommendation (the >> stage before W3C's final stage, Recommendation): > > The biggest issue I have with this is exiting CR without anything > resembling a compreh

Re: W3C Proposed Recommendation: HTML5

On 22/09/14 12:43, Henri Sivonen wrote: > On Sun, Sep 21, 2014 at 4:00 PM, James Graham wrote: >> leaving the remaining participants to debate topics of >> little consequence. > > FWIW, this bit is being spun into Twitter propaganda about Mozilla not > caring about acces

Re: W3C Proposed Recommendation: HTML5

On 22/09/14 13:16, Robin Berjon wrote: > I can't say it has brought about a revolution yet, but it has certainly > helped change minds. It's hard to argue against a continuously updated > test suite. It's hard to imagine that such an animal wouldn't find spec > bugs in addition to implementation b

Re: W3C Proposed Recommendation: HTML5

On 21/09/14 22:19, Boris Zbarsky wrote: > On 9/21/14, 9:00 AM, James Graham wrote: > More interestingly, either the specification is implementable or not. > Again, because once the REC is published everyone goes home and never > touches that document again. > > The two impleme

Re: Intent to ship: resource timing

On 24/09/14 02:11, Valentin Gosu wrote: > == Test coverage == > dom/tests/mochitest/general/test_resource_timing.html > dom/tests/mochitest/general/test_resource_timing_cross_origin.html > > There is also the w3c test, which presents some failures for all UAs > because of bugs in the test. > http

Re: Intent to ship: resource timing

On 24/09/14 14:27, Valentin Gosu wrote: > On 24 September 2014 12:08, James Graham wrote: > >> On 24/09/14 02:11, Valentin Gosu wrote: >> >>> == Test coverage == >>> dom/tests/mochitest/general/test_resource_timing.html >>> dom/tests/mochitest/g

Re: Intent to implement: "image-rendering: pixelated" CSS property-value

On 25/09/14 05:23, Daniel Holbert wrote: > It depends on what you mean by "interoperable". If you're asking if > they'll produce the exact same result, pixel-for-pixel, when downscaling > an image, then no. But that's likely already the case, with the default > scaling behavior; I'd be surprised

Re: Documenting uses of Github at Mozilla

Some test-related things that we both use and contribute to/maintain: https://github.com/w3c/web-platform-tests https://github.com/w3c/wptserve https://github.com/w3c/wptrunner https://github.com/w3c/testharness.js ___ dev-platform mailing list dev-platf

Re: W3C Proposed Recommendation: HTML5

On 30/09/14 16:56, Patrick Walton wrote: > On 9/21/14 6:00 AM, James Graham wrote: >> In the longer term, one might hope that bugfixes will produce new >> testcases that could be upstreamed, and Servo might need a proper >> testsuite to achieve interoperability. Having sa

Re: PSA: Array.prototype.contains is going away again

On 02/10/14 09:06, Philip Chee wrote: > On 02/10/2014 00:52, Till Schneidereit wrote: >> Unfortunately, it turns out that Array.prototype.contains breaks the web. >> Or, the MooTools-using parts of the web, at least. So I'm preparing a >> backout right now. > > Can we not reach out to the MooTools

Re: Git -> Hg workflows?

On 30/10/14 22:48, Gregory Szorc wrote: > I'm trying to learn more about how the people who use Git for > Firefox/Gecko development manage interacting with repositories that have > their canonical home in Mercurial (mozilla-central, Try, etc). I'm doing > this to ensure the replacement Try architec

Re: elm changesets gone walkies?

On 24/12/14 11:19, Philip Chee wrote: > https://bugzilla.mozilla.org/show_bug.cgi?id=771238#c1 > >> http://hg.mozilla.org/projects/elm/rev/ab6d458a4258 > Not unexpectedly this doesn't exist any more. So I check mozilla-central > assuming that elm had been merged to m-c: >> https://hg.mozilla.org/m

Re: Intent to implement: Sub-resource Integrity (SRI)

On 01/01/15 01:38, Francois Marier wrote: > On 31/12/14 21:42, Ms2ger wrote: >> What's the testing story? Do we pass the web-platform tests >> ()? > > We do, except for one which relies on ambiguity in the spec and is > c

Re: Intent to Ship: Fetch API

On 18/02/15 17:06, nsm.nik...@gmail.com wrote: > Support in other engines: > Blink: supports Fetch in ServiceWorkers since 40, and intend to enable it on > Window in 42 or 43 - > https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/fetch$20api/blink-dev/qwRO52vsQlU/CPLC4G6oG9IJ W

Re: Intent to Ship: Fetch API

On 18/02/15 17:31, nsm.nik...@gmail.com wrote: > We have fairly comprehensive mochitests in dom/workers/tests/fetch > and dom/tests/mochitests/fetch. The blink intent to ship email, at > the bottom, has a section which documents Canary performing well on > our tests. In addition, we pass (except f

Re: What are your pain points when running unittests?

On 12/03/15 22:51, Jonathan Griffin wrote: > The A-Team is embarking on a project to improve the developer experience > when running unittests locally. This project will address the following > frequently-heard complaints: > > * Locally developers often use mach to run tests, but tests in CI use

Re: Some site performance analysis from Google

On 30/03/15 22:49, Robert O'Callahan wrote: > This is a quick read and an interesting analysis of how various sites fail > to achieve acceptable performance on mobile: > https://docs.google.com/document/d/1K-mKOqiUiSjgZTEscBLjtjd6E67oiK8H2ztOiq5tigk/pub There is also a view with some extra comment

Re: Some site performance analysis from Google

On 30/03/15 23:55, Karl Dubost wrote: > > Le 31 mars 2015 à 07:43, James Graham a écrit : >> There is also a view with some extra comments at [1] which are worth >> reading. >> >> [1] >> https://docs.google.com/document/d/1K-mKOqiUiSjgZTEscBLjtjd6E67oiK8H

Changes to web-platform-tests

This is just an update to make sure everyone is aware of recent improvements to the web-platform-tests, which should improve the UX for gecko hackers and make them suitable for more testing situations. == Summary == * Now possible to set per-test prefs so experimental features can be tested. * I

Re: Changes to web-platform-tests

> ./mach testing/web-platform/tests/dom/historical.html > > It is also possible to use the path of the test relative to the server i.e. > > ./mach dom/historical.html Sorry, you still need the command name i.e. ./mach web-platform-tests [whatever] It isn't quite that magical yet :) _

Re: Using rust in Gecko. rust-url compatibility

On 30/04/15 23:42, Jet Villegas wrote: I wonder why we'd allow *any* parsing differences here? Couldn't you just assert and fail hard while you're testing against our tests and in Nightly? I imagine the differences you don't catch this way will be so subtle that crowd-sourcing is unlikely to catc

Re: Using rust in Gecko. rust-url compatibility

On 01/05/15 18:39, Boris Zbarsky wrote: On 5/1/15 12:41 PM, Jet Villegas wrote: I think the plan was to improve security and dogfood rust. If we're also signing up to increase spec compliance as part of the rewrite, that should be called out as an explicit goal--with a plan for dealing with non-

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

On 06/05/15 18:08, Anne van Kesteren wrote: On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari wrote: * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concern _at all_ (since your malicious web site can easily

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

On 06/05/15 18:22, James Graham wrote: On 06/05/15 18:08, Anne van Kesteren wrote: On Wed, May 6, 2015 at 7:02 PM, Ehsan Akhgari wrote: * Restricting this API to resources loaded from a secure origin also doesn't help in any way in practice. It doesn't address your original concer

Re: PSA: The mochitest ise() function is dead, please use is() instead

On 14/05/15 00:35, Gregory Szorc wrote: I would steer people in the direction of Assert.jsm, specifically Assert.deepEqual, which uses ObjectUtils.jsm goodness for type aware comparisons so things like Date, RegExp, and Object comparisons have sane behavior. (deepEqual falls back to === for non-s

web-platform-tests on debug builds running on try

Web-platform-tests are now running in debug builds on try only. However due to some teething problems, they are not currently all green. This is expected to be fixed in the next 24 hours but, in the meantime, if you see some orange that seems unrelated to your change, particularly orange that l

Re: Collecting web platform features implementation status

On 17/07/15 04:21, Eric Shepherd wrote: Agreed. This is about how we feel about a spec, its content, and the design of its API, not about if or when we will get around to implementing it. That's also something worth capturing, but they're not the same data points at all. I think it's the exact

Re: Proposed W3C Charters: All Groups, XML Activity

On 21/07/15 11:29, Ms2ger wrote: This entire Activity is a distraction from the real needs of the web, and if the W3C is serious about its motto, it should focus on those rather than providing support and hosting conferences for people's petty side projects that have no bearing on the web. Howe

Re: Intent to Implement: Storage Access API

web-platform-tests: Our implementation unfortunately doesn’t come with web-platform-tests, for two reasons. One is that there is currently no way to mock user gestures in web platform tests [4], and the second reason is that furthermore, our implementation also depends on being able to manipulate

Re: Intent to Implement: Storage Access API

On 07/09/2018 21:27, Ehsan Akhgari wrote: Very cool, I did not know this!  It seems like test_driver.bless() is what we need here for simulating a user activation gesture. However it sounds like in this case you may need to add test-only APIs for manipulating internal browser state. Th

PSA: wpt MANIFEST.json has moved out of tree

Thanks to great work by Outreachy intern Ahilya Sinha (:Cactusmachete) [1], the in-tree wpt MANIFEST.json files are no longer used and will soon be removed. Invoking `mach wpt` will now cause a recent wpt manifest to be downloaded from Taskcluster into the objdir (if not already present) and

Re: PSA: wpt MANIFEST.json has moved out of tree

On 24/09/2018 14:01, Boris Zbarsky wrote: On 9/24/18 8:43 AM, James Graham wrote: Thanks to great work by Outreachy intern Ahilya Sinha (:Cactusmachete) [1], the in-tree wpt MANIFEST.json files are no longer used and will soon be removed. That's great news.  :) Invoking `mach wpt`

Re: PSA: wpt MANIFEST.json has moved out of tree

On 24/09/2018 13:43, James Graham wrote: If you notice regressions from this change, please file a bug in the Testing::web-platform-tests component and needinfo me. Due to bug 1493674 we were mistakenly looking for test metadata in the objdir rather than the source dir. If you notice that

Multi-browser web-platform-tests results dashboard

https://wpt.fyi is a dashboard containing the results of the full web-platform-tests suite in multiple versions of current browsers. The default view shows test results in the latest stable releases of desktop Firefox/Chrome/Edge/Safari. There are several alternative views that are likely to b

Re: Multi-browser web-platform-tests results dashboard

On 02/10/2018 21:27, Boris Zbarsky wrote: On 10/2/18 1:38 PM, James Graham wrote: Experimental (i.e. nightly/dev) builds of Firefox and Chrome are run on Linux using Taskcluster after each commit to web-platform-tests. Would a commit to Firefox that fixes some tests and just touches wpt .ini

Re: Multi-browser web-platform-tests results dashboard

On 03/10/2018 13:32, Boris Zbarsky wrote: On 10/3/18 5:21 AM, James Graham wrote: So the net effect of all this is that bug fixes won't appear on the dashboard until the first upstream wpt commit after they are present in a nightly release. Right. I assume for now the volume of commi

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

On 17/10/2018 01:23, Emilio Cobos Álvarez wrote: Hi Philip, Do you know how do reftests run in order to get that data? I'm particularly curious about this Firefox-only failure:   css/selectors/selection-image-001.html It passes both on our automation and locally. I'm curious because I was t

Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

On 17/10/2018 10:12, James Graham wrote: On 17/10/2018 01:23, Emilio Cobos Álvarez wrote: Hi Philip, Do you know how do reftests run in order to get that data? I'm particularly curious about this Firefox-only failure:    css/selectors/selection-image-001.html It passes both o

Re: Intent to implement: Support Referrer Policy for

On 31/10/2018 14:03, Thomas Nguyen wrote: Summary: This implementation adds Referrer Policy support to the

Re: Intent to implement: Support Referrer Policy for

On 01/11/2018 11:03, Thomas Nguyen wrote: The link https://searchfox.org/mozilla-central/search?q=script-tag%2Finsecure-protocol.keep-origin-redirect.http.html&path= is not covered all the tests. Thanks James for pointing it out. In fact, we have synced all script-tag tests which were added in h

Re: Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

On 11/11/2018 17:57, Emilio Cobos Álvarez wrote: web-platform-tests: Test coverage for all the values is pre-existing. There's unfortunately little coverage in WPT, but a lot in our selection and contenteditable tests. Can we upstream some of these tests to wpt? I don't know if there are/wer

Re: Workflow Apropos!

On 27/11/2018 17:46, Kim Moir wrote: Speeding up moz-phab moz-phab[2] is Engineering Workflow’s officially supported custom command-line interface to Phabricator, built in order to better support the “stacked commits” workflow that is common in Firefox engineering. Unfortunately some of the des

Re: Workflow Apropos!

On 28/11/2018 20:15, Mark Côté wrote: We're still working through a longer-term vision that we'll share early next year, but I can answer some questions now. Thanks, this is helpful! * Have to make a choice early on about whether to learn a relatively unfamiliar (to the majority of de

Re: Intent to ship: set keyCode or charCode of "keypress" event to the other's non-zero value

On 30/11/2018 01:37, Masayuki Nakano wrote: web-platform-tests: N/A due to requiring user input, but we have mochitests with synthesized events. I think it should be possible to write web-platform-tests for this kind of thing now, using the testdriver API and in particular the actions support

Re: Intent to ship: set keyCode or charCode of "keypress" event to the other's non-zero value

On 04/12/2018 02:23, Masayuki Nakano wrote: On 2018/11/30 20:42, James Graham wrote: On 30/11/2018 01:37, Masayuki Nakano wrote: web-platform-tests: N/A due to requiring user input, but we have mochitests with synthesized events. I think it should be possible to write web-platform-tests for

This year in web-platform-tests - 2018 edition

Welcome to the second annual update on progress in cross-browser interop testing through web-platform-tests. This year has seen big improvements to the platform coverage of wpt, as well as increasing the number of features that can be tested with wpt, and the visibility of test results in Gecko

Next Year in web-platform-tests - 2018/19 Edition

Following the summary of what we've achieved in the previous year in web-platform-tests, I'd like to set out the plan for priorities in the coming year, and solicit feedback. There are several key things that we would like to achieve over the course of the year: * Give the platform team and

Re: Intent to implement and ship: Overflow media queries

On 23/12/2018 10:59, Emilio Cobos Álvarez wrote: web-platform-tests: Minimal parsing tests are being added to:   https://wpt.fyi/results/css/mediaqueries/test_media_queries.html Unfortunately WPT has no way to test print preview or pagination right now so the rest of reftests are Gecko-only.

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

On 03/01/2019 16:17, jmaher wrote: What are the risks associated with this? 1) try server build times will increase as we will be testing on PGO instead of OPT 2) we could miss a regression that only shows up on OPT, but if we only ship PGO and once we leave central we do not build OPT, this is

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

On 03/01/2019 18:16, Steve Fink wrote: Good points, but given that most failures will show up debug builds, it seems like a more relevant metric is the difference between time(Opt) vs min(time(debug), time(PGO)). Though debug builds may run slow enough that it boils down to what you said? Lo

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

On 17/01/2019 16:42, jmaher wrote: Following up on this, thanks to Chris we have fast artifact builds for PGO, so the time to develop and use try server is in parity with current opt solutions for many cases (front end development, most bisection cases). Even as someone not making frequent ch

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

On 21/01/2019 10:18, Jan de Mooij wrote: On Fri, Jan 18, 2019 at 10:36 PM Joel Maher wrote: Are there any concerns with this latest proposal? This proposal sounds great to me. Thank you! +1. This seems like the right first step to me. ___ dev-pl

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

On 25/02/2019 19:44, Daosheng Mu wrote: web-platform-tests: none exist (and I don't plan to write WPTs but we do have gamepad mochitest, I will add new tests to cover these two new APIs.) Why do you plan to not write web-platform-tests? I imagine there may be technical challenges, but we s

Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`

On 26/02/2019 22:49, d...@mozilla.com wrote: On Tuesday, February 26, 2019 at 2:15:57 AM UTC-8, James Graham wrote: On 25/02/2019 19:44, Daosheng Mu wrote: web-platform-tests: none exist (and I don't plan to write WPTs but we do have gamepad mochitest, I will add new tests to cover

Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

On 08/03/2019 15:06, Boris Zbarsky wrote: On 3/7/19 7:31 PM, Ehsan Akhgari wrote: *web-platform-tests*: This is an intervention which different engines do not agree on yet.  Creating a web-platform-test for it would be very simple but it will be failing in the engines that do not agree with th

Re: Intent to ship: CSS Containment

On 18/03/2019 19:01, Daniel Holbert wrote: As of today (March 18th 2019), I intend to turn CSS Containment on by default on all platforms, in Firefox Nightly 68. It has been developed behind the 'layout.css.contain.enabled' preference. Apologies if I've m

Re: Creating a new mach command for adding tests

On 01/04/2019 23:13, Steve Fink wrote: On 4/1/19 11:36 AM, Brian Grinstead wrote: Based on my own experience and discussions with others, the workflow for adding new mochitests isn't great. Commonly, it looks like: "copy/paste a test in the same directory, add the new test to the relevant mani

Re: Creating a new mach command for adding tests

On 02/04/2019 19:11, Brian Grinstead wrote: I don't think that having papercuts in the workflow for writing one type of test is the right way to nudge developers into writing another type. It also doesn't seem effective - otherwise people would be using the wpt-create tool to avoid jumping thr

Re: Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

On 09/04/2019 10:31, Anne van Kesteren wrote: On Tue, Apr 9, 2019 at 5:56 AM Cameron McCormack wrote: On Tue, Apr 9, 2019, at 1:39 PM, Brian Grinstead wrote: I'd like to rewrite markup in the tree to avoid using the [type] attribute on

Re: Creating a new mach command for adding tests

On 11/04/2019 18:22, Brian Grinstead wrote: This has now landed (with initial support for xpcshell, mochitests, and web platform tests). Thanks to Andrew Halberstadt and James Graham for improving upon the initial prototype and making it easier to extend to new suites. Eager users should

PSA: web-platform-tests (dashboard | fuzzy-reftests | reftest comparisons)

There have been a few recent changes related to wpt that may be of interest to a wider audience; for brevity I'm coalescing them into a single email: * New wpt dashboard focused on interop problems * Support for fuzzy annotations in reftests * Better support for debugging failing reftests on wp

Re: PSA: web-platform-tests (dashboard | fuzzy-reftests | reftest comparisons)

On 16/04/2019 12:17, Anne van Kesteren wrote: On Mon, Apr 15, 2019 at 7:16 PM Jonathan Watt wrote: These are all really great. Thanks, James! Indeed, thanks a lot for working on this! This will help a lot with prioritizing work and also with standards development. Some feedback for the Inter

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

On 25/04/2019 17:12, Bobby Holley wrote: On Thu, Apr 25, 2019 at 3:36 AM Joel Maher wrote: On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley wrote: Thanks Mike! So Fennec is the last remaining non-e10s configuration we ship to users. Given that Fennec test coverage is somewhat incomplete,

Re: Intent to ship: Visual Viewport API on Android

On 10/05/2019 21:49, David Burns wrote: Not yet as we are stabilising tests for gecko view but hopefully soon! That won't automatically work; we'd need to start uploading Android results to wpt.fyi. Which is possible in one of two ways: * Add Geckoview on Android to the TC configuration fo

Support for annotating intermittent tests with multiple statuses

Thanks to the amazing work of Outreachy participant Nikki Sharpley, our test result logging infrastructure now supports marking tests as having multiple expected statuses. This can be used instead of disabling tests where the results are intermittent. Harness-level support is currently availabl

Re: Support for annotating intermittent tests with multiple statuses

On 25/07/2019 20:39, Andrew Halberstadt wrote: Excellent work Nikki! This will give us more tools to help with the war on orange. Are there plans (or at least bugs on file) to support other harnesses? I'll file some bugs. On Thu, Jul 25, 2019 at 2:47 PM James Graham <m

Re: PSA: Improvements to infrastructure underpinning `firefox-source-docs`

On 27/08/2019 16:24, Andrew Halberstadt wrote: RST is foreign to most It turns out* that firefox-source-docs also supports markdown format, so if you have existing docs in that format, or simply feel like needing to learn ReST is a significant impediment to writing docs, that option is availab

Re: Intent to ship: CSS subgrid

On 22/10/2019 00:07, L. David Baron wrote: On Monday 2019-10-21 16:01 -0500, Mike Taylor wrote: Hi David, On 10/21/19 7:22 AM, L. David Baron wrote: (That we haven't applied the policy that much because we've granted exceptions because other browsers have shipped the features reduces the effec

Re: Reminder: Planned Taskcluster migration this weekend (Nov 9)

On 04/11/2019 22:00, Chris Cooper wrote: tl;dr: Taskcluster, the platform supporting Firefox CI, will be moving to a new hosting environment during the tree closing window (TCW) this coming Saturday, Nov 9. Trees will be closed from 14:00 UTC to 23:00 UTC. CI services will be available as soo

Re: Intent to prototype: CSS property `text-underline-position`

On 03/12/2019 17:50, Jonathan Kew wrote: web-platform-tests: https://wpt.fyi/results/css/css-text-decor/parsing?label=master&q=text-underline-position That looks like it's just testing the property computation. Do we also have tests for the layout effect, or is that difficult to do in this c

This year in web-platform-tests - 2019 edition

Welcome to "This year in web-platform-tests"; possibly the lowest frequency regular project update at Mozilla. In a break from tradition the MoCo All Hands moving to January means that this is the first edition to come from a normal office and not a hotel corridor somewhere in North America. T

Re: Intent to Prototype: beforeinput event (disabled by default even in Nightly channel)

On 08/01/2020 09:54, Masayuki Nakano wrote: Summary: "beforeinput" event is useful for web apps which manage input data into ``, `` and/or `contenteditable`. This event is fired before our editor modifies value or DOM tree and some types are cancelable. Therefore, if some user inputs are not

Re: Visibility of disabled tests

On 07/01/2020 13:29, Johann Hofmann wrote: /For disabling tests, review from the test author, triage owner or a component peer is required. If they do not respond within 2? business days or if the frequency is higher than x, the test may be disabled without their consent, but the triage own

Re: Visibility of disabled tests

On 09/01/2020 10:46, David Burns wrote: I think a lot of the problem is not necessarily a technical issue, meaning I am not sure that tooling will solve the problem, but it is more of a social problem. To exapnd a little on this; we've had various attempts at making disabled tests more visibl

Re: Intent to implement: AVIF (AV1 Image Format) support

On 13/01/2020 21:48, Jon Bauman wrote: AVIF is an image format based on the AV1 video codec [1] from the Alliance for Open Media [2]. AV1 support shipped in release 55 [3] and is currently supported in Chrome, but not Safari. There is an open issue for AVIF support in Chrome [4]. Bug: https://bu

Re: Intent to Deploy: ThreadSanitizer

On 04/02/2020 09:41, Christian Holler wrote: One of the problems with deploying ThreadSanitizer in CI is that we have a fair amount of existing data races that orange pretty much every test we have. In order to solve this situation, we are currently working on the following strategy: 1.

Re: Intent to implement: CSS conic-gradient

On 16/02/2020 10:46, Tim Nguyen wrote: web-platform-tests: https://searchfox.org/mozilla-central/search?q=conic-gradient&case=false®exp=false&path=testing%2Fweb-platform That looks like some tests for the parsing, but afaict not much for rendering. Do we have a sense of how good the test cove

Re: Intent to prototype and ship: CSS comparison functions: min() / max() / clamp()

On 21/02/2020 01:42, Emilio Cobos Álvarez wrote: web-platform-tests: There's a variety of tests in: https://wpt.fyi/results/css/css-values?label=master&label=experimental&aligned&q=minmax%7Cclamp Do we have any sense of how good the test coverage is? Also, not having enabled causes some confu

Re: Testing Rust code in tree

On 11/05/2020 23:54, Mike Hommey wrote: On Mon, May 11, 2020 at 03:37:07PM -0700, Dave Townsend wrote: Do we have any standard way to test in-tree Rust code? Context: We're building a standalone binary in Rust that in the future will be distributed with Firefox and of course we want to test it.

Re: Intent to ship: ParentNode#replaceChildren

On 25/05/2020 16:45, Alex Vincent wrote: Effective 2020-05-27, I intend to land ParentNode.replaceChildren feature in mozilla-central, on by default. This has not been developed behind a preference, as both I and the reviewers believe this is a small change. Status in other browsers is unimplemen

Re: Intent to change default try selector from `syntax` to `auto` (ACTION NEEDED for try syntax users)

On 06/07/2020 17:50, Tom Ritter wrote: Thank you for continuing to keep try syntax working. I know I'm holding back progress by not spending the time to figure out how to convert `./mach try -b do -p win32-mingwclang,win64-mingwclang -u all -t none` to fuzzy (maybe it's something like `./mach tr

Print reftest support in wpt

It is now* possible to write reftests for print layout in wpt. These work like normal reftests except instead of comparing the rendering of two documents in a browser window, they compare all the pages of a paginated rendering of the documents. wpt print reftests go through the full printing m

Re: Searchfox now gives info about tests at the top of test files!

This is awesome! On 28/07/2020 18:40, Andrew Sutherland wrote: - How long your tests take to run (on average)! - How many times your tests were run in the preceding 7 days[1]! - How many times your tests were skipped in the preceding 7 days! - What skip-patterns govern the skips from your test's

Re: Intent to ship in Nightly channel and early Beta: `beforeinput` event and `InputEvent.getTargetRanges()`

On 17/09/2020 17:14, Masayuki Nakano wrote: web-platform-tests: none for `beforeinput` (because of it requires user input, and test driver was not when other browsers implement it), but there are a lot of tests for `getTargetRanges()` which I added (200+). https://searchfox.org/mozilla-central/

[action maybe required] Verify recent wpt changes are still on autoland

A bug in the wptsync when switching over to Python 3 caused it to drop some upstream changes when doing recent landings. In order to get things back on track I've made a patch which copies over the files from the current sync revision from GitHub to m-c and reapples changes made to mozilla-cent

Re: Adopting the black Python code style

On 19/10/2020 22:01, Jeff Gilbert wrote: I'm disappointed by that. FWIW last time I looked at black, I found that the compromises it made to be fully automatic and with minimal configuration meant that it was liable to produce ugly or difficult to read code in some situations. I understand

Writing web-platform-tests using non-web-exposed APIs is now easier

Two changes that recently landed in web-platform-tests make it easier to write tests that require access to non-web-exposed features: * testdriver APIs now work in many situations involving multiple browsing contexts origins * SpecialPowers is now available in gecko-only web-platform-tests t

Re: Writing web-platform-tests using non-web-exposed APIs is now easier

On 26/10/2020 14:11, Mirko Brodesser wrote: Supporting synthesizing drag-and-drop events [1] That seems like the kind of thing that ought to be covered by testdriver. Would something like new test_driver.Actions() .pointerMove(0,0,{origin:elem1}) .pointerDown() .pointerMove(0,0,{origin

Re: Status of Ubuntu 20.04 as a development platform

On 10/11/2020 14:17, Kyle Huey wrote: On Tue, Nov 10, 2020 at 3:48 AM Henri Sivonen wrote: Does Ubuntu 20.04 work properly as a platform for Firefox development? That is, does rr work with the provided kernel and do our tools work with the provided Python versions? rr works. I use 20.04 pers

Re: HTTP/3 ready for testing

On 20/11/2020 16:09, Dragana Damjanovic wrote: Our implementation is ready for testing. What's the interop testing story for HTTP/3? How confident are we that we won't run into implementation differences that look like web-compat issues? Also, what's the priority on enabling other test typ

web-platform-tests now runs under Python 3

With bug 1678663 [1] now on central, web-platform-tests uses Python 3, both locally under mach, and on Gecko CI. This matches upstream, where the CI switched over a few weeks ago [2] and Google's CI which switched at the end of last week. For most users this change should be entirely transpare

Re: web-platform-tests now runs under Python 3

On 15/12/2020 20:00, James Graham wrote: With bug 1678663 [1] now on central, web-platform-tests uses Python 3, both locally under mach, and on Gecko CI. This matches upstream, where the CI switched over a few weeks ago [2] and Google's CI which switched at the end of last week. Appar

This year in web-platform-tests - 2020 Edition

It's been a long year hasn't it? Maybe the next one will seem shorter. Although, at home in London today, it feels that if it does, it will only be for want of a leap day. Given all that's passed since 2019, you would be forgiven for having entirely forgotten about "This Year in Web-Platform-Test

Intent to ship: remote-protocol (CDP)

Summary: remote-protocol provides a Firefox implementation of a subset of the Chrome DevTools Protocol (CDP) [1], specifically targeted at testing and automation use cases. remote-protocol isn't a web-exposed feature so it doesn't fit into the standard exposure guidelines. However we're mentio

<    1   2   3   >