googlechromelabs / confluence Goto Github PK

Creating custom views by interacting with confluence graphs (except for API Velocity, they are okay) triggers an expensive query and data rehashing procedure.

The real problem here is that the client-side part (data caching and rehashing) is done largely synchronously on the same worker that serves all other data queries. Hence, attempting to load a custom confluence view, then navigating to the catalog view yields an empty table. Returning to the confluence view yields no graphs (because they also query via the worker for their data).

Based on discussion of #57 we should rename classes and variables named browser* (except browserName and browserVersion) to release*, because we intend a particular release of a browser. Similarly, comments and variable names that refer to vendor actually refer to a particular browser (which has multiple releases).

@arobins does that sound right?

This info provides important context to anyone inspecting the graphs.

Standard DAO decorator introduced in https://github.com/foam-framework/foam2/pull/318/files#diff-2981b40014961d72e93be57efd49e5e2R20.

Metrics each contain roughly the same data with different semantics/labels. Also, the set ops refactor exposed similar patterns in how metrics are computed. The metric computer classes should probably be consolidated into:

• A single metric data class
• A metric computation interface
• Three metric computation implementations

It would be nice if the user could add/select vendors to include in time series graphs. This would eliminate the need for separate graphs to show "all browsers" and "each browser individually".

I get "failed - Network error" whenever I try to use "download CSV"

Eg. in the "Safari API diff history" I'm surprised to see so many APIs listed as removed. I want to somehow see a list of what these APIs are.

@foolip says that in addition to the "1 year grace period" view of browser-specific APIs, he'd like to also see a picture of the debt we're creating the minute we are the first to ship a new API. I.e. at any given point in time, how many APIs exist for the one browser but no others.

I don't think this data will be particularly actionable (we don't consider shipping first to be problem in and of itself), but we should see a saw-tooth pattern that gives some indication of how we're creating temporary "stretch" in the band which later gets relaxed.

Some (all?) of this can go in README.md

When custom views are created for drilling down in metrics graphs, their tabs are labeled "#VIEW0", "#VIEW1", etc. in the UI. Almost anything would be better than this.

Metrics views create a point on each line for shipping from any browser. When the browser shipped is the browser associated with the current line, make the point a different colour.

window.Screen.prototype should have a bunch of properties eg. availTop, but I don't see them in the raw data (Except for a couple Chrome releases under an interface named ))).

The mobile browsers should have mostly the same surface area as their desktop counterparts, but there are some interesting differences. We talked about adding Chrome Android, right? What are the trade offs here?

All app states should be linkable. This means that we would have different URLs (possibly just a different anchor/fragment) for:

• API catalog (and custom views spawned by analysis)
  • Page number
  • Expand all state
  • Search query
  • Currently selected browsers
• Analysis
  • Currently selected view
  • State for custom views

This may prove to be too much state. Perhaps we want the ability to generate a link for API-catalog-style views, and current app state on the current machine could go in IndexedDB or similar so that custom views aren't lost on a single client.

The client worker script and ApiMatrix should be smart enough to fetch smaller batches of data and only produce a matrix of data relevant to the current page (and maybe a couple surrounding pages).

We're hoping that we can get the list of supported CSS properties showing up consistently in CSSStyleDeclaration. In Firefox the properties are on CSS2Properties.prototype instead of CSSStyleDeclaration.prototype. I think we had some plan for merging CSS2Properties "up" into CSSStyleDeclaration, right? I don't see CSS2Properties members showing up in the catalog for Firefox.

In Safari, the properties appear to sort of show up as own-properties on instances of CSSStyleDeclaration:

Object.getOwnPropertyNames(document.body.style) -> contains "borderStyle"
Object.getOwnPropertyDescriptor(document.body.style,'borderStyle') -> Object
Object.hasOwnProperty(document.body.style, 'borderStyle') -> false, WTF?

Safari 5.1 and 6.0 (according to the data) ship < 500 APIs. That does not seem right.

Some metric compute() implementations contain a lot of Promise synchronization and exploiting side-effects in accumulating (or reducing) objects and arrays. They should be cleaned up to concisely express the queries they intend, which will probably require custom mLangs and/or sinks, such as DISTINCT.

So people know where to go to file bugs / feature requests

