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

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 MANIFE

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 i

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

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

On 08/03/17 14:24, Ehsan Akhgari wrote: On 2017-03-08 6:40 AM, James Graham wrote: 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 ma

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 wou

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

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: 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 wpt-manifest-upda

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

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

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 specific testing. It is targeted more at web d

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 lim

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: 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 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. […] I’m

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 another time frame that

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

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

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 WebD

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 l

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 wire protocol would b

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: https://activedata.alli

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 chun

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 "What legacy syntax sho

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 i

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 dec

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 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 worker-src directive [1] wich

Re: PSA: Microsoft VMs for testing

On 07/11/17 13:47, Tom Ritter wrote: Warning: they auto-shut down after 30 minutes (maybe? I never timed it). I haven't put any effort into figuring out if that's configurable, but I don't think it is. I think that only happens once the trial period expires but you can reinstall the VM to rese

Re: Intent to ship: CSP Violation DOM Events

On 17/11/17 05:55, Chung-Sheng Fu wrote: Content Security Policy suggests Security Policy Violation DOM Events [1]. In case any of the directives within a policy are violated, such a SecurityPolicyViolationEvent is generated and sent out to a reporting endpoint associated with the policy. We are

Re: Intent to ship: CSP Violation DOM Events

On 17/11/17 16:06, Daniel Veditz wrote: On Fri, Nov 17, 2017 at 2:01 AM, James Graham <mailto:ja...@hoppipolla.co.uk>> wrote: Do we have cross-browser (i.e. web-platform) tests covering this feature? We fail many of the existing CSP web platform tests, despite having impleme

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

Re: Intent to ship: CSS Shapes Module Level 1 (partial)

On 29/11/17 11:03, Ting-Yu Lin wrote: CSS Shapes Module Level 1 [1] defines three properties: "shape-outside", "shape-margin", and "shape-image-threshold" (used with shape-outside: ), which allows the users to define non-rectangular shapes for floating elements. See the previous discussion for t

Re: Intent to Ship: Web Authentication

On 05/12/17 20:44, J.C. Jones wrote: Summary: Support public key cryptographic authentication devices through Web Authentication. This sounds pretty cool! Testing: Mochitests in-tree; https://webauthn.io/; https://webauthn.bin.coffee/ ; Web Platform Tests in-progress Are the web-platform-te

Re: Intent to Ship: Set document.URL (location) to url of active document when navigation started for javascript:-generated documents

On 12/12/17 14:49, Samael Wang wrote: The current behavior that Firefox would set document.URL to the javascript: URL on navigating to the javascript:-generated document doesn't fit HTML5 standard: https://html.spec.whatwg.org/#javascript-protocol We're going to fix that in bug 836567, and ship

This year in web-platform-tests

I thought that people might be interested in a retrospective on the progress with web-platform-tests in the last year. 2017 has seen big advance in the adoption of web-platform-tests by the wider browser community, and has brought considerable improvements to the associated tooling and infrastruct

Next year in web-platform-tests

Following the summary of what we achieved in wpt in the last year, I'd like to solicit input from the gecko community to inform the priorities of various pieces of wpt work for the next year. In order to maximise the compatibility benefit we have two long term objectives for the web-platform-test

Re: Intent to implement: support CSS paint-order for HTML text

On 24/12/2017 13:13, Emilio Cobos Álvarez wrote: On 12/24/2017 02:01 PM, Jonathan Kew wrote: Tests - Is this feature fully tested by web-platform-tests? No, as it is not yet spec'd (see above). I propose to land a basic mozilla reftest along with the patches in bug 1426146 (behind a pref); if/wh

Improved wpt-sync now running experimentally

The new sync for web-platform-tests is now running experimentally. This provides two way sync between the w3c/web-platform-tests repository on GitHub and mozilla-central, so allowing gecko developers to contribute to web-platform-tests using their normal gecko workflow, and ensuring that we get

Re: Improved wpt-sync now running experimentally

