A while back we renamed a bunch of pages from "quantum" to "tp6".
It's been long enough and the old pages don't show up.

The tp6 loaded graph takes you here:
https://mzl.la/2FSMyeg
The link should lead us to this:
https://mzl.la/2Hzr7fC

There's a list of signatures in here that we need to trim:
https://github.com/mozilla/firefox-health-dashboard/blob/master/src/quantum/index.js#L297-L302

As discussed, and as a separate dashboard/link from the home page, we'd like a dashboard showing how things are tracking for android/geckoview throughout the year

Within bugzilla we are now tracking [qf:needs-analysis] and [qf:analyzed] whiteboard tags, this will be a top line goal for 2018 to keep performance issues well triaged.

We need to create a graph showing two lines over time indicating the NeedsAnalsyis:Analyzed ratio of profiling bugs

Some graphs are stuck saying "Loading Perfherder …"

Loading http://localhost:3000/api/perf/notes returns (in the console):

Failed to load resource: the server responded with a status of 500 (Internal Server Error)

On the server side we get the following:

  SyntaxError: Unexpected token u in JSON at position 0
      at JSON.parse (<anonymous>)
      at /Users/armenzg/repos/platform-health/src/perf.js:24:25
      at Generator.next (<anonymous>)
      at step (/Users/armenzg/repos/platform-health/src/perf.js:64:191)
      at /Users/armenzg/repos/platform-health/src/perf.js:64:437
      at Promise (<anonymous>)
      at /Users/armenzg/repos/platform-health/src/perf.js:64:99
      at getSpreadsheetValues (/Users/armenzg/repos/platform-health/src/perf.js:22:7)
      at /Users/armenzg/repos/platform-health/src/perf.js:144:24
      at Generator.next (<anonymous>)
      at step (/Users/armenzg/repos/platform-health/src/perf.js:64:191)
      at /Users/armenzg/repos/platform-health/src/perf.js:64:437
      at Promise (<anonymous>)
      at /Users/armenzg/repos/platform-health/src/perf.js:64:99
      at router.get.get (/Users/armenzg/repos/platform-health/src/perf.js:121:1)
      at dispatch (/Users/armenzg/repos/platform-health/node_modules/koa-compose/index.js:44:32)

We should only have white background behind the targetStatus and not see the green/yello at the top.

The upgrade requires some code changes.

When I split the frontend and backend code I decided to leave a bunch of custom linting rules.
If we remove them all we will likely catch some bugs we could otherwise be introducing.

Removing the custom rules will require refactoring the code to meet the airbnb style guide.

This is also useful since IDE editors that including linting do not know how to handle linting rules within .neutrinorc.js

Just a nice to have to understand and debug health.graphics life; making it more educational.

CC @eliperelman

If you run yarn start after the refactoring you will see some warning messages like these:

6:5 ⚠ Custom property ignored: not scoped to the top-level :root element (:root { ... --fontSize: ... }), in atrule [postcss-custom-properties]
65:5 ⚠ Custom property ignored: not scoped to the top-level :root element (:root { ... --h1FontSize: ... }), in atrule [postcss-custom-properties]
66:5 ⚠ Custom property ignored: not scoped to the top-level :root element (:root { ... --h1Lines: ... }), in atrule [postcss-custom-properties]
67:5 ⚠ Custom property ignored: not scoped to the top-level :root element (:root { ... --h2FontSize: ... }), in atrule [postcss-custom-properties]
68:5 ⚠ Custom property ignored: not scoped to the top-level :root element (:root { ... --h1Lines: ... }), in atrule [postcss-custom-properties]

These warnings were not in the originally project, thus, I decided to try to bring the postcss plugins usage closer to the real thing.

Now, visually, I could not tell that there were any discrepancies between the previous version and the current refactoring.
The only difference I could tell is that the generated css files were different.

