Implement form verification (async form validation) by cvializ · Pull Request #9054 · ampproject/amphtml

cvializ · 2017-04-29T01:02:43Z

Needs documentation, opening this PR for feedback.

jridgewell · 2017-05-01T20:46:04Z

examples/form/zipcodes.csv

@@ -0,0 +1,4431 @@
+RecordNumber,Zipcode,City,State


What is alllllllllllllllll of this needed for?

The original title of the issue was forms: zip code input validation, but it was changed. I thought reading through real California zip codes and cities would be an interesting demo. If you think it's too heavy weight we can just change it to a smaller dict.

It's massive.

jridgewell · 2017-05-01T21:19:31Z

extensions/amp-form/0.1/form-verifiers.js

+ * @return {?Element}
+ */
+function getConfig_(form) {
+  return form.getElementsByTagName('script')[0];


This is finds deep elements. Should this be looking for a child script instead?

jridgewell · 2017-05-01T21:20:26Z

extensions/amp-form/0.1/form-verifiers.js

+    });
+    const config = json && json[CONFIG_KEY];
+    if (!config.length) {
+      throw new Error(`The amp-form verification config should contain an array


Are there any future uses for this configuration script? Maybe we shouldn't be throwing an error if they don't specify a verification group?

See #getFormVerifier. #parseConfig_ is not called if a verification group is not specified.

jridgewell · 2017-05-01T21:21:03Z

extensions/amp-form/0.1/form-verifiers.js

+      throw new Error('Failed to parse amp-form config. Is it valid JSON?');
+    });
+    const config = json && json[CONFIG_KEY];
+    if (!config.length) {


This will throw for an empty JSON object.

Isn't that correct behavior? If the publisher specifies {"verificationGroups": []} or {} in a form config, it seems like it is a mistake they should be made aware of through an error. Let me know if you'd prefer to allow an empty config.

It's fine for this to be an error, but it this line causes an error. As in, the test, not the error we throw on the line below.

jridgewell · 2017-05-01T22:10:31Z

extensions/amp-form/0.1/form-verifiers.js

+   * Clear the validity state of this group's elements.
+   */
+  clearErrors() {
+    this.elements_.forEach(element => element.setCustomValidity(''));


Are all elements guaranteed to have #setCustomValidity?

The HTML Constraints spec specifies that submittable elements are guaranteed to have #setCustomValidity. A publisher would have to put a non-submittable element in a verification group for this to throw, and it seems unlikely. I could check that every element in the group has a #setCustomValidity method in #parseConfig, let me know if you think that's a good idea.

Yah, I would just limit them to the form input elements.

Done. See #isSubmittable_

jridgewell · 2017-05-01T22:11:38Z

extensions/amp-form/0.1/form-verifiers.js

+export class FormVerifier {
+  /**
+   * @param {!HTMLFormElement} form
+   * @param {!Array<!VerificationGroup>} config


Nit: rename to groups

jridgewell · 2017-05-01T22:14:16Z

extensions/amp-form/0.1/form-verifiers.js

+    // Set the error message on each element that caused an error.
+    for (let i = 0; i < errors.length; i++) {
+      const error = errors[i];
+      const element = scopedQuerySelector(this.form_, `[name="${error.name}"]`);


Scoped query selector is unnecessary in this case.

I got an error in the presubmit on Travis telling me not to this.form_.querySelector because of strange behavior. Why is it unnecessary in this case?
If you mean use document.querySelector, multiple elements can have identical names so it could select the wrong element.

scopedQuerySelector is only necessary when there is a space in the selector (really, when you're matching a descendent of a descendent, see #7260). In this case, you're only matching a single descendent, so no issues.

I see. We may want to update the message querySelectorAll produces during the travis presubmit or a comment in the jsdoc for scopedQuerySelector to make that clearer. Thanks!

jridgewell · 2017-05-01T22:15:45Z

extensions/amp-form/0.1/form-verifiers.js

+    // Remove the dirty flag from the successful groups that have values.
+    for (let i = 0; i < this.groups_.length; i++) {
+      const group = this.groups_[i];
+      if (group.isFilledOut() && group.containsNoElementOf(errorElements)) {


Use #shouldVerify instead.

This statement and the function of #shouldVerify are not equivalent. Could you please explain why?

This method is #verify, which means we're only verifying the elements that #shouldVerify returned true for.

jridgewell · 2017-05-01T22:16:12Z

extensions/amp-form/0.1/form-verifiers.js

+   * @param {!Array<!Element>} elements
+   * @return {boolean}
+   */
+  containsNoElementOf(elements) {


Nit: rename to #containsNone

jridgewell · 2017-05-01T22:19:05Z

extensions/amp-form/0.1/form-verifiers.js

+   */
+  maybeVerify_(afterVerify) {
+    if (this.shouldVerify_()) {
+      this.doXhr_().then(() => {


We're gonna get into a LOT of race conditions here. Need to verify that this is a response to the last issued XHR, not any before it.

aghassemi

first round of comments for the first half.

aghassemi · 2017-05-02T20:37:59Z

examples/forms.amp.html

            color: #dc4e41;
        }

+        .verification-form label {


/cc @spacedino let's work with Abby on UI design of this

This is just for the example page we use for development, right? It isn't baked in to amp-form. The publisher should be responsible for the spinner UX

less so for this example page and more so to kick of the design for AmpByExample and/or AMP Start.

aghassemi · 2017-05-02T20:53:54Z

examples/forms.amp.html

+        },
+        {
+          "name": "fullAddress",
+          "elements": ["[name='addressLine2']", "[name='city']", "[name='zip']"]


let's restrict this to just name (considering error response has name which is used to find the target elements later)

maybe: "fields" = ['addressLine2', 'city', 'zip'].

aghassemi · 2017-05-02T22:55:08Z

extensions/amp-form/0.1/amp-form.js

+      checkUserValidityAfterInteraction_(dev().assertElement(e.target));
      this.validator_.onBlur(e);
    }, true);
+    this.form_.addEventListener('change', e => {


should this be guarded by custom-validation-reporting='as-you-go?

Nope, "as-you-go" is sort of poorly named. It should be called something that implies "use your own error message elements instead of using Chrome's validation tooltip, AND do so as the user fills out fields". The change listener is still necessary when using verification with Chrome's default validation UI.

wow ok. so what is the default browser UI strategy? is it always "on-submit" and not changeable?

That's right, unless you call form.reportValidation, which by default happens on submit.

aghassemi · 2017-05-02T22:57:49Z

extensions/amp-form/0.1/amp-form.js

+    }
+  }
+
+  getVarSubsFields_() {


jsdoc for this a few other private methods added

aghassemi · 2017-05-02T23:05:00Z

extensions/amp-form/0.1/amp-form.js

+
+    this.setState_(FormState_.VERIFYING);
+    const verifyXhr = this.doVarSubs_(this.getVarSubsFields_()).then(
+        () => this.doXhr_(map({verify: true})));


'verify' can collide with existing inputs named verify. Do __amp_form_verify and then check if any input has that name same way SOURCE_ORIGIN_PARAM is checked in the constructor of AMP form.

aghassemi · 2017-05-02T23:09:14Z

extensions/amp-form/0.1/form-verifiers.js

+function parseConfig_(script) {
+  if (isJsonScriptTag(script)) {
+    const json = tryParseJson(script.textContent, () => {
+      throw new Error('Failed to parse amp-form config. Is it valid JSON?');


throw user().createError() here and couple of places below.

aghassemi · 2017-05-02T23:12:42Z

extensions/amp-form/0.1/form-verifiers.js

+ * data in ways not possible with standard form validation, or check
+ * values against sets of data too large to fit in browser memory
+ * e.g. ensuring zip codes match with cities.
+ * @visibleForTesting


jridgewell · 2017-05-02T23:22:36Z

extensions/amp-form/0.1/amp-form.js

+
+    this.setState_(FormState_.VERIFYING);
+    const verifyXhr = this.doVarSubs_(this.getVarSubsFields_()).then(
+        () => this.doXhr_(map({verify: true})));


Is the map necessary?

Probably not. Could you help me understand what use-cases require our map utility function?

I thought it was to make for-in loops more robust. I iterate over this object using a for-in loop in #doXhr

It has an old JS meaning and a valid CS meaning.

Old JS, people used to put enumerable properties on the Object.prototype object, which would then magically appear in all for-in loops. We don't do that. Actually we did, but Ali fixed that.

The CS meaning is when the object is treated as a true Map instance with arbitrary accesses. In that case, anything in the prototype chain could be accessed, which is incorrect in 99% of cases.

I see, map is more for storing and accessing values, and we don't need it here because it's just a descriptive value and not used for storage.

jridgewell · 2017-05-02T23:23:08Z

extensions/amp-form/0.1/amp-form.js

-    const isHeadOrGet = this.method_ == 'GET' || this.method_ == 'HEAD';
+
+    const p = this.doVarSubs_(varSubsFields)
+    .then(() => {


Whitespace.

jridgewell · 2017-05-02T23:23:34Z

extensions/amp-form/0.1/amp-form.js

+      return;
+    }
+
+    this.setState_(FormState_.VERIFYING);


Are we going to do any blocking in this state?

Like blocking of the submit button? No, that is not planned. This state is intended to allow a spinner to show during the verify request. If the user wants to submit while the verify request is pending, they should be able to.

aghassemi

Second round.
Excellent PR overall Carlos!

aghassemi · 2017-05-04T16:33:43Z

extensions/amp-form/0.1/amp-form.js

      this.validator_.onBlur(e);
    }, true);
+    this.form_.addEventListener('change', e => {
+      const input = dev().assertElement(e.target);


let's create an experiment (maybe amp-form-verifier?) and guard entry points to this. Ideally being sure when experiment is off, code paths to existing forms functionality does not change (much).

aghassemi · 2017-05-04T16:37:40Z

extensions/amp-form/0.1/amp-form.js

+
+    const verifyXhr = this.doVarSubs_(this.getVarSubsFields_())
+        .then(() => this.doXhr_({[FORM_VERIFY_PARAM]: true}));
+    const reset = () => this.setState_(FormState_.INITIAL);


what if multiple are still running and one fails while others are still running? we don't want to lose VERIFYING state.

Good catch, I'll move this to the afterVerify callback

aghassemi · 2017-05-04T16:42:34Z

extensions/amp-form/0.1/form-verifiers.js

+    // Set the error message on each element that caused an error.
+    for (let i = 0; i < errors.length; i++) {
+      const error = errors[i];
+      const element = this.form_./*OK*/querySelector(`[name="${error.name}"]`);


scopedQuerySelector(this.form_, [name="${error.name}"]) from dom.js

@jridgewell and I discussed this above, and he shared that scopedQuerySelector is not necessary unless there is a space in the selector. Is that your understanding as well?

My understanding is that scopedQuerySelector(parent) can match the parent element itself but parent.querySelector can never match parent. so in that sense yeah no need to use scopedQuerySelector.

With my comment I was hoping to get rid of /*OK*/ as they should be used for exceptions not common cases, looks like querySelector is allowed without `/OK/ anyway.

Neither can match the parent. The issue is #querySelector is scoped to the document, then filtered to elements inside the parent (div span can match a <div> outside parent and then a <span> inside parent). scopedQuerySelector however, is scoped to the parent only (div span can only match a <div> inside parent and a <span> inside that <div>).

#querySelector is allowed when there is a single string without any spaces (meaning, you can not have '* *'). Because this is a template string, it could do all kinds of weird things. But we know better than the linter in this case.

@jridgewell wow good to know (I probably should have known this but never too late to learn :) ). Good job preventing this with presubmit rules.

aghassemi · 2017-05-04T16:44:16Z

extensions/amp-form/0.1/form-verifiers.js

+      const error = errors[i];
+      const element = this.form_./*OK*/querySelector(`[name="${error.name}"]`);
+      if (element && element.checkValidity()) {
+        element.setCustomValidity(error.message);


I guess if multiple elements have the same name (common with radio buttons) the first one gets it which is fine, let's just document here as a comment.

Good idea. I checked how the existing validator behaves when a radio button value is required and none is checked and this matches that.

aghassemi · 2017-05-04T16:59:54Z

src/service/xhr-impl.js

+    const status = response.status;
+    if (status < 200 || status >= 300) {
+      const retriable = isRetriable(status);
+      const err = user().createCustomError(


we should not log the full response (since we store logs and response body can contain sensitive info)

The only thing sent in the error report is the message first argument. The other information is just tacked on to the error object and not sent, so the full response won't be logged.
Also, createError doesn't report errors so this error isn't logged anyway.

well, createError don't report but whoever is catching .fetch() error may report it. (or we might be reporting all unhandledrejection error, @jridgewell do we report unhandledrejection?)

You are right that response does got get reported right now because it is just a field on FetchError, but do we need it? I like dump error objects that one can't do anything but log them instead of error objects that can be inspected and used to switch code path. (e.g. not a fan of .catch(err => if( err.response.code == 500) {...} )

Removing the property from the error would involve slightly more refactoring effort. The code was already augmenting the error with the response and responseJson properties, just not doing so with a custom error class.

#7585

We do log all unhandledrejections.

aghassemi · 2017-05-04T17:01:16Z

src/utils/promise.js

+/**
+ * Resolves with the result of the last promise added.
+ */
+export class LastAddedResolver {


aghassemi · 2017-05-04T17:02:34Z

src/utils/promise.js

+    this.count_ = 0;
+
+    if (opt_promises) {
+      for (let i = 0; i > opt_promises.length; i++) {


please add a test that would catch the bug in this line.

Ah that's a pretty goofy mistake I made. Adding the test.

jridgewell · 2017-05-03T23:27:37Z

extensions/amp-form/0.1/amp-form.js

-          inputs[i].name != SOURCE_ORIGIN_PARAM,
-          'Illegal input name, %s found: %s', SOURCE_ORIGIN_PARAM, inputs[i]);
+      const name = inputs[i].name;
+      user().assert(!name ||


First check is unnecessary.

jridgewell · 2017-05-03T23:28:19Z

extensions/amp-form/0.1/amp-form.js

+        updatedElements.forEach(updatedElement => {
+          checkUserValidityAfterInteraction_(updatedElement);
+        });
+        this.validator_.onBlur(e);


Why are we blurring here?

This function's name is not very clear. It's part of the amp-form FormValidator API and it hides any displayed messages. Originally it was always called on blur in the form, but that behavior is also needed when the verifier calls afterVerify.

jridgewell · 2017-05-03T23:28:54Z

extensions/amp-form/0.1/amp-form.js

+
+    const verifyXhr = this.doVarSubs_(this.getVarSubsFields_())
+        .then(() => this.doXhr_({[FORM_VERIFY_PARAM]: true}));
+    const reset = () => this.setState_(FormState_.INITIAL);


This probably needs to make sure form state is still VERIFYING

jridgewell · 2017-05-03T23:29:56Z

extensions/amp-form/0.1/amp-form.js

+      this.renderTemplate_(json || {});
+      this.maybeHandleRedirect_(response);
+    }, error => {
+      rethrowAsync('Failed to parse response JSON:', error);


This is a user error.

Thanks. Can you help me understand when something should be a user error? I haven't been able to find anything in the docs/comments.

Developer errors are only for state that we absolutely know to be true, and isn't. So, if we expect our BaseElement instance to have an element attached, but it doesn't, that goes to dev logs.

But anything that has to do with user input, like parsing JSON that pub provides, or a response that pub provides, is on them. We don't need to know about it.

It wasn't a user error before I made any changes, this is just split out from a larger function. A user error needs a tag, correct? What value should I put for tag given this is not in an amp element.

That's a mistake then. This should be "FORM"

jridgewell · 2017-05-03T23:30:02Z

extensions/amp-form/0.1/amp-form.js

+    this.setState_(FormState_.SUBMIT_ERROR);
+    this.renderTemplate_(error.responseJson || {});
+    this.maybeHandleRedirect_(error.response);
+    rethrowAsync('Form submission failed:', error);


User error.

jridgewell · 2017-05-04T18:40:02Z

extensions/amp-form/0.1/form-verifiers.js

+    // Set the error message on each element that caused an error.
+    for (let i = 0; i < errors.length; i++) {
+      const error = errors[i];
+      const element = this.form_./*OK*/querySelector(`[name="${error.name}"]`);


Neither can match the parent. The issue is #querySelector is scoped to the document, then filtered to elements inside the parent (div span can match a <div> outside parent and then a <span> inside parent). scopedQuerySelector however, is scoped to the parent only (div span can only match a <div> inside parent and a <span> inside that <div>).

#querySelector is allowed when there is a single string without any spaces (meaning, you can not have '* *'). Because this is a template string, it could do all kinds of weird things. But we know better than the linter in this case.

jridgewell · 2017-05-04T18:47:40Z

src/utils/promise.js

+    }, error => {
+      // Match the behavior of standard functions by rejecting when an error
+      // occurs even if it's out of order. e.g. Promise.race and Promise.all
+      this.reject_(error);


This is incorrect, we're looking for more of a cancel behavior and not a race behavior. This should just reject if the most recently added one rejects.

Yeah I was on the fence about which way to go. I think it can be made to be equivalent through adding promises with a catch at the end, but I agree it's convenient to not have to do that for our common use-case.

jridgewell · 2017-05-04T18:48:21Z

src/utils/promise.js

+/**
+ * Resolves with the result of the last promise added.
+ */
+export class LastAddedResolver {


@ampproject/a4a will be interested in this.

jridgewell · 2017-05-04T18:50:57Z

src/utils/promise.js

+   * Get the result promise.
+   * @return {!Promise}
+   */
+  get() {


I'd be nice if this followed the thenable spec instead (we can get rid of this method then):

then(onFulfilled, onRejected) { return this.promise_.then(onFulfilled, onRejected); }

jridgewell · 2017-05-04T21:49:34Z

src/utils/promise.js

-  get() {
-    return this.promise_;
+  then(opt_resolve, opt_reject) {
+    if (!opt_resolve && !opt_reject) {


Let the promise implementation handle this.

jridgewell · 2017-05-04T22:33:20Z

src/service/xhr-impl.js

+    if (status < 200 || status >= 300) {
+      const retriable = isRetriable(status);
+      const err = user().createCustomError(
+          new FetchError(`HTTP error ${status}`, response, retriable));


Why are we creating custom Error classes?

I was trying to adapt the existing code to work better with the type system, since gulp check-types would complain that I was accessing properties not available on an Error instance. The previous implementation instantiated a new Error and augmented it with the response and the responseJson, in effect rejecting an error and passing data together. It was added in #3669. This felt hacky and unclear since the type was sort of lying (it says it's an Error, but it has these extra fields) so I wanted to make the augmentation more formal.

jridgewell · 2017-05-04T22:40:11Z

src/log.js

+  /**
+   * @param {string} message
+   */
+  constructor(message) {


Danger! This may or may not behave as you expect based on how compliant the browser is.

I ran the unit test for this on our SauceLabs suite and it passed on all platforms. Does that mitigate the danger? Do those tests cover every browser/device we support?

I'm more worried about older versions. Extending native classes has been fraught with bugs (see https://github.com/ampproject/amphtml/blob/master/src/custom-element.js#L409-L414).

aghassemi · 2017-05-09T23:14:59Z

extensions/amp-form/amp-form.md

 #### As You Go
 The `as-you-go` reporting option allows your user to see validation messages as they're interacting with the input. For example, if the user types an invalid email address, the user will see the error right away.  Once they correct the value, the error goes away.

+## Verification


## Verification (Experimental)

also add a first sentence that points out the experimental nature and instructions on how to enable the experiment (e.g. link to https://www.ampproject.org/docs/reference/experimental )

- Prevent verify request race condition with LastAddedResolver - Add amp-form tests with verifier - Add custom error class to simplify logic with XHR errors

- Fix error on connection fail. - Fix for-loop bug. - Fix state bug.

cvializ · 2017-05-11T19:45:28Z

I've tested this against some pages in the wild and our manual tests and I feel comfortable merging this now.

aghassemi · 2017-05-12T23:25:29Z

merged

cvializ requested review from aghassemi and jridgewell April 29, 2017 01:02

cvializ force-pushed the cv-async branch 3 times, most recently from 1b22b04 to 9b012b2 Compare May 1, 2017 17:05

cvializ mentioned this pull request May 1, 2017

Weekly Status 2017-05-01 #9058

Closed

cvializ force-pushed the cv-async branch 2 times, most recently from 6195d98 to 26dff6f Compare May 1, 2017 20:34

jridgewell requested changes May 1, 2017

View reviewed changes

cvializ force-pushed the cv-async branch 3 times, most recently from 82e22af to 61354f1 Compare May 2, 2017 20:53

cvializ mentioned this pull request May 2, 2017

Use describes for form validator tests. #9105

Merged

cvializ force-pushed the cv-async branch from 61354f1 to 1415f4a Compare May 2, 2017 20:57

aghassemi suggested changes May 2, 2017

View reviewed changes

jridgewell reviewed May 2, 2017

View reviewed changes

googlebot added the cla: yes label May 3, 2017

cvializ force-pushed the cv-async branch 5 times, most recently from a278ebf to d2f3150 Compare May 4, 2017 15:44

aghassemi suggested changes May 4, 2017

View reviewed changes

jridgewell reviewed May 4, 2017

View reviewed changes

cvializ force-pushed the cv-async branch 2 times, most recently from 17ed8cc to fba0ab1 Compare May 4, 2017 22:26

jridgewell reviewed May 4, 2017

View reviewed changes

jridgewell approved these changes May 5, 2017

View reviewed changes

taymonbeal mentioned this pull request May 9, 2017

Xhr option not to reject on non-2xx response #8017

Closed

aghassemi approved these changes May 9, 2017

View reviewed changes

cvializ force-pushed the cv-async branch from cd984fa to d7c8bd2 Compare May 10, 2017 22:31

Carlos Vializ added 22 commits May 11, 2017 11:35

Implement form verification (asynchronous validation)

6b6f49c

Add shortcut to avoid unnecessary zip lookups

daff34f

Update the validity state of modified input's group peers

af0f932

Add @Private

83ef0b1

Review feedback

d8a9a62

Check config is defined

2788d66

Remove zipcodes. Remove unnecessary scopedQuerySelector

2c4a422

Review feedback

d1de68b

- Prevent verify request race condition with LastAddedResolver - Add amp-form tests with verifier - Add custom error class to simplify logic with XHR errors

Restrict group elements to submittable elements. Test.

4599bb9

Fix test

afca851

More review feedback

2b85702

- Fix error on connection fail. - Fix for-loop bug. - Fix state bug.

Improve verify error API

da59064

Update resolver api. Change resolver reject behavior.

ad778d1

Only set initial state if in verifying state

45f7bdf

Remove unnecessary checks

b754357

Change FetchError from is-a to has-a relationship with Error

a3b63fa

Update integration tests with new error

1e46a27

Add amp-form-verifiers experiment

83e649d

Treat form submit errors as user errors

258d05a

Add basic documentation

e39ef3e

Mention the experimental nature of form verification

ec4ed44

tagName is always uppercase

71998c9

cvializ force-pushed the cv-async branch from 25468ae to 71998c9 Compare May 11, 2017 18:36

aghassemi merged commit c244689 into ampproject:master May 12, 2017

cvializ deleted the cv-async branch May 15, 2017 17:19

ampprojectbot added the PR use: In Beta / Experimental label May 23, 2017

Conversation

cvializ commented Apr 29, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aghassemi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!