On 09/02/2018 19:59, Josh Bowman-Matthews wrote: On 2/9/18 1:26 PM, James Graham wrote: * One bug per PR we downstream, filed in a component determined by the files changed in the PR. What does this mean exactly? What is the desired outcome of these bugs? They're tracking the proces

Re: Improved wpt-sync now running experimentally

On 12/02/2018 20:08, smaug wrote: On 02/09/2018 10:39 PM, James Graham wrote: On 09/02/2018 19:59, Josh Bowman-Matthews wrote: On 2/9/18 1:26 PM, James Graham wrote: * One bug per PR we downstream, filed in a component determined by the files changed in the PR. What does this mean exactly

Re: Intent to ship: Module scripts (ES6 modules)

On 14/02/2018 14:13, jcoppe...@mozilla.com wrote: I intend to turn on

Re: Intent to ship: OpenType Variation Font support

On 19/03/2018 22:32, Jonathan Kew wrote: As of this week, for the mozilla-61 cycle, I plan to turn support for OpenType Font Variations on by default. It has been developed behind the layout.css.font-variations.enabled and gfx.downloadable_fonts.keep_variation_tables preferences. Other UAs s

Re: Intent To Require Manifests For Vendored Code In mozilla-central

On 10/04/2018 05:25, glob wrote: mozilla-central contains code vendored from external sources. Currently there is no standard way to document and update this code. In order to facilitate automation around auditing, vendoring, and linting we intend to require all vendored code to be annotated wi

Re: Intent To Require Manifests For Vendored Code In mozilla-central

On 10/04/2018 14:34, Ted Mielczarek wrote: On Tue, Apr 10, 2018, at 9:23 AM, James Graham wrote: On 10/04/2018 05:25, glob wrote: mozilla-central contains code vendored from external sources. Currently there is no standard way to document and update this code. In order to facilitate automation

Re: Intent to ship: PerformanceServerTiming

On 24/04/2018 20:32, Valentin Gosu wrote: Bug 1423495 is set to land on m-c and we intend to let it ride the release train, meaning we are targeting Firefox 61. Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=702760 This

Re: Intent to ship: PerformanceServerTiming

On 24/04/2018 22:36, Valentin Gosu wrote: On 24 April 2018 at 22:44, James Graham <https://bugs.chromium.org/p/chromium/issues/detail?id=702760> This affects web-compat, since per our "restrict new features to secure origins policy" the server

Re: Intent to ship: media-capabilities