The code prior to refactoring had this [1]:

    {
        loader: 'postcss-loader',
        options: {
           plugins: () => [
                postcssImport(),
                postcssSimpleExtend(),
                postcssNested(),
                postcssVariables(),
                postcssCssnext({
                  browsers: ['last 1 version'],
                }),
                postcssReporter({
                  throwError: true,
                }),
                mqpacker(),
],

When I switched to Neutrino, it seems I wrote a postcss.config.js file incorrectly [2] and it was doing nothing useful. In essence the postcss-loader from Neutrino would run with the defaults.

On this branch [3], I've got postcss plugins to actually kick in, however, a couple of them produce a bunch of errors. I needed to remove these two:

                postcssVariables(),
                postcssCssnext({
                  browsers: ['last 1 version'],
                }),

Now, if I use the same set of dependencies and the same set of plugins I would assume I should not get these new errors.

Before I go any further, I'm going to verify that all dependencies related to postcss are as close as possible to the original project.

[1] https://github.com/mozilla/firefox-health-dashboard/blob/1494caad2b27b9005c9dd94af1a99368d5a3b6cc/webpack.config.babel.js#L92-L109
[2] https://github.com/mozilla/firefox-health-dashboard/blob/master/src/postcss.config.js
[3] master...armenzg:neutrino_postcss

Each graph should have the ability to be annotated so we can add details/context around what a regression or improvement may be, and link out to a bug if there are relevant details.

Ask me for details, some still tbd :) Just wanted to get this filed while I'm thinking of it

We renamed a bunch of Talos jobs to include "stylo" in their name (I think) back in February.
Unfortunately, if you look at the Quantum page you would not notice easily that we're missing data since then.

@stuartphilp CC

Once tp6 is updated we will be able to add these new tests:

• First paint
• Hero element
• First contentful paint
• Domcontentloaded

In tmo.js we add a lot of code to fetch a telemetry evolution.

It is a better long investment to use the package provided by telemetry team:
https://www.npmjs.com/package/telemetry-next-node
https://github.com/mozilla/telemetry-next-node

preferably directly pull in, but at least link to the photo dashboard at: http://astithas.com/perm/photon-perf/

this should be in spot #3, just before page load times

After speaking with @stuartphilp we need to address the following:

• Drop "First Paint" and "Hero Element"
• Remove incorrect labels for tp6 loaded

Speedometer changes:

• Comparing against Canary 2017 should be 105% target rather than 95%
• Add permanent legend labels
• 1st graph to say "Nightly, Beta & current Canary"
• 2nd graph to say "Current Nightly vs Canary Dec. 2017"

Right now, the percentage value is always positive regardless if we're slower.

There's a bunch of places where we use metrics-graphics directly instead of react-metrics-graphics [1][2]. There's also some custom CSS code to modify the defaults of metrics-graphics.

The telemetry code also added some CSS adjustments.

Soon I will be landing some support for react-metrics-graphics (in #24 )

If anyone's interested on contributing I can add some info on how to make it work.

[1]

armenzg@armenzg-mbp platform-health$ git grep MG
static/crashes/firefox-ut.js:import MG from 'metrics-graphics';
static/crashes/firefox-ut.js: const data = MG.convert.date(crashes, 'date');
static/crashes/xp.js:import MG from 'metrics-graphics';
static/crashes/xp.js: crashes[0] = MG.convert.date(crashes[0], 'date');
static/crashes/xp.js: crashes[1] = MG.convert.date(crashes[1], 'date');
static/crashes/xp.js: crashes[2] = MG.convert.date(crashes[2], 'date');
static/crashes/xp.js: MG.data_graphic({
static/graphic.js:import MG from 'metrics-graphics';
static/graphic.js: MG.data_graphic(Object.assign(options, this.props, override));
static/regressions.js:import MG from 'metrics-graphics';
static/regressions.js: MG.data_graphic({
static/telemetry/graph.js:import MG from 'metrics-graphics';
static/telemetry/graph.js: const newDatas = datas.map(evo => MG.convert.date(evo, 'date'));
static/telemetry/graph.js: MG.data_graphic({

[2]

static/index.css:@import "metrics-graphics/dist/metricsgraphics.css";

We have no test coverage and it would great to add tests specially for the logic used on the Quantum page since we change it so often.

The question of which Chrome channel (Beta or Canary) we're comparing Firefox Beta and Nightly against has come up a few times. We should label the graphs to avoid the question. Something like:

"Benchmark: Speedometer v2 32-bit Nightly vs Chrome Beta" (unless we are actually testing Canary, IDK)
"Benchmark: Speedometer v2 32-bit Nightly vs Chrome Canary"

Make important data work on small screens.

Requested by EPM to monitor 57 rollout health.

@stuartphilp looks like we have the data on AWFY.

This will reduce the cost of maintaing two different approaches (direct svg manipulation) as well as gaining some features (e.g. hovering over data points issue #55).

Several routes in /src/quantum/routes.jsx are failing when testing on health.graphics and locally:

• 'track' route shows in error in the console (TypeError: e is undefined) and the page isn't loading
• 'responsiveness/parent', 'responsiveness/content', and 'pageload/render' all fail to fully load and show this message in the console:
  "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://firefox-health-backend.herokuapp.com/api/perf/version-evolutions?child=content&e10sEnabled=true&metric=TIME_TO_NON_BLANK_PAINT_MS&os=Windows_NT. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing)"

This is an old screenshot but it pictures the problem quite clearly.
We want to support this in PerfherderGraphContainer.

[1]

The benchmarks that digitard put together look a lot like confidence bands (I think that is the right term).

I would like to see if that code can be resued for graphs generated using metrics-graphics.

E.g.

Scope

Operations

• P1/P2 Burn up charts
• Triage backlog
• Bug age

Performance

• DAMP breakdown: https://bugzilla.mozilla.org/show_bug.cgi?id=1397745

Engagement

• Opening counts (per channel)

With the latest release of react-metrics-graphics we have been able to include it into the project (#62).

We can now migrate from the old-style to react-metrics-graphics.

Switch from metrics-graphics to react-metrics-graphics:
https://github.com/mozilla/firefox-health-dashboard/search?utf8=%E2%9C%93&q=metrics-graphics&type=

Sometimes, Perfherder will stop having recent data, however, the graphs do not make it easy to notice.

We need to add some code that would look for the most recent data point, determine if it's been longer than 3 days and show an error panel underneath it saying so.

See issue #68 for when it happened in the past.

Use the ErrorPanel component:
https://mozilla-frontend-infra.github.io/components/#errorpanel

Possibly show:

Speedometer v2 Chrome absolute value - label “Chrome” color:red?
Speedometer v2 Firefox Nightly absolute value - label “Nightly” color: orange?
Speedometer v2 Chrome*.8 value - label “Target 57” color: grey?
Speedometer v2 Chrome*.9 value - label “Target 60” color: green?

There's some new benchmarks that we need added that need support for subbenchmarks.
This issue focuses on adding support for it.

specifically around ongoing quantum efforts, since they have different priorities/scopes/needs 32 and 64 bit should be shown independently

To do:

• Separate backend from frontend
• Switch frontend to Neutrino
• Make sure it deploys correctly and keeps running tests

I assume this will take few days to over a week.

The work will happen in https://github.com/armenzg/platform-health/tree/separate

We currently query json-pushes to give us all the pushes in the last day which we then turn into changesets.
After we do that, for every changeset we asynchronously query the backend (producing 100-400 fetches) and wait for all of them to finish first.
This is specially bad since the browser allows for a maximum of 6 fetches in parallel.
Nothing in the UI is rendered until all fetches have been completed.

Now, there's a two tier approach I want to implement.
We first query for every push the tipmost changeset.
For the pushes that have coverage data we then proceed to fetch the data of all of its changesets. When that batch of changesets is completed we proceed to set the state and the UI will show all changesets for that specific push.

This approach would likely cause the main view to show changesets on batches. I don't know how much of a problem it would be from a UX perspective (e.g. about to click on a changeset and it suddenly a new changesets shows up in its place). We will have to see.

I can see 'win7-32' but not the other one.

@wlach @eliperelman I'm trying to add react-metrics-graphics to platform-health, however, I'm getting an issue I can't understand.

When I load http://localhost:3000/quantum from this branch.
I get the following:

ERROR in ./node_modules/react-metrics-graphics/node_modules/metrics-graphics/dist/metricsgraphics.css
Module parse failed: Unexpected token (1:0)
You may need an appropriate loader to handle this file type.
| .mg-active-datapoint {
| fill: black;
| font-size: 0.9rem;
@ ./node_modules/react-metrics-graphics/build/MetricsGraphics.js 1:3421-3473
@ ./static/plotting.js
@ ./static/quantum/index.js
@ ./static/routes.js
@ ./static/index.js
@ multi react-hot-loader/patch webpack-hot-middleware/client?reload=true ./index.js

Here's a link to the code that tries to import the CSS module.

I've tried using the following as indicated in here:

diff --git a/webpack.config.babel.js b/webpack.config.babel.js
index 53d9286..f686bf2 100644
--- a/webpack.config.babel.js
+++ b/webpack.config.babel.js
@@ -83,19 +83,24 @@ export default {
         test: /\.js$/,
         include: srcDir,
         use: 'babel-loader',
       },
       {
         test: /\.css$/,
         include: srcDir,
         use: [
           'style-loader',
-          'css-loader',
+          {
+            loader: 'css-loader',
+            options: {
+              modules: true,
+            },
+          },
           {
             loader: 'postcss-loader',
             options: {
               plugins: () => [
                 postcssImport(),
                 postcssSimpleExtend(),
                 postcssNested(),
                 postcssVariables(),
                 postcssCssnext({

Graphs using metrics-graphics allow the user to hover over the various data points and shows the actual value for each point.

This is a feature that the Talos graphs do not have.

Allowing this feature would most likely require switching over to metrics-graphics which won't be trivial. I also think we would loose the aura around each line (cloud of dots around the median/average (?) line).

these measures are not actionable today and should not be tracked

It will help debugging production issues.

• Touch Scrollbar Dragging Bug 1367765 was enabled in Nightly 57 (2017-09-13).
• Keyboard Scrolling Bug 1376525 was enabled in Nightly 57 (2017-09-01).
• Autoscrolling Bug 1385463 was enabled in Nightly 57 (2017-09-02).

That data might actually be indicated in perfherder.

The Photon graphs show different colours for each Fx version [1].
The data coming from Telemetry has the data split like that already.

It would be nice if we could take the same approach for the Speedometer graphs [2] (it currently only shows an orange line).

We can handle this by moving data points into buckets according to the release dates.
We will need a data source to determine the dates or update them manually.

We could also add simple markers on the graph indicating the release dates.

This versions API could have been the one, however, it seems to return 404. Filed as mozilla/firefox-health-backend#15.

[1]

[2]

label changed in perfherder from quantum to tp6

Joel is adding few benchmarks that were originally running in AWFY into Talos/Perfherder.
Once these are ready for Windows we can add them to the Quantum page.

These benchmarks have subbenchmarks and code to support it will be landed on issue #43.

List of benchmarks:

• MotionMark
• JetStream
• ARES-6

travis is currently building on node 5, koa requires node 7 (hence the travis failures)

node 7 seems to introduce some other errors possibly around webpack, or browserslist, or caniuse-db (browserslist.queries is undefined)

CC @eliperelman @digitarald @wlach

I've been trying to separate the frontend and backend because I did not know how to debug a build issue. I see the value of running both from the same URL, thus, here's my attempt at trying to hopefully fix this in an easier way.

I also tried to switch the project to using Neutrino but I gave up as well.

I originally reported the production build issue in this comment [1]

I believe the issue comes from trying to use es2015-loose with a package (react-metrics-graphics) that has es2016 syntax (I think). See this issue.

Here's what is mentioned on that comment:

Uglify cannot parse ES6, it will throw you syntax errors. Either:

• set TypeScript to target ES5
• post-process your generated JS with babel
• or use a different minifier.

This is what the official documentation says:

When using uglify-js to minify your code, you may run into syntax errors when targeting later browsers since uglify-js does not support any ES2015+ syntax.

To prevent these errors - set the uglify option to true, which enables all transformation plugins and as a result, your code is fully compiled to ES5. However, the useBuiltIns option will still work as before and only include the polyfills that your target(s) need.

Uglify has support for ES2015 syntax via uglify-es. If you are using syntax unsupported by uglify-es, we recommend using babel-minify.

Please let me know if you have any suggestions on what to try.

I'm going to try to switch to babel-minify.

[1]

ERROR in app.1683db.js from UglifyJs
Unexpected token: name (l) [../node_modules/react-metrics-graphics/build/MetricsGraphics.js:1,2669][app.1683db.js:106701,2637]
Child html-webpack-plugin for "index.html":
1 asset
[0] ../node_modules/html-webpack-plugin/lib/loader.js!./index.html 689 bytes {0} [built]
+ 3 hidden modules
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.