Report v2: check/x boolean audits, expand details failing audits, optimal val #1963

ebidel · 2017-04-04T19:50:54Z

R: all

Before:

After:

Expands failing audits + expander arrows
Support for boolean audits with X/check
Renders optimalValue text on audit title. Final UI we'll need to work out.

ebidel · 2017-04-04T19:53:53Z

lighthouse-core/report/v2/report-renderer.js

+    const isAudit = 'result' in auditOrCategory;
+    const tagName = isAudit ? 'details' : 'div';
+
+    // Score template. Audits get a details dropdown. Categories don't.


if we wanted to, we could make the whole category collapsable. For now, I decide to keep it as v1.

patrickhulce · 2017-04-04T20:02:57Z

lighthouse-core/report/v2/report-renderer.js

    }
+
+    element.appendChild(
+        this._renderScore(audit.result.score, title, audit.result.helpText, audit));


why can't we stick to audit.score?

That doesn't have boolean information. Booleans come back score: 0 re score: 100. The UI needs to know if it should render a number score or a boolean pass/fail.

Yeah moved discussion to #1963 (comment) :)

patrickhulce · 2017-04-04T20:03:20Z

lighthouse-core/report/v2/report-renderer.js

@@ -31,6 +31,10 @@ const RATINGS = {
 * @return {string}
 */
 function calculateRating(value) {
+  if (typeof value === 'boolean') {


:( can we just keep that logic in the report generator?

patrickhulce · 2017-04-04T20:04:01Z

lighthouse-core/report/v2/report-renderer.js

+
+    // Score template. Audits get a details dropdown. Categories don't.
+    const tmpContainer = this._createElement('div');
+    tmpContainer.innerHTML = `<div class="lighthouse-score">


Don't be scared. Completely safe since we control all inputs for the initial set. Also, after spending time working on the report, this has proven to be infinitely nicer to work with.

patrickhulce · 2017-04-04T20:06:04Z

lighthouse-core/report/v2/report-renderer.js

@@ -98,19 +102,42 @@ window.ReportRenderer = class ReportRenderer {
   * @param {string} description
   * @return {!Element}
   */
-  _renderScore(score, title, description) {
-    const element = this._createElement('div', 'lighthouse-score');
+  _renderScore(score, title, description, auditOrCategory) {


the doctype lies! since we're shifting away from displaying high precision scores is this still necessary? what about a precision: binary|grade|numeric property or something for each audit and we can say goodbye to typeof

Score could also be an object with value/precision props. Or maybetype for the latter. Examples:

category.score = {value: 100, precision: 'numeric'} audit.score = {value: true, precision: 'binary'} audit.score = {value: 'A', precision: 'grade'}

can someone sum up what was decided? My thoughts:

audits are going to score in some fashion, whether that's 0-100, bucketed into grades, or pass/fail. Even if we require all audits to report a score as a number, it's still going to be an integer in that interval, buckets of every 10ish numbers, or 0/100. It makes some sense then for the audit to declare how it scored (perhaps on audit.meta), even if the reporter changes how the score is presented.

If on the other hand (or in addition to the above), we allow specifying the precision type in the config (on one of the audits in categories.categoryName.audits) it seems like we'd need some way of converting the score reported by the audit into the new format. binary -> numeric is easy, but (as discussed), what's the true/false cutoff for numeric -> binary and where do you specify it?

Here's my take on what was discussed

Immediate actions:

add a scorePrecision or similarly named property to the performance audits meta object specifying a numeric precision

add default scorePrecision of binary to the result in the base Audit class

update ReportRenderer to use the audit.result.scorePrecision combined with audit.score to decide how to display (no more typeof score === 'boolean' outside of ReportGenerator)

Potential future course of action that need further discussion:

We remove score from the audit result object and instead have them return values that are compared to the declared target/point of diminishing returns/median values and a score is generated for them, boolean audits return whether they pass or fail as they do today and a score of 100/0 is generated for them. We explore the possibility of introducing letter grades and changing the score curves.

add a scorePrecision or similarly named property to the performance audits meta object specifying a numeric precision

should be noted that is basically just giving expectedValue a new name :)

It will be nice to always have a numeric score, though.

if you mean renaming a property to align with it's meaning and changing the types of values it can hold then yes it's basically that :)

an enum is an enum :P

@patrickhulce do you want to craft those changes in a PR? I am working on some other stuff with <template> and can rebase when that lands.

@ebidel sure thing

ebidel · 2017-04-05T07:03:45Z

lighthouse-core/report/v2/report-renderer.js

+   */
+  _renderScore(score, title, description, auditOrCategory) {
+    const isAudit = 'result' in auditOrCategory;
+    const precision = isAudit ? 'binary' : 'category'; // TODO(ericbidelman): placeholder


fyi @patrickhulce

ebidel · 2017-04-05T18:30:33Z

Removed .innerHTML!

It's been replaced by templates.html which includes declared html partials (using <template>). It will also be the future home for ported handlebars formatters and other UI scaffolding. Templates get added to report-template.html using our injection technique. It's unclear how devtools will bring in templates.html.

This PR also introduces a DOM class to organize DOM-related code. It includes wrapper methods for setting .textContent and .classList so we never run into errors with querySelector'd returning null. Plan to add some renderer tests.

The typeof === 'boolean' stuff is also removed. I've preemptively hardcoded precision placeholders for audit and cateogry scores. For now, _renderAuditScore and _renderCategoryScore construct an object: score = {value: audit.score, precision: 'numeric'}. The expectation is that report-generator.js will setup this object when it creates results and we can remove those lines.

PTAL.

…imal val

- rename good/poor -> pass/fail - organize DOM related code - placeholders for score precision

ebidel · 2017-04-05T22:33:03Z

Now with scoringMode. PTAL

paulirish · 2017-04-06T00:19:18Z

lighthouse-core/report/v2/report-renderer.js

-    column.appendChild(
-      this._createElement('div', 'lighthouse-score__description')).textContent = description;
+    // Fill in the blanks.
+    const value = tmpl.querySelector('.lighthouse-score__value');


s/value/elem/

when for valueEl so disambiguate.

ebidel · 2017-04-06T01:02:20Z

Added tests. I'm done.

paulirish

there's stuff i could bikeshed.. like the DOM library API and how the templates are added to the page. But on the whole I'm happy here. Let's keep it moving.

brendankenny

some things

brendankenny · 2017-04-06T01:26:33Z

docs/hacking-tips.md

+
+```sh
+npm run start -- --output=json --output-path=lighthouse-core/test/results/sample_v2.json http://localhost:8080/dobetterweb/dbw_tester.html
+```


should we add something about consider deleting any irrelevant changes from the diff, like exact timings, etc?

brendankenny · 2017-04-06T01:26:49Z

docs/hacking-tips.md

 ## Iterating on the v2 report

-This'll generate new reports from the same results json.
+This will generate new reports from the same results json.


brendankenny · 2017-04-06T01:28:44Z

lighthouse-core/report/v2/report-generator.js

@@ -23,6 +23,7 @@ const REPORT_TEMPLATE = fs.readFileSync(path.join(__dirname, './report-template.
 // TODO: Setup a gulp pipeline to concat and minify the renderer files?
 const REPORT_JAVASCRIPT = fs.readFileSync(path.join(__dirname, './report-renderer.js'), 'utf8');
 const REPORT_CSS = fs.readFileSync(path.join(__dirname, './report-styles.css'), 'utf8');
+const REPORT_TEMPLATES = fs.readFileSync(path.join(__dirname, './templates.html'), 'utf8');


want to clean up our paths here while you're at this? :D fs.readFileSync(__dirname + '/templates.html'), 'utf8') works just fine

does that work just fine on windows?

does that work just fine on windows?

Yeah, Windows understands / and the fs methods will take care of the rest. The only real worry (that I know of) is if you want to specify an absolute path from the root, which is different cross platform, but we're using __dirname so it's not an issue here

brendankenny · 2017-04-06T01:34:07Z

lighthouse-core/report/v2/report-generator.js

@@ -97,11 +98,14 @@ class ReportGeneratorV2 {
  generateReportHtml(reportAsJson) {
    const sanitizedJson = JSON.stringify(reportAsJson).replace(/</g, '\\u003c');
    const sanitizedJavascript = REPORT_JAVASCRIPT.replace(/<\//g, '\\u003c/');
+    // Remove script in templates files just to be safe.
+    const sanitizedTemplates = REPORT_TEMPLATES.replace(/<script>([\s\S]*?)<\/script>/g, '');


I'm not sure how much we should emphasize this; it doesn't strip event handlers, for instance. It's all our own markup, so I vote for not worrying about sanitization of the templates (we don't sanitize report-template.html so why should we do that with these? :)

I agree with you. I recall that el.innerHTML = '<div>just a string</div>'; was deemed unsafe and that's our own markup :) The argument from someonnnnne was that we may add things later and not realize the mistakes.

I think this is different enough, though, because it's not markup assembled in (potentially) multiple places, it's all in one spot. So I think it's better on that front. I also don't like calling it sanitized unless it is actually sanitized :)

really think we should remove this, or call it "templatesWithScriptTagsRemoves" or something. Current version is easily worked around with an attribute on the script tag...I don't think this is an arms race we want to even start.

brendankenny · 2017-04-06T01:35:10Z

lighthouse-core/report/v2/report-renderer.js

 /* eslint-env browser */
 /* eslint indent: [2, 2, { "SwitchCase": 1, "outerIIFEBody": 0 }] */

-(function() {
+(function(self) {


IIFE is still pointless :P

brendankenny · 2017-04-06T02:17:37Z

lighthouse-core/test/report/v2/report-renderer-test.js

+    });
+
+    it('does not fail when given null element argument', () => {
+      assert.doesNotThrow(() => {


can drop the surrounding assert.doesNotThrow and just execute it. If it throws the test will fail

I kind of like being explicit.

brendankenny · 2017-04-06T02:19:58Z

lighthouse-core/test/report/v2/report-renderer-test.js

+    });
+
+    it('does not fail when given null element argument', () => {
+      assert.doesNotThrow(() => {


don't need doesNotThrow wrapper

brendankenny · 2017-04-06T02:21:11Z

lighthouse-core/test/report/v2/report-renderer-test.js

+    it('fails when template cannot be found', () => {
+      const dom = new DOM(document);
+      assert.throws(() => {
+        const clone = dom.cloneTemplate('#unknown-selector'); // eslint-disable-line no-unused-vars


can you just not assign to a var to lose the eslint directive?

so sloppy...but done!

brendankenny · 2017-04-06T02:22:18Z

lighthouse-core/test/report/v2/report-renderer-test.js

+});
+
+describe('ReportRenderer V2', () => {
+  const window = self;


isn't the global window already set to self? Or...something? The globals are confusing here (and only used to access ReportRenderer)

brendankenny · 2017-04-06T02:26:56Z

lighthouse-core/test/report/v2/report-renderer-test.js

+
+    it('should render an exception for invalid input', () => {
+      const renderer = new ReportRenderer(document);
+      const output = renderer.renderReport({});


Since we're not really validating anything right now this relies on implementation details. What about something explicit like

const output = renderer.renderReport({ get reportCategories() { throw new Error() } });

brendankenny · 2017-04-06T02:29:54Z

there's stuff i could bikeshed.. like the DOM library API and how the templates are added to the page. But on the whole I'm happy here. Let's keep it moving.

If it really is just bikeshedding stuff that's fine, but this is the kind of thing that gets written once and we're stuck with from then on unless it bothers you so much in the future you file a bug/change it.

Now's the time to bring it up, even if we get to it in a followup :)

brendankenny · 2017-04-06T02:35:50Z

lighthouse-core/report/v2/report-renderer.js

- * Dummy text for ensuring report robustness: </script> pre$`post %%LIGHTHOUSE_JSON%%
- */
-window.ReportRenderer = class ReportRenderer {
+class DOM {


feels like something I know ahead of time you're going to disagree with me on :) but I don't personally see the need for a separate DOM class (yet, at least), especially because the split with ReportRenderer doesn't seem completely clear. Anything wrong with these living there?

I knew you were going to bring this up! I wasn't convinced adding a bunch of generic methods to ReportRenderer made sense either. They could live as standalone helper functions, but devtools may need to extend them later.

ebidel · 2017-04-06T21:02:29Z

PTAL. I think I got everything.

brendankenny · 2017-04-06T22:56:19Z

lighthouse-core/report/v2/report-renderer.js

+
+    // Append audit details to to header section so the entire audit is within one <details>.
+    const header = element.querySelector('.lighthouse-score__header');
+    if (header) {


in what cases might there not be a header?

it was meant to protect against null querySelector results like methods. But removed since we don't care about that anymore.

brendankenny · 2017-04-06T22:57:24Z

lighthouse-core/report/v2/report-renderer.js

+
+// Exports
+window.ReportRenderer = ReportRenderer;
+window.DOM = DOM;


not needed anymore since you removed the IIFE?

Mocha needs it, but I've switched to proper module exports for Node env.

brendankenny · 2017-04-06T22:59:39Z

lighthouse-core/report/v2/report-renderer.js

+   * @param {!CategoryJSON} category
+   * @return {!Element}
+   */
+  _renderCategoryScore(category) {


should these also be _renderAuditResult and _renderCategoryResult?

I'm actually going to change "_populateResult" back to _populateScore. It's populating the score dom with values.

I'm actually going to change _populateResult back to _populateScore. It's populating the score dom with values

my issue was that if someone was going into the codebase to see where audits' titles and descriptions are set, they probably wouldn't think it would be in _populateScore. If the issue is the template's id, that can change too :P

This is all going to change a lot in the near future, so if you feel strongly we can defer

brendankenny · 2017-04-06T23:03:02Z

lighthouse-core/report/v2/report-renderer.js

+  _renderAuditScore(audit) {
+    const tmpl = this._dom.cloneTemplate('#tmpl-lighthouse-audit-score');
+
+    const scoringMode = audit.result.scoringMode;


How we've gotten here has made sense, but it is weird that scoringMode is on audit.result but the score is on audit directly

brendankenny · 2017-04-06T23:03:49Z

lighthouse-core/report/v2/report-renderer.js

+  }
+
+  /**
+   * @param {!DocumentFragment|Element} element DOM node to populate with values.


this is only ever called with a DocumentFragment, though

yep, but it support both

brendankenny · 2017-04-06T23:07:53Z

lighthouse-core/report/v2/report-generator.js

@@ -97,11 +98,14 @@ class ReportGeneratorV2 {
  generateReportHtml(reportAsJson) {
    const sanitizedJson = JSON.stringify(reportAsJson).replace(/</g, '\\u003c');
    const sanitizedJavascript = REPORT_JAVASCRIPT.replace(/<\//g, '\\u003c/');
+    // Remove script in templates files just to be safe.
+    const sanitizedTemplates = REPORT_TEMPLATES.replace(/<script>([\s\S]*?)<\/script>/g, '');


really think we should remove this, or call it "templatesWithScriptTagsRemoves" or something. Current version is easily worked around with an attribute on the script tag...I don't think this is an arms race we want to even start.

brendankenny · 2017-04-06T23:09:22Z

lighthouse-core/report/v2/report-renderer.js

  AVERAGE: {label: 'average', minScore: 45},
-  POOR: {label: 'poor'}
+  FAIL: {label: 'fail'}


does PASS/FAIL work here? Seems weird to have a three state pass/fail system :)

Not really a pass/fail system. Just for labeling/coloring right now. We'll probably need to expand in the future if we support things like grades. Seems fine for now.

Not really a pass/fail system. Just for labeling/coloring right now.

yeah, I was mostly just commenting on the names since PASS/FAIL is usually a binary state. Fine for now

brendankenny · 2017-04-06T23:10:08Z

lighthouse-core/report/v2/report-renderer.js

-    } catch (e) {
-      return this._renderException(e);
+  static setText(element, text) {
+    if (element) {


still think we should remove. Earlier (and non-silent) failures are better failures.

brendankenny

last things

brendankenny · 2017-04-07T22:15:51Z

lighthouse-core/report/v2/report-renderer.js

  AVERAGE: {label: 'average', minScore: 45},
-  POOR: {label: 'poor'}
+  FAIL: {label: 'fail'}


Not really a pass/fail system. Just for labeling/coloring right now.

yeah, I was mostly just commenting on the names since PASS/FAIL is usually a binary state. Fine for now

brendankenny · 2017-04-07T22:17:05Z

lighthouse-core/report/v2/report-renderer.js

+  }
+
+  /**
+   * @param {!DocumentFragment|Element} element DOM node to populate with values.


{!DocumentFragment|!Element} then

brendankenny · 2017-04-07T22:24:33Z

lighthouse-core/report/v2/report-renderer.js

+   * @param {!CategoryJSON} category
+   * @return {!Element}
+   */
+  _renderCategoryScore(category) {


I'm actually going to change _populateResult back to _populateScore. It's populating the score dom with values

my issue was that if someone was going into the codebase to see where audits' titles and descriptions are set, they probably wouldn't think it would be in _populateScore. If the issue is the template's id, that can change too :P

This is all going to change a lot in the near future, so if you feel strongly we can defer

brendankenny · 2017-04-07T22:26:03Z

lighthouse-core/report/v2/report-renderer.js

+    element.appendChild(this._renderAuditScore(audit));
+
+    // Append audit details to to header section so the entire audit is within one <details>.
+    const header = element.querySelector('.lighthouse-score__header');


since this depends on markup introduced by _renderAuditScore, move header/details stuff in there?

brendankenny · 2017-04-07T22:28:49Z

lighthouse-core/report/v2/templates.html

+      <div class="lighthouse-score__snippet">
+        <span class="lighthouse-score__title"><!-- fill me --></span>
+      </div>
+      <div class="lighthouse-score__description"><!-- fill me --></div>


worth putting in a comment(s) to show where audits (and details for the below template) will go?

I like the idea, but right now it's not worth it. Things are going to move around as we iterate. Don't want comments to get out of whack.

I like the idea, but right now it's not worth it. Things are going to move around as we iterate. Don't want comments to get out of whack.

you say that now, but we'll have to see if anyone remembers later on :)

brendankenny · 2017-04-07T22:31:35Z

lighthouse-core/test/report/v2/report-generator-test.js

+      const page = jsdom.jsdom(new ReportGeneratorV2().generateReportHtml({}));
+      const templates = jsdom.jsdom(TEMPLATES_FILE);
+
+      assert.deepEqual(page.querySelectorAll('template[id^="tmpl-"]'),


deepStrictEqual? Deep equality checking also gets weird with e.g. empty objects and properties on prototypes (it doesn't check them), so it may be worth doing an explicit comparison with the expected elements

ebidel · 2017-04-07T22:52:47Z

PTAL

brendankenny · 2017-04-07T23:24:33Z

lighthouse-core/test/report/v2/report-generator-test.js

+      const page = jsdom.jsdom(new ReportGeneratorV2().generateReportHtml({}));
+      const templates = jsdom.jsdom(TEMPLATES_FILE);
+
+      assert.deepStrictEqual(page.querySelectorAll('template[id^="tmpl-"]'),


just checked, assert.deepStrictEqual also doesn't work here (besides checking that there's the same number of templates) because Object.keys() on the two HTMLTemplateElements returns [], so any two HTMLTemplateElements are considered deep equal. You'll probably need to manually check the innerHTMLs are equal or something

could do something like

const page = jsdom.jsdom(new ReportGeneratorV2().generateReportHtml({})); const templates = jsdom.jsdom(TEMPLATES_FILE); const pageTemplates = page.querySelectorAll('template[id^="tmpl-"]'); const rawTemplates = templates.querySelectorAll('template[id^="tmpl-"]'); rawTemplates.forEach((expectedTemplate, index) => { assert.strictEqual(pageTemplates[index].innerHTML, expectedTemplate.innerHTML); });

switched to using lengths.

switched to using lengths

lulz, well the assert.deepEqual was checking that, but I guess at least now it's explicit

brendankenny

LGTM 🏗☑️

ebidel added the v2report label Apr 4, 2017

ebidel commented Apr 4, 2017

View reviewed changes

patrickhulce reviewed Apr 4, 2017

View reviewed changes

ebidel commented Apr 5, 2017

View reviewed changes

ebidel force-pushed the reportv2-more branch 2 times, most recently from 1b3504c to f4e5842 Compare April 5, 2017 18:11

ebidel added 3 commits April 5, 2017 15:25

Report v2: check/x boolean audits, expand details failing audits, opt…

4368d0d

…imal val

Generate DOM from <template>. Add templates.html.

e82eabc

- rename good/poor -> pass/fail - organize DOM related code - placeholders for score precision

Use scoreMode

1d04b26

ebidel force-pushed the reportv2-more branch from f4e5842 to 1d04b26 Compare April 5, 2017 22:31

paulirish reviewed Apr 6, 2017

View reviewed changes

Add tests and use correct renderScore method in renderCategory

72598c9

Turn travis green. Node doesnt have "self" defined

0550aec

paulirish approved these changes Apr 6, 2017

View reviewed changes

brendankenny requested changes Apr 6, 2017

View reviewed changes

brendankenny reviewed Apr 6, 2017

View reviewed changes

ebidel added 2 commits April 6, 2017 11:05

Feedback

ed21330

Test feedback

e01d13e

brendankenny requested changes Apr 6, 2017

View reviewed changes

Remove DOM class, update tests

2abfebc

ebidel mentioned this pull request Apr 7, 2017

Generate DOM for markdown links in help text #1979

Merged

brendankenny requested changes Apr 7, 2017

View reviewed changes

mmoooooar comments

25921d1

brendankenny reviewed Apr 7, 2017

View reviewed changes

tests

468aaa9

brendankenny approved these changes Apr 7, 2017

View reviewed changes

brendankenny merged commit 0b9f960 into master Apr 7, 2017

brendankenny deleted the reportv2-more branch April 7, 2017 23:55

paulirish mentioned this pull request Apr 17, 2024

refactor: split report-renderer into multiple files #1987

Merged

Report v2: check/x boolean audits, expand details failing audits, optimal val #1963

Report v2: check/x boolean audits, expand details failing audits, optimal val #1963

Conversation

ebidel commented Apr 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ebidel Apr 4, 2017 • 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

ebidel Apr 4, 2017 • 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

patrickhulce Apr 4, 2017 • 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

ebidel commented Apr 5, 2017

ebidel commented Apr 5, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ebidel commented Apr 6, 2017

paulirish left a comment

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

ebidel Apr 6, 2017 • 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

brendankenny commented Apr 6, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ebidel commented Apr 6, 2017

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

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

ebidel commented Apr 4, 2017 •

edited

Loading

ebidel Apr 4, 2017 •

edited

Loading

ebidel Apr 4, 2017 •

edited

Loading

patrickhulce Apr 4, 2017 •

edited

Loading

ebidel Apr 6, 2017 •

edited

Loading