On 14/05/2018 16:19, Jean-Yves Avenard wrote: Media Capabilities allow for web sites to better determine what content to serve to the end user. Currently a media element offers the canPlayType method (https://html.spec.whatwg.org/multipage/media.html#dom-navigator-canplaytype-dev

Re: Launch of Phabricator and Lando for mozilla-central

On 06/06/2018 15:57, Mark Côté wrote: Similarly, there are two other features which are not part of initial launch but will follow in subsequent releases: * Stacked revisions. If you have a stack of revisions, that is, two or more revisions with parent-child relationships, Lando cannot land th

Re: Fwd: WPT Developer Survey - June 2018

On 19/06/2018 10:01, Andreas Tolfsen wrote: If you run, write, or work with Web Platform Tests (WPT) in some capacity, we would like to invite you to answer a short survey. The survey helps us identify ergonomic problems so that we can improve the tools for building an interoperable web platform

Re: PSA: pay attention when setting multiple reviewers in Phabricator

On 05/07/2018 18:19, Mark Côté wrote: I sympathize with the concerns here; however, changing the default would be a very invasive change to Phabricator, which would not only be complex to implement but troublesome to maintain, as we upgrade Phabricator every week or two. This is, however, som

Re: Intent to ship: Changes to how offset*, client*, scroll* behave on tables

On 10/07/2018 17:25, Boris Zbarsky wrote: Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=820891 Summary: In other browsers, and arguably per spec as far as cssom-view specs things, various geometry APIs on tables should report values for the table wrapper, not the table itself, because they

Re: PSA: Re-run old (non-syntax) try pushes with |mach try again|

On 17/07/2018 21:16, Nicholas Alexander wrote: Ahal, On Tue, Jul 17, 2018 at 11:55 AM, Andrew Halberstadt > wrote: While |mach try fuzzy| is generally a better experience than try syntax, there are a few cases where it can be annoying. One common case was w

Re: Developer Outreach - Web Platform Research and Recommendations

On 26/07/2018 19:15, Dietrich Ayala wrote: Why are we doing this? The goals of this effort are to ensure that the web platform technologies we're investing in are meeting the highest priority needs of today's designers and developers, and to accelerate availability and maximize adoption of th

Re: Developer Outreach - Web Platform Research and Recommendations

On 27/07/2018 21:26, Dietrich Ayala wrote: Additionally, much of what we're proposing is based directly on the interviews we had with people in different roles in the development of the web platform. Common themes were: lack of data for making selection/prioritization decisions, visibility of wha

Re: Developer Outreach - Web Platform Research and Recommendations

On 31/07/18 10:34, James Graham wrote: One of the underlying concerns I have here is that there are a lot of separate groups working on different parts of this. As one of the people involved, I would nevertheless struggle to articulate the overall Mozilla strategy to ensure that the web

Re: ./mach try fuzzy: A Try Syntax Alternative

On 06/08/2018 01:25, Botond Ballo wrote: Is there an easy way to do a T-push (builds on all platforms, tests on one platform only) with |mach try fuzzy|? I usually do T-pushes using try syntax, by Trychooser seems to be out of date when it comes to building a T-push syntax for Android, so I'm at

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 wrote: On Mon, Aug 3, 2015 at 12:32 AM, Anne van Kesteren wrote: On Mon, Aug 3, 2015 at 9:23 AM, Jonas Sicking wrote: I think something like a might be a simpler solution here. Coupled with either simply

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 a

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 any

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 c

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? Yeah, I'm confused. If

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 wrote: What are the implications of this? The web-platform tests are pass/fail, right? So is it a bug if

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 do

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 ends with a RequestLon

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 18:09, Tim Guan-tin Chien wrote: I wonder if there is any use cases to do multiple Try pushes of different changesets but with the same bug number. Should we automatically cancel the old ones when there is a new one? Unfortunately there are legitimate uses for e.g. comparing the eff

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 ad

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 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 MANFEST.json is different before and

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 can

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 wi

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

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 common

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 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 O'Duinn suggests[5] for

Re: Pushes to Backouts on Mozilla Inbound

On 05/11/13 15:20, Till Schneidereit wrote: Do we have any way to identify tests that break particularly often for specific areas? If so, we could create a mach command that runs just these tests and finishes quickly. Something like `mach canary-tests`. Isn't the end game for this kind of appr

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

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 outsid

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 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 for Autoland, but of cou

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 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 regressions that cause it to

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 wrote: If a bug is causing a test to fail intermittently, then that test

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 st

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 det

Re: Standardized assertion methods

On 03/06/14 14:16, Mike de Boer wrote: > Writing wrappers in python around things to improve the current > situation like a band-aid isn’t the way I’m used to fix things; I > like to take the bull by the horns[1] > > I’d like to ask _why_ structured logging needs to be bolted on top of > what we

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 al

Re: Standardized assertion methods

On 03/06/14 20:34, Boris Zbarsky wrote: > I'm arguing against Assert.jsm using the commonjs API names. And I am arguing against using the CommonJS semantics. If we are adding new assertions it shouldn't be ones that encourage broken tests. ___ dev-plat

Re: Standardized assertion methods

On 04/06/14 18:42, Mike de Boer wrote: > On 04 Jun 2014, at 19:20, Ehsan Akhgari > wrote: > >> On 2014-06-04, 5:45 AM, Mike de Boer wrote: >>> On 04 Jun 2014, at 00:33, James Graham >>> wrote: >>> >>>> On 03/06/14 20:34, Boris Zbarsky wrote

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

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

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

  1   2   3   >