Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update handling of UA/environment in ObjectGraph instances #21

Merged
merged 4 commits into from
May 16, 2018
Merged

Conversation

mdittmer
Copy link
Owner

UA:

  • Lock in on capture to ensure that it is an own property

Environment:

  • Copy from (default) UA during lazy data initialization
  • Can be overridden (since UA string does not always capture it precisely)
  • Store as JSON key (because it's not always derived from UA string anymore)

UA:

- Lock in on capture to ensure that it is an own property

Environment:

- Copy from (default) UA during lazy data initialization
- Can be overridden (since UA string does not always capture it precisely)
- Store as JSON key (because it's not always derived from UA string anymore)
@mdittmer
Copy link
Owner Author

@foolip PTAL. Once this change is in place, a form for controlling ObjectGraph.environment can be implemented in https://github.com/mdittmer/web-apis

@@ -54,6 +54,14 @@ ObjectGraph.prototype.init = function(opts) {

// Try to prevent recursion into internal structures.
this.blacklistedObjects.push(this);

// Lock-in user agent by (potentially) copying it into an own property.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is just potentially? This unconditionally assigns this.userAgent, but is there some way it could have already been an own property? Is there still a reason to have ObjectGraph.prototype.userAgent now, or could have just this.userAgent, like for environment? That'd be easier to understand I think.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I would leave the prototype value in place is defensive: If we deserialize an ObjectGraph with no userAgent, it should assume its default value.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed on VC, since ObjectGraph instances are used both when collecting data on the browser and are also created with ObjectGraph.fromJSON in node when processing the data, there's a risk of confusion if the node UA string shows up there from the prototype. So setting userAgent only in a code path that's run when collecting data would be best. (Can't quite tell if this is such a code path.)

Copy link
Contributor

@foolip foolip left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM % userAgent nit, but can take another if requested

mdittmer added a commit to GoogleChromeLabs/confluence that referenced this pull request Jan 17, 2018
... fallback on old behaviour: Use filename. In combination with `mdittmer/web-apis` and `mdittmer/object-graph-js` changes, this allows data collectors to manually rewrite browser info (because some browsers do not contain precise enough info in their UA string), and for that info to propagate up into Confluence's data objects.

Dependent PRs:

mdittmer/web-apis#55 + mdittmer/web-apis#56
mdittmer/object-graph-js#21
Copy link
Contributor

@foolip foolip left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite understand the latest state of this. navigator.userAgent no longer appears anywhere, so is it just not being saved?

@foolip
Copy link
Contributor

foolip commented Jan 19, 2018

I read my notification in the wrong order: mdittmer/web-apis#57

@mdittmer mdittmer merged commit 1b1a817 into master May 16, 2018
@mdittmer mdittmer deleted the ua-env branch May 16, 2018 14:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants