URL blocking patterns configuration UI #1455

weiwei-lin · 2017-01-12T01:58:54Z

Implement UI for URL blocking patterns configuration. Part of #1143
Design Overview:
Toggles in critical request chain section for users to choose which resources to block.
A fixed bottom bar where all the configurations for the next run are shown.

weiwei-lin

Haven't implement the bottom bar yet and still need to fix some bugs. But would like to have some feedback on the UX design first (about the toggle in the critical resources chain section).

Design Overview:

Blocked resources (in the previous run) will be stroke out
User can click on toggles to choose which URLs to block
- Red cross: URL will be actively blocked
- Black cross: resource will be blocked because it's parent will be blocked

Currently, it's not very obvious that those toggles are to configure request blocking patterns in the next run. Later in this PR, a fixed bottom bar will be added. It will show URL blocking patterns update messages.
Unit test for critical request chain is broken for now. Because the html structure of the critical resources tree is changed. Will fix this after we confirmed the UI design.
The bottom bar is not implemented yet.

Could you give me some advice : ) @paulirish @brendankenny @ebidel @samuelli

weiwei-lin · 2017-01-12T02:01:10Z

lighthouse-core/formatters/partials/critical-request-chains.html

 </style>

 {{#*inline "writeNode"}}
-  <div class="cnc-node" title="{{ this.node.request.url }}">
+  <div class="cnc-node js-cnc-node" title="{{ this.node.request.url }}" data-blocked="{{ this.node.request.blocked }}" data-to-block="{{ this.node.request.blocked }}">


blocked: blocked in this run
to-block: block in next run

weiwei-lin · 2017-01-12T02:01:43Z

lighthouse-core/formatters/partials/critical-request-chains.html

+      {{#createContextFor ../node.children @key ../treeMarkers ../isLastChild ../startTime ../transferSize }}
+        {{> writeNode this }}
+      {{/createContextFor }}
+    {{/each}}


Make the request tree more like a tree in DOM. So we can have a better representation of requests in DOM and make it easier to show correct toggle icon.

weiwei-lin · 2017-01-12T02:10:22Z

lighthouse-core/gather/computed/critical-request-chains.js

@@ -47,6 +47,10 @@ class CriticalRequestChains extends ComputedArtifact {
      return false;
    }

+    if (request.statusCode === 0) {
+      return true;


treat blocked request as critical
currently, in a normal run, blocked resources must be critical in the previous run (otherwise it's not possible to block it via the UI). This prevents some resources which start with low priority but end up with high priority become non-critical after being blocked. So user will be able to see and configure them in current UI.
This is a temp solution and will probably be removed after I implemented the bottom bar.

weiwei-lin · 2017-01-12T02:14:06Z

lighthouse-core/gather/computed/critical-request-chains.js

@@ -67,7 +71,8 @@ class CriticalRequestChains extends ComputedArtifact {
        startTime: request.startTime,
        endTime: request.endTime,
        responseReceivedTime: request.responseReceivedTime,
-        transferSize: request.transferSize
+        transferSize: request.transferSize,
+        blocked: request.statusCode === 0


not sure if there is a better way to tell whether a request is blocked by dev-tool. I will use JavaScript to find all the blocked requests instead if necessary.

yup, there's a better way. Here's part of the networkRequest object from devtools: https://github.com/ChromeDevTools/devtools-frontend/blob/master/front_end/sdk/NetworkRequest.js#L404-L423

Thx for the link! Updated!

samuelli · 2017-01-12T02:18:32Z

lighthouse-cli/performance-experiment/report/injected-script.js

@@ -30,17 +30,39 @@ window.addEventListener('DOMContentLoaded', _ => {
  rerunButton.style.display = 'inline-block';

  rerunButton.addEventListener('click', () => {
-    rerunButton.setAttribute('status', 'running');
-    rerunLighthouse().then(() => {
+    rerunButton.setAttribute('data-status', 'running');


Not a fan of data-* since you're not really storing data. These represent state, so I think its fine to have it without the data-* prefix. If its simply for styling, just use a class instead.

rerunButton.classList.add('...')

samuelli · 2017-01-12T02:19:29Z

lighthouse-cli/performance-experiment/report/injected-script.js

-    rerunButton.setAttribute('status', 'running');
-    rerunLighthouse().then(() => {
+    rerunButton.setAttribute('data-status', 'running');
+    rerunLighthouse({blockedUrlPatterns: getUrlPatternsToBlock()}).then(() => {


urlPatternsToBlock() or maybe even blockedUrls().

changed to getUrlBlockingConfig() Because 'blocked' stands for URLs blocked in the previous run in the HTML.

samuelli · 2017-01-12T02:20:42Z

lighthouse-cli/performance-experiment/report/injected-script.js

      location.reload();
+    }).catch(err => {
+      rurunButton.setAttribute('data-status', 'stable');


nit: stable is a little odd to me, since this button will change, probably fine for now.

fixed. thanks for the suggestion

samuelli · 2017-01-12T02:25:59Z

lighthouse-cli/performance-experiment/report/injected-script.js

+  blockToggles.forEach(toggle => {
+    toggle.addEventListener('click', () => {
+      const requestNode = toggle.parentNode;
+      if (requestNode.getAttribute('data-to-block') === 'true') {


Let's just use a class here. This handler will then be
toggle.parentNode.classList.toggle('block-resource')

fixed. Instead of using data URL, changed to request_block (for URL to block in the next run) and request__blocked (for URL blocked in the previous run). thanks for the suggestion.

samuelli · 2017-01-12T02:26:28Z

lighthouse-cli/performance-experiment/report/injected-script.js

    });
  });
 });

+function getUrlPatternsToBlock() {
+  const requestNodes = document.querySelectorAll('.js-cnc-node[data-to-block=true]');


This will just become .js-cnc-node.block-resource

paulirish · 2017-01-12T03:38:40Z

Can you paste in a screenshot or two of the UI to the PR here?

weiwei-lin · 2017-01-12T04:03:43Z

Can you paste in a screenshot or two of the UI to the PR here?

Sure : )

When in --interactive mode, there will be a checkbox next to each critical resource.

Users can click the checkbox to block certain resources. The clicked one will show red x, which means this resource is actively blocked. The child resources of blocked resources will show black x, which means they are blocked because their parent is blocked.

If users choose to block some resources and hit rerun, in the new report page, blocked resources will be stroke out.

If users want to stop blocking this resource in the next run, they can uncheck the checkbox and hit rerun.

weiwei-lin · 2017-01-17T00:19:20Z

Added bottom config panel.
Screenshots:

Expanded:

The rerun button on the top fixed bar is removed since it's no longer needed.

brendankenny

I think using the critical request chain report for the blocked UI works really well, but I'm wondering if we can avoid making the critical request chain gatherer and audit part of the performance experiment by embedding logic and UI directly in it.

For instance, considering blocked resources as critical includes them in the CRC print out, but isn't necessarily valid for other LH users taking advantage of the blocked URLs option (e.g. if they want to try blocking some key XHR, all of which are currently treated as non-critical).

One approach that would still use all the work that's already been done in this PR would be to make the URL blocking its own audit, separate from the CRC one. It would actually be simpler than that audit, as it would just need to get artifacts.requestCriticalRequestChains and then append networkRecords.filter(req => req.blockedReason() === 'inspector') to it.

The formatter partial and all that could be from the existing CRC audit and the HTML/CSS changes you made in critical-request-chains.html here.

The main downside would be a duplication of critical request chains in the report and the critical request chains in the perfX UI. It should be fairly easy to suppress the output of the CRC audit, either from running at all or just hidden from display.

Just my initial thoughts! WDYT?

brendankenny · 2017-01-18T01:13:53Z

lighthouse-core/report/report-generator.js

@@ -195,10 +195,10 @@ class ReportGenerator {

  /**
   * Gets the CSS for the report.
-   * @return {string}
+   * @return {Array<string>} an array of CSS


@return {!Array<string>}

brendankenny · 2017-01-18T01:15:15Z

lighthouse-core/report/report-generator.js

   */
  getReportCSS() {
-    return fs.readFileSync(path.join(__dirname, './styles/report.css'), 'utf8');
+    return [fs.readFileSync(path.join(__dirname, './styles/report.css'), 'utf8')];


the isn't used to bring in more than one stylesheet, but was there a reason to make the change? I think it does make sense to move the perfX-specific styling to a separate file where possible

I changed this to make it more consistent with getReportJS.

brendankenny · 2017-01-18T01:19:23Z

lighthouse-core/report/styles/report.css

@@ -50,6 +50,8 @@ span, div, p, section, header, h1, h2, li, ul {
  --report-width: 1280px;
  --report-menu-width: 280px;
  --report-header-height: 58px;
+
+  --config-panel-header-height: 50px;


css once added is difficult to unwind after the fact, so re: above comment, I think a lot of this would be better living in a separate file explicitly for perfX UI, even if it introduces some redundancies.

We're also going to have to think about maintainability, as there are a few proposals about overhauling lighthouse scoring this quarter which will necessitate some level of report structure changes. No one else is really running the performance experiment yet, so we'll need to come up with a to make sure we don't break it.

(this and viewer make me increasingly want to set up a selenium check of the report in travis)

I moved the config panel HTML and related CSS into a partial. Some position related CSS code is still in the main CSS file (now in .report-body__fixed-body-container {...}) so the CSS in the partial does not need to use the variables declared in the main CSS file.
Thx for your advice.

brendankenny · 2017-01-18T01:21:14Z

lighthouse-core/report/templates/report-template.html

@@ -175,5 +174,27 @@ <h1 class="menu__header-title">Lighthouse</h1>
    <footer class="footer">
      Generated by <b>Lighthouse</b> {{lighthouseVersion}} on {{generatedTime}} | <a href="https://github.com/GoogleChrome/Lighthouse/issues" target="_blank">File an issue</a>
    </footer>
+
+    <div class="config-panel js-config-panel">


since this is nicely self contained, maybe we can move this into a partial, included conditionally on reportContext?

Fixed. Thanks for your advice : )

brendankenny · 2017-01-18T01:32:39Z

@ebidel since he's been thinking a lot about report unification and maintainability in the last few weeks

brendankenny · 2017-01-18T01:37:37Z

One approach that would still use all the work that's already been done in this PR would be to make the URL blocking its own audit, separate from the CRC one

It also may be that doing this as an audit (and included like a normal audit in the report) may be a bit of a hack and we're being blinded by the existing pipeline :)

It'd be easy to append a CRC + blocked resources audit to any config being run as --interactive but not included it in any aggregation, so it wouldn't be printed in the normal report. The UI you've written here could then be inserted into the report in the same way the configuration bar is.

weiwei-lin · 2017-01-18T05:30:52Z

For instance, considering blocked resources as critical includes them in the CRC print out, but isn't necessarily valid for other LH users taking advantage of the blocked URLs option (e.g. if they want to try blocking some key XHR, all of which are currently treated as non-critical).

That's a good point. I did't think of that.

One approach that would still use all the work that's already been done in this PR would be to make the URL blocking its own audit, separate from the CRC one.

I've considered this before. From my point of view, it does not really make sense to add it into audit, because it has nothing to do with the web page performance evaluation. And as you mentioned, we will end up with two almost identical trees in the report page.
What about adding this tree (maybe a complete network request tree) to config panel? We can increase the size of the config panel and add 2 tabs. One tab for text representation and input (just like what we have in config panel now) and the other one for graphical representation and input (just like the CRC with toggle buttons).

weiwei-lin

Moved most perf-x code to perf-x directory. Minimized the impact on other parts of lighthouse code base.
Moved configurable critical request chain to config tab, leaving the original critical request chain unchanged.
PTAL
Screenshots:

weiwei-lin · 2017-01-20T05:11:47Z

lighthouse-cli/performance-experiment/formatters/partials/config-panel.html

+}
+
+</style>
+


Reuse critical request chain with some small changes.
The original critical request chain is almost unchanged.

weiwei-lin · 2017-01-20T05:15:17Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+    });
+
+    // get and recover blocked URL patterns of current run
+    fetch('/blocked-url-patterns').then(response => {


temporary solution here. once lighthouse report includes runtime configuration, we probably can get the blockedUrlPatterns from there.

weiwei-lin · 2017-01-20T05:20:19Z

lighthouse-core/report/styles/report.css

@@ -389,6 +380,15 @@ body {
  width: calc(100vw - var(--report-menu-width));
 }



Container for bottom panel.
Config panel need some CSS variables here to calculate it's width. This container removes the dependency between config panel and the main CSS.

weiwei-lin · 2017-01-20T05:24:51Z

lighthouse-core/report/report-generator.js

-   * Generates the Lighthouse report HTML.
-   * @param {!Object} results Lighthouse results.
-   * @param {!string} reportContext What app is requesting the report (eg. devtools, extension)
-   * @return {string} HTML of the report page.


Actually not a big change here. Just moving formatters registration to it's own method. So I can inject another formatter by overriding this method.

brendankenny

sorry for the slow review! Looking good; I think we can move forward with this quite soon.

I think @ebidel is taking a look and will probably have some contradicting comments just to make this process more painful :)

brendankenny · 2017-01-23T23:53:41Z

lighthouse-cli/performance-experiment/formatters/config-panel.js

@@ -0,0 +1,37 @@
+/**
+ * @license
+ * Copyright 2016 Google Inc. All rights reserved.


brendankenny · 2017-01-23T23:54:32Z

lighthouse-cli/performance-experiment/formatters/partials/config-panel.html

+    });
+  });
+});
+</script>


brendankenny · 2017-01-23T23:59:25Z

lighthouse-core/formatters/partials/critical-request-chains.html

  line-height: 26px;
  white-space: nowrap;
+  display: block;


can you revert these last changes to this file now?

brendankenny · 2017-01-24T00:12:21Z

lighthouse-cli/performance-experiment/server.js

 function rerunRequestHandler(request, response) {
  let message = '';
  request.on('data', data => message += data);

  request.on('end', () => {
    const additionalFlags = JSON.parse(message);
-    const flags = Object.assign({}, lhParams.flags, additionalFlags);
+    const flags = Object.assign(lhParams.flags, additionalFlags);


is there a reason to modify lhParams?

Because report page currently needs to ask perf-x server which URL patterns are blocked. So I need to store the blocked URL patterns somewhere. Since in this PR we only store data for one report (including config, flags and results), I decided to directly store it with the flags (AFAIK there is no side effects). In the future PR (#1477), flags will be stored on hard drive (for each experiment) and re-parsed when we need them.

brendankenny · 2017-01-24T00:13:56Z

lighthouse-cli/performance-experiment/server.js

@@ -30,7 +30,7 @@ const http = require('http');
 const parse = require('url').parse;
 const opn = require('opn');
 const log = require('../../lighthouse-core/lib/log');
-const reportGenerator = new (require('./report/perf-x-report-generator'))();
+const ReportGenerator = require('./report/perf-x-report-generator');


nit: maybe call this PerfXReportGenerator just to more clearly call it out as an instance of the subclass?

brendankenny · 2017-01-24T00:14:16Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

@@ -0,0 +1,158 @@
+/**
+ * @license
+ * Copyright 2016 Google Inc. All rights reserved.


brendankenny · 2017-01-24T00:16:06Z

lighthouse-cli/performance-experiment/report/perf-x-report-generator.js

+
+  _registerFormatters(audits) {
+    super._registerFormatters(audits);
+    const configPanelTemplate = Handlebars.compile(ConfigPanelFormatter.getFormatter('html'));


since this is loading the partial differently than how it's done in _registerFormatters, would it be better to just load the partial file here instead of making ConfigPanelFormatter a Formatter?

fixed. thanks for the advice

brendankenny · 2017-01-24T00:16:25Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+/**
+ * @fileoverview Report script for Project Performance Experiment.
+ *
+ * Include functions for supporting interation between report page and Perf-X server.


s/interation/interaction

brendankenny · 2017-01-24T00:17:23Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+ * limitations under the License.
+ */
+
+/* global window, document, location, fetch */


since this file is only for running in the browser, would /* eslint-env browser */ work instead of declaring each?

brendankenny · 2017-01-24T00:19:07Z

lighthouse-cli/performance-experiment/formatters/partials/config-panel.html

+</div>
+
+<script>
+window.addEventListener('DOMContentLoaded', () => {


does this happen here instead of in perf-x.js for a reason?

Mainly because it's closely related to config panel and I consider it as part of the UI. But yeah, I can move this to perf-x.js.

ebidel · 2017-01-24T00:03:05Z

lighthouse-cli/performance-experiment/formatters/config-panel.js

@@ -0,0 +1,37 @@
+/**
+ * @license
+ * Copyright 2016 Google Inc. All rights reserved.


ebidel · 2017-01-24T00:03:19Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

@@ -0,0 +1,158 @@
+/**
+ * @license
+ * Copyright 2016 Google Inc. All rights reserved.


ebidel · 2017-01-24T00:06:40Z

lighthouse-cli/performance-experiment/formatters/partials/config-panel.html

+}
+
+.config-panel.expanded .config-panel__panel-toggle {
+  background-image: url('data:image/svg+xml;utf8,<svg fill="#000000" height="24" viewBox="0 0 24 24" width="24" xmlns="http://www.w3.org/2000/svg"><path d="M16.59 8.59L12 13.17 7.41 8.59 6 10l6 6 6-6z"/><path d="M0 0h24v24H0z" fill="none"/></svg>');


FF has issues parsing svg data urls with # in them. Can you use fill="black" for these colors?

ebidel · 2017-01-24T00:11:27Z

lighthouse-cli/performance-experiment/formatters/partials/config-panel.html

+</div>
+
+<script>
+window.addEventListener('DOMContentLoaded', () => {


I'm not sure we want to put script in a partial formatter. As of now, our partial have just been dumb render targets for data. This one is different in that it adds functionality. The script will also be injected every time the partial is included in the report. Presumably that's one time, but it would be good not to go that route :)

Is it possible to do this in your main perf-x.js script?

Mainly because it's closely related to config panel and I consider it as part of the UI. But yeah, I can move this to perf-x.js.

ebidel · 2017-01-24T00:14:25Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+  new ConfigPanel();
+});
+
+class ConfigPanel {


Define the class before the DOMContentLoaded.

ebidel · 2017-01-24T00:16:13Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+    bodyToggle.addEventListener('click', this._toggleBody.bind(this));
+
+    const rerunButton = this._configPanel.querySelector('.js-rerun-button');
+    rerunButton.addEventListener('click', this._rerunLighthouse.bind(this));


ebidel · 2017-01-24T00:18:11Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+      }
+    });
+    patternInput.addEventListener('keypress', event => {
+      (event.keyCode || event.which) === 13 && addButton.click();


this should be fine:

if (event.keyCode === 13) { addButton.click(); }

ebidel · 2017-01-24T00:20:40Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+
+    // init tree view buttons
+    const requestBlockToggles = this._configPanel.querySelectorAll('.js-request-blocking-toggle');
+    requestBlockToggles.forEach(toggle => {


Not sureNodeList.forEach has landed in stable yet (https://www.chromestatus.com/features/5691608351637504).

[...requestBlockToggles].forEach(... for good measure :)

Hmm. Is there any performance overhead for doing that? Because it seems like that converted nodeList to an array.
I changed it to Array.prototype.forEach.call(.... Not sure if this is better.

Yea [...requestBlockToggles] is creating an array from the NodeList. You could also do Array.from(requestBlockToggles). Both are more modern ways to Array.prototype.forEach.call. I would prefer the newer options over the latter. Perf will be negligible, esp since the list won't be that long.

Are the newer ones better because they are shorter? If that's the case, what about [].forEach.call?

ebidel · 2017-01-24T00:21:56Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+    fetch('/blocked-url-patterns').then(response => {
+      return response.text();
+    }).then(data => {
+      const blockedUrlPatterns = JSON.parse(data);


Why not parse the response as just? That would save you this JSON.parse call.

fetch('/blocked-url-patterns').then(response => response.json()).then(data => { ... });

fixed. thx for the advice

ebidel · 2017-01-24T00:22:10Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+    }).then(data => {
+      const blockedUrlPatterns = JSON.parse(data);
+      blockedUrlPatterns.forEach(urlPattern => this.addBlockedUrlPattern(urlPattern));
+      this.log('');


is this intentionally empty?

I see. This is for resetting an .innerHTML?

Yeah. It is.

ebidel · 2017-01-24T00:24:27Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+    });
+  }
+
+  addBlockedUrlPattern(urlPattern) {


please add docs for these methods

ebidel · 2017-01-24T00:27:27Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+    }).then(data => {
+      const blockedUrlPatterns = JSON.parse(data);
+      blockedUrlPatterns.forEach(urlPattern => this.addBlockedUrlPattern(urlPattern));
+      this.log('');


I see. This is for resetting an .innerHTML?

ebidel · 2017-01-24T00:30:44Z

Haha. Yea, sorry for the duplicate remarks. @brendankenny and I sit right by each other too... :)

weiwei-lin · 2017-01-24T02:28:48Z

Ready for review again. PTAL : )

ebidel · 2017-01-24T06:01:04Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+    // init tabs
+    const tabs = this._configPanel.querySelector('.js-tabs');
+    const tabNodes = tabs.querySelectorAll('.js-tab');
+    Array.prototype.forEach.call(tabNodes, tab => {


Rock ES6:
[...tabNodes].forEach(

ebidel · 2017-01-24T06:04:20Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

+    const tabNodes = tabs.querySelectorAll('.js-tab');
+    Array.prototype.forEach.call(tabNodes, tab => {
+      tab.addEventListener('click', () => {
+        Array.prototype.forEach.call(tabs.querySelectorAll('.is-active'), activeEle => {


Rock ES6:
[...tabs.querySelectorAll('.is-active')].forEach(

ebidel · 2017-01-24T06:10:10Z

lighthouse-cli/performance-experiment/report/scripts/perf-x.js

    });

    // init tree view buttons
    const requestBlockToggles = this._configPanel.querySelectorAll('.js-request-blocking-toggle');
-    requestBlockToggles.forEach(toggle => {
+    Array.prototype.forEach.call(requestBlockToggles, toggle => {


brendankenny

one small styling nit, but this is looking good

brendankenny · 2017-01-25T00:08:53Z

lighthouse-cli/performance-experiment/report/perf-x-report-generator.js

 const ReportGenerator = require('../../../lighthouse-core/report/report-generator');
+const configPanelPartial = fs.readFileSync(path.join(__dirname, 'partials/config-panel.html'),
+                                           'utf8');


prefer four space indent after line break rather than aligning

edit: fixed. thx for the advice

brendankenny · 2017-01-25T00:53:22Z

looks like you'll need to rebase because of #1505 as well, sorry

paulirish

i like this UI. very nice job. :)

brendankenny

☑️
☑️
☑️
LGTM!

weiwei-lin · 2017-01-25T01:20:07Z

Thanks!

weiwei-lin added 2 commits January 12, 2017 12:53

basic url blocking patterns toggle design

8a91594

fixed a conflict after rebase

044c647

weiwei-lin commented Jan 12, 2017

View reviewed changes

fixed some coding sytle

4224618

samuelli reviewed Jan 12, 2017

View reviewed changes

samuelli suggested changes Jan 12, 2017

View reviewed changes

fixed some coding style

f103c69

samuelli approved these changes Jan 12, 2017

View reviewed changes

weiwei-lin and others added 4 commits January 12, 2017 15:29

use more reliable way to check if request is blocked by users

2fcc4b0

Removed an unused css class

a375008

bottom panel prototype

8861d4f

removed some unecessary comments

fb75850

weiwei-lin force-pushed the configure-blocking-patterns branch from 4499c1d to fb75850 Compare January 15, 2017 09:52

removed an uncessary tab

fa805f0

added some padding to config panel body

73a08ac

weiwei-lin force-pushed the configure-blocking-patterns branch from 3f1ca05 to 73a08ac Compare January 17, 2017 04:04

brendankenny requested changes Jan 18, 2017

View reviewed changes

moved config panel code into a partial

f2c31e2

weiwei-lin force-pushed the configure-blocking-patterns branch from 83a75cc to f2c31e2 Compare January 18, 2017 05:11

weiwei-lin force-pushed the configure-blocking-patterns branch from aec2719 to f2c31e2 Compare January 18, 2017 06:17

WeiweiAtGit and others added 4 commits January 18, 2017 17:20

Merge branch 'master' into configure-blocking-patterns

8f0b04d

fixed some coding style

0f4c45b

exclude config panel in print view

afe20b3

move all the perf-x related code to perf-x folder

aeb915e

move configurable CRC to config panel

cc2bec6

weiwei-lin commented Jan 20, 2017

View reviewed changes

weiwei-lin mentioned this pull request Jan 23, 2017

Show runtime configuration on report #1485

Merged

brendankenny requested changes Jan 24, 2017

View reviewed changes

ebidel suggested changes Jan 24, 2017

View reviewed changes

brendankenny mentioned this pull request Jan 24, 2017

Add links to switch between different reports in left nav-bar #1477

Merged

ebidel reviewed Jan 24, 2017

View reviewed changes

fixed some coding style and added some documentations

f243b84

ebidel reviewed Jan 24, 2017

View reviewed changes

ebidel approved these changes Jan 24, 2017

View reviewed changes

fixed some coding style

1ee9d2a

brendankenny requested changes Jan 25, 2017

View reviewed changes

fixed indent

658a083

Merge branch 'master' into configure-blocking-patterns

462fb19

paulirish approved these changes Jan 25, 2017

View reviewed changes

brendankenny approved these changes Jan 25, 2017

View reviewed changes

brendankenny merged commit 3fa2156 into GoogleChrome:master Jan 25, 2017

weiwei-lin deleted the configure-blocking-patterns branch January 29, 2017 22:31

		@@ -389,6 +380,15 @@ body {
		width: calc(100vw - var(--report-menu-width));
		}

URL blocking patterns configuration UI #1455

URL blocking patterns configuration UI #1455

Conversation

weiwei-lin commented Jan 12, 2017 • edited Loading

weiwei-lin left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paulirish commented Jan 12, 2017

weiwei-lin commented Jan 12, 2017

weiwei-lin commented Jan 17, 2017 • edited Loading

brendankenny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

brendankenny commented Jan 18, 2017

brendankenny commented Jan 18, 2017

weiwei-lin commented Jan 18, 2017

weiwei-lin left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weiwei-lin Jan 20, 2017 • edited Loading

Choose a reason for hiding this comment

brendankenny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weiwei-lin commented Jan 12, 2017 •

edited

Loading

weiwei-lin left a comment •

edited

Loading

weiwei-lin commented Jan 17, 2017 •

edited

Loading

weiwei-lin left a comment •

edited

Loading

weiwei-lin Jan 20, 2017 •

edited

Loading

weiwei-lin Jan 24, 2017 •

edited

Loading

ebidel Jan 24, 2017 •

edited

Loading