The web3 usage metrics added in #9144 assumed that all web3 properties
were strings. When a `Symbol` property is accessed, our `inpage.js`
script crashes because the `Symbol` cannot be serialized correctly.
A check has been added for non-string property access. The metric event
in these cases is set to the string "typeof ", followed by the type of
the key. (e.g. `typeof symbol` for a `Symbol` property).
Fixes#9234
The usage metrics for the injected web3 instance were being sent upon
each use, which exceeded the limits of our Matomo plan. These metrics
are now only being sent upon the first usage, for each origin and
property.
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.
* Remove `url` parameter from `metricsEvent`
The `url` parameter was used to override the `currentPath`, but it
never worked correctly. It was supposed to be used for setting the
`url` query parameter that was sent to Matomo, but `currentPath` was
always used even if it `url` was set and `currentPath` was empty.
Instead, `currentPath` is now always used. There was never a need to
provide an "override" for `currentPath` when it can be set directly.
The metrics provider does set `currentPath` automatically by default,
but this can be overwritten already by passing a second parameter to
`metricsEvent`.
There were two places this `url` parameter was being used: background
events, and path changes. Background events were submitted with no
`currentPath`, so because of the bug with the `url` parameter, the
metrics utility would crash upon each event. So those were never
actually sent. This commit will fix that crash.
The `currentPath` parameter was supplied as an empty string for the
path change events, so those never crashed. They just had the `url`
query string parameter set incorrectly (to an empty string). It should
now be correctly populated, which should mean we'll be capturing all
path changes now. Previously we were only capturing path changes to
pages that happened to include an event, because of this blank `url`
problem.
* Use `url` query parameter as fallback for generating `pv_id`
The `pv_id` parameter currently isn't generated correctly on Firefox,
as the generation assumes that the current URL starts with
`chrome-extension://`. The `url` query parameter is still unique for
each path, so it's probably good enough for generating an id for each
page.
This is just a temporary fix; it will be removed in a future PR, where
Firefox will be properly supported.
Background events are now sent in the `Background` category, rather
than `backend`. Conventionally we use the term "background" over
"backend", as it's not really a "backend" in the normal sense since
it's a client background process. Also it's capitalized because all of
the other event categories are capitalized as well.
The metrics URL has been updated to use `background` instead of
`backend` as well, for consistency.
Luckily we don't have to worry about our metrics being disjointed due
to this name change, because the background metrics never worked to
begin with! So there will be none under the old name. The metrics will
be made functional in a separate PR.
All JavaScript files included in the final bundle are now listed as
target files. The `phishing-detect.js` file is the only new file to be
validated that was not validated before.
Any files that are expected to fail validation are commented out, with
a note explaining why they're expected to fail.
The report printed to the console for invalid source map samples has
been improved in a few ways:
* The entire message is now printed using `console.error`, so the
contents aren't split between STDERR and STDOUT
* The code fence is now guaranteed to be a set length, rather than it
varying depending on the filename
* The code fence is no longer padded on the inside with newlines, which
results in a more compact output that is (in my opinion) just as
readable.
We were not affected by the breaking changes introduced with v2.0.0.
This was updated primarily to get a bugfix relating to source maps, and
to update some older transitive dependencies.
The changes between these two versions don't seen to affect us a great
deal. The browserify dependency updates do result in changes to our
production bundle, but the changes have no obvious functional impact.
The output remains identical between these two versions, and none of
the changelog entries appear relevant to us (aside from maybe some of
the bug fixes).
The `build-artifacts` directory is created on CI (as of #7151), and is
used to store the sesify visualization and dependency logs. It's useful
to have this ignored locally as well, for when those scripts are being
tested.
Our source maps were being corrupted during minification, because the
`gulp-terser-js` plugin we were using didn't account for the existence
of sourcemaps in the input. A configuration option to allow the input
of sourcemaps was added in v5.2.0. The plugin has been updated, and we
now use this option.
Previously the generated sourcemaps had an invalid entry in the
"sources" array, with the filename of the bundle itself. This was not a
real source. After this change, this invalid source is no longer
present.
The Sentry DSN is now expected to be provided via environment variable
for production builds. The build script will fail if it is missing, and
an error will be thrown at runtime if it is missing.
The `SENTRY_DSN` environment variable has been set in CI to the old
value for `SENTRY_PROD_DSN`. We can migrate to a new DSN at some point
in the future.
