Use pathname instead of URL for currentPath metrics parameter#9158
Merged
Use pathname instead of URL for currentPath metrics parameter#9158
pathname instead of URL for currentPath metrics parameter#9158Conversation
Member
Author
5ff290e to
e7779dc
Compare
bc8031f to
a4a276b
Compare
e7779dc to
9cd049b
Compare
Collaborator
Builds ready [9cd049b]
Page Load Metrics (608 ± 44 ms)
|
The `currentPath` parameter passed to our metrics utility had been passed the full URL rather than just the path, contrary to what the name would imply. We only used the path portion, so passing the full URL did lead to complications. Now just the `pathname` is passed in, rather than the full URL. This simplifies the metrics logic, and it incidentally fixes two bugs. The main bug fixed is regarding Firefox metrics. Previously we had assumed the `currentPath` would start with `chrome-extension://`, which of course was not true on Firefox. This lead to us incorrectly parsing the `currentPath`, so path tracking was broken for Firefox events. This broken parsing is now bypassed entirely, so metrics should now work the same on Firefox as on Chrome. The second bug was that we were incorrectly setting the tracking URL for background events during tests. As a result, we were incorrectly detecting ourselves as an internal site that had referred the user to us. But this was not of major concern, since it only affected test metrics (which get sent to the development Matomo project). Lastly, this change let us discard the `pathname` parameter used in the `overrides` parameter of the `metricsEvent` function. Now that `currentPath` is equivalent to `pathname`, the `pathname` parameter is redundant.
9cd049b to
3faded6
Compare
Collaborator
Builds ready [3faded6]
Page Load Metrics (617 ± 19 ms)
|
Gudahtt
added a commit
that referenced
this pull request
Aug 7, 2020
) The `currentPath` parameter passed to our metrics utility had been passed the full URL rather than just the path, contrary to what the name would imply. We only used the path portion, so passing the full URL did lead to complications. Now just the `pathname` is passed in, rather than the full URL. This simplifies the metrics logic, and it incidentally fixes two bugs. The main bug fixed is regarding Firefox metrics. Previously we had assumed the `currentPath` would start with `chrome-extension://`, which of course was not true on Firefox. This lead to us incorrectly parsing the `currentPath`, so path tracking was broken for Firefox events. This broken parsing is now bypassed entirely, so metrics should now work the same on Firefox as on Chrome. The second bug was that we were incorrectly setting the tracking URL for background events during tests. As a result, we were incorrectly detecting ourselves as an internal site that had referred the user to us. But this was not of major concern, since it only affected test metrics (which get sent to the development Matomo project). Lastly, this change let us discard the `pathname` parameter used in the `overrides` parameter of the `metricsEvent` function. Now that `currentPath` is equivalent to `pathname`, the `pathname` parameter is redundant.
Gudahtt
added a commit
that referenced
this pull request
Aug 10, 2020
* origin/master: (44 commits) Add category in eventOpts (#9164) Update changelog for v8.0.7 (#9161) Version v8.0.7 Remove web3 e2e tests (#9159) Add web3 usage metrics, prepare for web3 removal (#9144) Use `pathname` instead of URL for `currentPath` metrics parameter (#9158) Remove `url` parameter from `metricsEvent` (#9157) Change MetaMetrics category for background events (#9155) remove .network-name height Use luxon@1.24.1 (#9154) Update 'react-devtools' to ^4.8.0 (#9140) Fix connection removal bug (#9137) Add source map validator to CI (#9135) Update source map validator target files (#9133) Improve sourcemap validator console report (#9131) Add `validate-source-maps` npm script (#9134) Non-zero exit code upon failure to validate source maps (#9132) Update `brfs` from v1.6.1 to v2.0.2 (#9115) Factor out `getEnvironment` function in build script (#9114) Update `browserify` from v16.2.3 to v16.5.1 (#9113) ...
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
currentPathparameter passed to our metrics utility had been passed the full URL rather than just the path, contrary to what the name would imply. We only used the path portion, so passing the full URL did lead to complications.Now just the
pathnameis passed in, rather than the full URL. This simplifies the metrics logic, and it incidentally fixes two bugs.The main bug fixed is regarding Firefox metrics. Previously we had assumed the
currentPathwould start withchrome-extension://, which of course was not true on Firefox. This lead to us incorrectly parsing thecurrentPath, so path tracking was broken for Firefox events. This broken parsing is now bypassed entirely, so metrics should now work the same on Firefox as on Chrome.The second bug was that we were incorrectly setting the tracking URL for background events during tests. As a result, we were incorrectly detecting ourselves as an internal site that had referred the user to us. But this was not of major concern, since it only affected test metrics (which get sent to the development Matomo project).