Firefox's CSS2Properties is a non-standard interface that extends a very small CSSStyleDeclaration. The union of these interfaces is what is meant by a "standard CSSStyleDeclaration" implementation in Firefox. This is a known issue, but is not high priority for the Firefox team.

We have two flavours of time series charts:

• Plain time series (but multiple may appear on one graph)
• "Tri-time-series": Used for number of APIs + add/remove delta on a single series

Right now, there is no common base class for these, even though a lot of setup work is the same.

Similar to https://github.com/GoogleChrome/webidl-diff test setup. This should fix our misleading high coverage metrics (we're missing tests for all the code in #33 but it claims to have no impact on coverage). This will be necessary before we can fix #35.

Maybe just link to this post?

@jingt06 PTAL & link from PR comments.

Same as done with webidl-diff here and here.

The metrics doc defines browser-specific as:

How many APIs does this engine ship that appear in fewer than 2 other engines for at least a year?

README.md, confluence.html, and the metric calculator (lib/confluence/browser_specific.es6.js) document and implement this as:

How many APIs does this engine ship that appear in no other engines for at least a year?

This is important to fix especially because the common WebKit lineage of Safari and Chrome deflate their metric.

Now that the model for chart data points has been unified, the chart code for various metrics (except API Velocity) is virtually identical. We should just have one chart.

Can be seen at http://web-confluence.appspot.com/#!/catalog?releaseKeys=%5B%22Chrome_53.0.2785.113_Windows_10.0%22,%22Chrome_53.0.2785.101_Windows_10.0%22%5D&releaseOptions=%7B%22Chrome_53.0.2785.113_Windows_10.0%22:true,%22Chrome_53.0.2785.101_Windows_10.0%22:false%7D&numAvailable=null&currentPage=0&gap=5&itemPerPage=15&searchKey=%22%22

It claims that lots of things on CSSStyleDeclaration have changed.

Steps to reproduce:

1. In an API velocity graph, click any point
2. Scroll to another graph and click that point
3. There are now two popups showing. Click outside to close the second of them.

The first popup now sits around, impossible to dismiss

The table loads the correct header, but the data don't show up. Perhaps it's just taking forever to fetch from Datastore, but it seems like something is actually failing.

Often you just want to see the latest Chrome, Firefox, Edge and Safari data. Perhaps pre-populate the browser list with that (all Windows, except Safari)?

These metrics included:

• Overall API confluence: what fraction of the total APIs are present in at least 3 or 4 engines at any given time?
• First to implement: How many APIs did this browser ship that were later shipped by at least 2 or 3 other browsers?

The catalog view currently has a few issues:

• Small fixed width
• Check/x tiles are huge; let's tighten them up
• Browser headings are pretty verbose/wide; tighten them up too

Modernizr is a hand-curated list of feature detects. In many ways the status of each of these detects is as relevant to API confluence as the presence/absense of a JS API. In some cases they're the same (eg. Modernizr.JSON is a simple combination of JS API checks (and so redundant with our API confluence data), but in other cases they're much more interesting things that couldn't be automated generically (eg. passive event listeners).

I think it could be reasonable to just add ALL the Modernizr feature detects as additional "APIs" in our confluence list (though we might want an option to filter them out in some views).

/cc @patket

The tool is for data analysis (not reading prose) on desktop/laptop machines so there's no reason to limit the main view's width.

A promise rejection error is logged when the search action is committed.

It should be possible to remove custom views that were created by drilling down into analysis graphs.

We have tests that use the emulator to ensure that FOAM models are behaving as expected, but there is no code checked in that, when run in a Compute/App Engine context, will commit data to Cloud Datastore (yet).

In https://bugs.chromium.org/p/chromium/issues/detail?id=695984 I was using the tool to see if the disabled attributes were supported in all the engines. I got my answer for the 3 element interfaces, but couldn't find the StyleSheet interface at all. Collection bug or display bug?

I think the more useful version number for Safari is the Version/ one (eg. 10.0.03), not the Safari/ one (eg. 602.4.8).

Some flow in catalog search is throwing (client-side) on master branch.

Computation routines are landing on the tail end of @jingt06 's internship. We haven't written tests for them yet 😢

The list is getting a little unwieldy. Maybe do something multi-level - first pick one of the 5 browsers, then the OS, then the version (sorted with most recent first)?

Metrics are computed assuming 4 modern engines (Edge, Blink, WebKit, Gecko). IE (Trident) data should not be included in analysis.