Re: Proposed policy change: reusability of tests by other browsers

. I believe WebKit doesn't run them automatically yet. James Graham of Opera has indicated that they'd probably be interested in running our tests. (Opera gets much less user testing than we do, so they're very interested in automated testing.) Yes, we are interested in running your tests and very

Re: Proposed policy change: reusability of tests by other browsers

On 11/07/2012 02:03 PM, Henri Sivonen wrote: On Wed, Oct 10, 2012 at 10:46 AM, Aryeh Gregor a...@aryeh.name wrote: That said, of course, Mozilla hackers *are* familiar with Mochitest but not testharness.js, and adopting testharness.js in parallel with Mochitest would require people to be

Re: What platform features can we kill?

On 10/10/13 15:28, Axel Hecht wrote: On 10/10/13 2:43 PM, Jeff Walden wrote: On 10/10/2013 02:27 PM, Axel Hecht wrote: I agree with the sentiment, but not on the eample. Having been a peer of the XSLT module back in the days, we started with a rather js DOM like implementation, and moved over

Re: Pushes to Backouts on Mozilla Inbound

On 05/11/13 14:57, Kyle Huey wrote: On Tue, Nov 5, 2013 at 10:44 PM, David Burns dbu...@mozilla.com wrote: We appear to be doing 1 backout for every 15 pushes on a rough average[4]. This number I am sure you can all agree is far too high especially if we think about the figures that John

Re: Pushes to Backouts on Mozilla Inbound

On 06/11/13 15:49, Ryan VanderMeulen wrote: On 11/6/2013 6:58 AM, Aryeh Gregor wrote: Has anyone considered allowing try pushes to run only specified directories of tests, and to allow incremental builds rather than clobbers on try? This would make try a heck of lot faster and

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

Re: Spring cleaning: Reducing Number Footprint of HG Repos

On 27/03/14 14:17, Armen Zambrano G. wrote: On 14-03-26 08:27 PM, Bobby Holley wrote: I don't understand what the overhead is. We don't run CI on user repos. It's effectively just ssh:// + disk space, right? That seems totally negligible. FTR from an operations standpoint, it is never just.

Re: Policy for disabling tests which run on TBPL

On 07/04/14 04:33, Andrew Halberstadt wrote: On 06/04/14 08:59 AM, Aryeh Gregor wrote: On Sat, Apr 5, 2014 at 12:00 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Note that is only accurate to a certain point. There are other things which we can do to guesswork our way out of the situation

Re: Policy for disabling tests which run on TBPL

On 08/04/14 14:43, Andrew Halberstadt wrote: On 07/04/14 11:49 AM, Aryeh Gregor wrote: On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek t...@mielczarek.org wrote: If a bug is causing a test to fail intermittently, then that test loses value. It still has some value in that it can catch

Re: Policy for disabling tests which run on TBPL

On 08/04/14 15:06, Ehsan Akhgari wrote: On 2014-04-08, 9:51 AM, James Graham wrote: On 08/04/14 14:43, Andrew Halberstadt wrote: On 07/04/14 11:49 AM, Aryeh Gregor wrote: On Mon, Apr 7, 2014 at 6:12 PM, Ted Mielczarek t...@mielczarek.org wrote: If a bug is causing a test to fail

Re: Standardized assertion methods

On 03/06/14 00:24, Chris Peterson wrote: On 6/2/14, 3:42 PM, Ehsan Akhgari wrote: 2. I also value consistency more than my personal preferences, and based on that, using the existing APIs in some tests and the new APIs in other tests (even if we agreed that #1 above doesn't matter) is strictly

Re: Standardized assertion methods

I'm not sure I grasp your overall point, but I have a few comments. On 03/06/14 11:22, Mike de Boer wrote: 1. The `Assert.*` namespace is optional and may be omitted. This module is also present in the addon-sdk and used _with_ that namespace, usually with a lowercase `assert.*`. Please pick

Re: Standardized assertion methods

On 03/06/14 12:27, Mike de Boer wrote: 4. None of the test-suites promote modularity and needlessly dictate a reporting style. What I mean by this is that there’s no way to hook different reporting styles in a test runner to promote TDD, for example. What does automation use to detect test

Re: Standardized assertion methods

On 03/06/14 22:28, Jonas Sicking wrote: testharness.js still requires lots of boiler plate. Especially when writing async tests. And especially if you try to follow the rule that each test within a file should clean up after itself. At this point testharness.js has taken several steps to

Re: Standardized assertion methods

On 04/06/14 18:42, Mike de Boer wrote: On 04 Jun 2014, at 19:20, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-06-04, 5:45 AM, Mike de Boer wrote: On 04 Jun 2014, at 00:33, James Graham ja...@hoppipolla.co.uk wrote: On 03/06/14 20:34, Boris Zbarsky wrote: I'm arguing against

Re: Standardized assertion methods

On 05/06/14 10:38, Mike de Boer wrote: As I tried to explain, the CommonJS API naively made sense to me at the time. To others as well, because we’re happily using it. As I now understand, some of us are very attached to a specific, different, API. FWIW I don't think that I am attached to a

Re: Standardized assertion methods

On 06/06/14 11:41, Gijs Kruitbosch wrote: On 06/06/2014 10:29, James Graham wrote: On 05/06/14 10:38, Mike de Boer wrote: As I tried to explain, the CommonJS API naively made sense to me at the time. To others as well, because we’re happily using it. As I now understand, some of us are very

Re: Running mochitests from a copy of the objdir?

On 20/08/14 18:38, Joshua Cranmer  wrote: On 8/20/2014 12:22 PM, L. David Baron wrote: (I estimated that it was going to be faster to get that working than to try to figure out how to use the packaged tests, since it was possible to reverse-engineer from mochitest run inside mach, though if

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,

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 a set of tests disjoint from those? I think

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 in the expectations file

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 ja...@hoppipolla.co.uk 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 that class

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 entirely

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 ja...@hoppipolla.co.uk 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 APIs aren't (yet) undergoing

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 comprehensive

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

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 implementations condition

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.

Re: Intent to ship: resource timing

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

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 if

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

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 said that, Servo has so far

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 people

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

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:

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 (https://github.com/w3c/web-platform-tests/tree/master/subresource-integrity)? We do, except for one which relies on ambiguity in the spec and is currently

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

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 comments

Re: Some site performance analysis from Google

On 30/03/15 23:55, Karl Dubost wrote: Le 31 mars 2015 à 07:43, James Graham ja...@hoppipolla.co.uk 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-mKOqiUiSjgZTEscBLjtjd6E67oiK8H2ztOiq5tigk/view

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. *

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 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

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 ehsan.akhg...@gmail.com 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

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 ehsan.akhg...@gmail.com 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

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

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

Re: Allowing web apps to delay layout/rendering on startup

On 03/08/15 16:46, Bobby Holley wrote: On Mon, Aug 3, 2015 at 12:37 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 3, 2015 at 12:32 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 3, 2015 at 9:23 AM, Jonas Sicking jo...@sicking.cc wrote: I think something like a meta

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.

Re: Intent to ship: referrerpolicy attribute

On 02/12/15 11:16, Franziskus Kiefer wrote: There are web-platform-tests [1], though they're not up to date with the spec. In particular, they still use |referrer| as attribute name instead of |referrerpolicy|. The idl name is referrerPolicy, is that the capitalisation issue you mean? So there

Re: wptview [Re: e10s]

On 09/01/16 15:43, Benjamin Smedberg wrote: On 1/8/2016 6:02 PM, James Graham wrote: On 08/01/16 22:41, Robert O'Callahan wrote: On Sat, Jan 9, 2016 at 10:27 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote: What are the implications of this? The web-platform tests are pass/fail,

Re: wptview [Re: e10s]

On 08/01/16 22:41, Robert O'Callahan wrote: On Sat, Jan 9, 2016 at 10:27 AM, Benjamin Smedberg wrote: What are the implications of this? The web-platform tests are pass/fail, right? So is it a bug if they pass but have different behaviors in e10s and non-e10s mode?

Re: unowned orange by team

On 23/12/15 01:15, Ben Kelly wrote: Hi all, In an attempt to wrangle some of the orange plaguing the tree I've tried to triage the top unowned bugs by team. ateam/releng: […] 10) https://bugzilla.mozilla.org/show_bug.cgi?id=1231798 This is a web-platform-tests test which is an interesting

Re: Too many oranges!

On 22/12/15 17:22, Andrew Halberstadt wrote: FWIW a summary of top orangefactor[1] oranges are posted regularly to dev.tree-alerts. Configuring it to also post to dev.platform is certainly possible if that's what people want. Though I have a feeling that people will mostly ignore these emails

Re: To bump mochitest's timeout from 45 seconds to 90 seconds

On 09/02/16 19:51, Marco Bonardo wrote: On Tue, Feb 9, 2016 at 6:54 PM, Ryan VanderMeulen wrote: I'd have a much easier time accepting that argument if my experience didn't tell me that nearly every single "Test took longer than expected" or "Test timed out" intermittent

Re: e10s

On 09/01/16 22:29, James Graham wrote: At this point I don't see any real advantages to trying to move to manifestparser for all web-platform-tests and many drawbacks, so I don't think it will happen. I am also not convinced that it's very relevant to the problem at hand; I don't see how

Re: Triage Plan for Firefox Components

On 01/04/16 01:02, Emma Humphries wrote: I've responded to a similar comment in the google doc, but I'll repeat it here. Priority sounds like a great choice, but given that everyone's using the Priority field their own way, there's enough heterogeneity in how it's used to make it difficult. I

Re: Why is Mozreview hassling me about squashed commits?

On 02/04/16 21:59, Gregory Szorc wrote: When you say "I almost never want to review individual commits and instead want to review the changeset as a single diff," I'm confused because a commit is a changeset (in Mercurial terms at least) and this statement is contradictory. You seem to be saying

Re: PSA: Cancel your old Try pushes

On 15/04/16 16:47, Ryan VanderMeulen wrote: I'm sure most of you have experienced the pain of long backlogs on Try (Windows in particular). While we'd all love to have larger pools of test machines (and our Ops people are actively working on improving that!), one often-overlooked thing people

Autoclassification of intermittent failures live on treeherder

Autoclassification of (a subset of) intermittent failures is now running on treeherder. You may have spotted that some jobs are now annotated with a hollow star symbol; this means that the autoclassifier matched all the error lines in that job with previously observed intermittents. The star

Re: Please use "web-platform-tests --manifest-update" for updating wpt tests

On 20/04/16 13:53, Josh Matthews wrote: Servo has a script [1] that runs on the build machine that executes --manifest-update and checks whether the contents of MANFEST.json is different before and after. We could do the same for Gecko and make it turn the job orange on treeherder. I plan to

Re: Please use "web-platform-tests --manifest-update" for updating wpt tests

On 20/04/16 14:13, Nathan Froyd wrote: On Wed, Apr 20, 2016 at 8:59 AM, James Graham <ja...@hoppipolla.co.uk> wrote: On 20/04/16 13:53, Josh Matthews wrote: Servo has a script [1] that runs on the build machine that executes --manifest-update and checks whether the contents of MANFES

Re: Intent to implement: CSS Houdini - Properties & Values API Level 1

On 25/07/16 16:48, Daniel Holbert wrote: On 07/25/2016 07:11 AM, Ms2ger wrote: Hey Jonathan, [...] Do we know how other vendors feel about this? Sentiment seems to be positive. Browser vendors are collaborating on developing the Houdini specs, and I haven't heard any serious reservations

Re: KeyboardEvent question for docs update

On 12/07/16 05:41, smaug wrote: On 07/12/2016 07:24 AM, Eric Shepherd wrote: I can continue to provide the per-OS information (I'd kind of like to -- but I have to consider the time involved), but if it's only marginally helpful, it may not be worth the maintenance cost, so I'd like to see if

Re: Visual Studio Code recommended extensions

On 23/02/17 16:48, Marco Bonardo wrote: // Rust language support. "saviorisdead.RustyCode" I haven't used either (or VS Code much), but my understanding is that is no longer maintained and you should prefer https://github.com/editor-rs/vscode-rust.

Re: Is there somewhere to get a report of new test failures from a web-platform-tests sync?

On 11/02/17 03:40, Brian Birtles wrote: Yes, I saw that and was very impressed! That's super useful. For Chrome, however, it would be even more useful if we could run those tests with --enable-experimental-web-platform-features. A lot of the Web Animations features we're testing are implemented

Re: Is there somewhere to get a report of new test failures from a web-platform-tests sync?

On 10/02/17 06:34, Brian Birtles wrote: I don't expect James to file bugs for all the new failures he encounters when syncing (and I suspect if he did, many of them would end up being marked invalid/duplicate because they're features we don't implement yet), but is there somewhere we can get a

Re: Do we need to run web-platform-tests --manifest-update when touching existing tests?

On 10/02/17 06:27, Brian Birtles wrote: Hi, It seems like the MANIFEST.json for web platform tests now includes a checksum of test file contents. As a result, if you run './mach web-platform-tests --manifest-update yer' on a clean checkout of m-c you're likely to get a bunch of changes to

Re: Reorganization of Firefox-UI tests in mozilla-central

On 02/09/16 10:37, Gijs Kruitbosch wrote: On 02/09/2016 08:08, Henrik Skupin wrote: The problematic piece here will be the package-tests step which currently picks complete subfolders. It would mean if we mix-up tests for firefox-ui-tests and eg. mochitests all would end-up twice in the

Re: A reminder about commit messages: they should be useful

On 17/04/17 16:41, David Major wrote: I'd like to add to this a reminder that commit messages should describe the _change_ and not the _symptom_. In other words, "Bug XYZ: Crash at Foo::Bar" is not a good summary. An unfortunate pattern I see is non-descriptive commit messages for tests,

Re: Project Stockwell (reducing intermittents) - March 2017 update

On 09/03/17 19:53, Milan Sreckovic wrote: Not a reply to this message, just continuing the thread. I'd like to see us run all the intermittently disabled tests once a ... week, say, or at some non-zero frequency, and automatically re-enable the tests that magically get better. I have a feeling

Re: Is there a way to improve partial compilation times?

On 08/03/17 14:21, Ehsan Akhgari wrote: On 2017-03-07 2:49 PM, Eric Rahm wrote: I often wonder if unified builds are making things slower for folks who use ccache (I assume one file changing would mean a rebuild for the entire unified chunk), I'm not sure if there's a solution to that but it

Planned tree closure Tue 2017-03-14 08:30 UTC

We will be running a migration on the Treeherder database which will require pausing job ingestion at 08:30 UTC tomorrow (Tuesday). This is expected to take around 90 minutes, and trees will be closed for the duration. Thank you for your patience.

Re: The future of commit access policy for core Firefox

On 13/03/17 14:45, Byron Jones wrote: David Burns wrote: We should try mitigate the security problem and fix our nit problem instead of bashing that we can't handle re-reviews because of nits. one way tooling could help here is to allow the reviewer to make minor changes to the patch before it

Re: Is there a way to improve partial compilation times?

On 08/03/17 11:11, Frederik Braun wrote: On 08.03.2017 01:17, Ralph Giles wrote: I second Jeff's point about building with icecream[1]. If you work in an office with a build farm, or near a fast desktop machine you can pass jobs to, this makes laptop builds much more tolerable. What do you

Re: Please do NOT hand-edit web platform test MANIFEST.json files

On 20/03/17 22:15, gsquel...@mozilla.com wrote: Sorry if it's a silly suggestion: Could the current tool insert some helpful reminders *everywhere* in the generated file (so it's can't be missed)? E.g., every 2nd line would read: "// PSA: This file is auto-generated by ./mach

Re: reducing high try macosx pending counts

On 02/08/17 22:30, Kim Moir wrote: You may have noticed that the time to wait for macosx test results on try has been very long (>1day) this week. We have taken the following steps to address this problem [...] That sounds great! Thanks. For everyone else: It looks like the queues are still

Re: disabled non-e10s tests on trunk

On 15/08/17 21:39, Ben Kelly wrote: On Tue, Aug 15, 2017 at 4:37 PM, Joel Maher wrote: All of the above mentioned tests are not run on Android (well mochitest-media is to some degree). Is 4 months unreasonable to fix the related tests that do not run in e10s? Is there

Re: disabled non-e10s tests on trunk

On 16/08/17 01:26, Nils Ohlmeier wrote: I guess not a lot of people are aware of it, but for WebRTC we still have two distinct implementations for the networking code. So if I understand the impact here right we just lost test coverage for probably a couple of thousand lines of code. […]

wpt CSS tests now running on Linux

Bug 1341078 and dependencies just landed on inbound, which means we now have the W3C/web-platform-tests CSS tests in-tree and running in automation. This adds about 12,000 reftests for CSS features to the web-platform-tests suite. They are currently enabled in CI, but only on linux*, due to

Re: wpt CSS tests now running on Linux

On 20/07/17 18:26, Emilio Cobos Álvarez wrote: Thanks for this James! \o/ One question, do we run the CSS test linter on automation, or are there any plans for it? Yes, that should be run as part of the W lint job (e.g. [1]), which is run on pushes (including to try) that change files under

Re: disabled non-e10s tests on trunk

On 16/08/17 19:36, Ben Kelly wrote: My only thought about windows7-debug is that android is a variant of linux. Running a linux platform might be closer to android behavior. But I don't have a known specific difference in mind. Right it seems like there are two use cases here: 1) Tests that

|mach wpt| now allows running tests in other browsers

Bug 1367041 recently landed on mozilla-central which should make it easier to run web-platform-tests from Mozilla source in (some) other browsers. |mach wpt| now accepts an argument --product that specifies the browser to run the tests in. This accepts values of servo, chrome, and edge in

Re: Shipping Headless Firefox on Linux

On 15/06/17 21:51, Ben Kelly wrote: On Thu, Jun 15, 2017 at 4:37 PM, Nathan Froyd wrote: On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl wrote: Headless will run less of the platform specific widget code and I don't recommend using it for platform

Re: Reminder on Try usage and infrastructure resources

On 15/09/17 00:53, Dustin Mitchell wrote: 2017-09-14 18:32 GMT-04:00 Botond Ballo : I think "-p all" is still useful for "T pushes" (and it sounds like build jobs aren't the main concern resource-wise). Correct -- all builds are in AWS. I'd like to steer this away from

Re: Reminder on Try usage and infrastructure resources

On 14/09/17 16:48, Marco Bonardo wrote: When I need to retrigger a mochitest-browser test multiple times (to investigate an intermittent), often I end up running all the mochitest-browser tests, looking at every log until I find the chunk where the test is, and retrigger just that chunk. The

Re: Reminder on Try usage and infrastructure resources

On 15/09/17 18:45, Dan Mosedale wrote: I wonder if this isn't (in large part) a design problem disguised as a behavior problem. The existing try syntax (even with try chooser) is so finicky and filled with abbreviations that even after years of working with it, I still regularly have to look up

Re: Intent to require `mach try` for submitting to Try

On 18/09/17 09:27, Samael Wang wrote: In a rare case that we need to send a "CLOSED TREE" try job, will we be able to do that with ./mach try? Last time I didn't use mach try to submit try job was because of that. That doesn't work right now, but it should be easy to add a --closed-tree flag

Re: Intent to require `mach try` for submitting to Try

On 18/09/17 04:05, Eric Rescorla wrote: But that's just a general observation; if you look at this specific case, it might not be much effort to support native git for richer/future try pushing. But that's very different from requiring all the tools to support native git on an equal basis. And

Re: Intermittent oranges and when to disable the related test case - a simplified policy

On 12/09/17 14:55, Andrew Halberstadt wrote: On Mon, Sep 11, 2017 at 10:33 PM Robert O'Callahan wrote: On Tue, Sep 12, 2017 at 11:38 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: I don't think so, that data already exists and is query-able from ActiveData:

Re: Implementing a Chrome DevTools Protocol server in Firefox

On 31/08/17 02:14, Michael Smith wrote: On 8/30/2017 15:56, David Burns wrote: > Do we know if the other vendors would see value in having this spec'ed properly so that we have true interop here? Reverse engineering seems like a "fun" project but what stops people from breaking stuff without

Testing & "Intent to Ship"

Looking back over recent "Intent to Ship" emails for web platform exposed features, I notice that only half make any mention of accompanying tests. Since cross-browser tests are one of the main ways we prevent today's exciting new feature being tomorrow's site-breaking compat nightmare, I'd

Re: Implementing a Chrome DevTools Protocol server in Firefox

On 31/08/17 19:42, Jim Blandy wrote: Some possibly missing context: Mozilla Devtools wants to see this implemented for our own use. After much discussion last summer in London, the Firefox Devtools team decided to adopt the Chrome Debugging Protocol for the console and the JavaScript debugger.

Re: Implementing a Chrome DevTools Protocol server in Firefox

On 31/08/17 21:22, Jack Moffitt wrote: Is there another alternative besides CDP you'd like to propose? I don't have an alternate proposal, and I feel like I must have been unclear at some point. I'm not saying "this is bad, period". I'm certainly not saying "this is bad because it isn't

Re: Implementing a Chrome DevTools Protocol server in Firefox

On 04/09/17 23:34, Jim Blandy wrote: On Mon, Sep 4, 2017 at 7:36 AM, David Burns wrote: I don't think anyone would disagree with the reasons for doing this. I, like James who brought it up earlier, am concerned that we from the emails appear to think that implementing the

Re: Intent to ship: CSP directive worker-src

On 22/09/17 15:18, Christoph Kerschbaumer wrote: Hey Everyone, within CSP2 workers used to be governed by the child-src directive [0]. CSP3 introduces the worker-src directive [1] wich governs Workers, SharedWorkers as well as ServiceWorkers. Please note that the child-src directive has been

Re: Intent to ship: CSP directive worker-src

On 18/10/17 10:35, Christoph Kerschbaumer wrote: On Oct 18, 2017, at 11:25 AM, James Graham <ja...@hoppipolla.co.uk> wrote: On 22/09/17 15:18, Christoph Kerschbaumer wrote: Hey Everyone, within CSP2 workers used to be governed by the child-src directive [0]. CSP3 introduces the work

Re: Intent to ship: (hyperlink auditing)

On 02/10/17 18:06, Anne van Kesteren wrote: Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=951104 Rationale: There's already a myriad of ways to obtain this data through script. We might as well ship the protocol that both Chrome and Safari ship in the hope that along with sendBeacon() it

Re: Intent to implement (again): Shadow DOM

On 27/11/17 12:20, smaug wrote: This is basically an after the fact notification that we're in progress of implementing Shadow DOM again, this time v1[1]. While doing this, the v0 implementation, which was never exposed to the web, will be removed. v1 is luckily way simpler, so this all should

  1   2   >