fix: Try to use a better performance API

[wmak]

• Trying to address the inconsistencies between browsers
• Always try to use the timeOrigin first, as long as its consistent with the current time
• Otherwise, use the navigationStart if its consistent with the current time
• And still fallback to date if all of the above fails
• Remember what source is used for the time origin, so we can tag events and analyze later
• An attempt to fixTiming issues using Performance API #2590

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests. -- Manually tested with Safari, Chrome + Firefox
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	20.51 KB (+0.19% 🔺)
@sentry/browser - Webpack	21.37 KB (+0.26% 🔺)
@sentry/react - Webpack	21.41 KB (+0.26% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	27.6 KB (+0.14% 🔺)

[dashed]

@wmak were you able to test this change in Safari, Chrome, and Firefox?

[wmak]

@dashed
Yup!
In firefox when timeOrigin was incorrect, this changes to timing.navigationStart, and if timeOrigin was correct it would continue using it.
In chrome where timeOrigin is usually correct this continues to use it
in Safari which only has timing.navigationStart this continues to use that.

[rhcarvalho]

I like this, it can likely mitigate the problems we're seeing on FF.

Thanks @wmak <3

[wmak]

Also, starting with Threshold == 1 hour, but this will likely mean we start seeing inaccurate durations up to an hour, if this solution works out we could drop Threshold down to a few seconds instead, just want to start with something safer for now

[rhcarvalho]

I'd love to see this in prod.

@wmak I had one idea since yesterday -- as a way to debug and quantify how this is working, we could set some internal variable with a string depending on what time origin is being used (timeOrigin, navigationStart or dateNow) and then in Sentry we can use this + event processor to set a tag on every transaction, so we can filter and see what fraction of users use which method, see if there is a clear browser correlation etc.
We could also mark/tag whenever we decided that timeOrigin or navigationStart is reliable or not.

@kamilogorek would you have some suggestion on how to implement the "internal global value"? E.g. how exactly to bind to the global sentry object?

[rhcarvalho]

Getting this in so we can test across more browsers in the wild.

[wmak]

• Trying to address the inconsistencies between browsers
• Always try to use the timeOrigin first, as long as its consistent with the current time
• Otherwise, use the navigationStart if its consistent with the current time
• And still fallback to date if all of the above fails
• Remember what source is used for the time origin, so we can tag events and analyze later
• An attempt to fixTiming issues using Performance API #2590

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests. -- Manually tested with Safari, Chrome + Firefox
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	20.51 KB (+0.19% 🔺)
@sentry/browser - Webpack	21.37 KB (+0.26% 🔺)
@sentry/react - Webpack	21.41 KB (+0.26% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	27.6 KB (+0.14% 🔺)

[dashed]

@wmak were you able to test this change in Safari, Chrome, and Firefox?

[wmak]

@dashed
Yup!
In firefox when timeOrigin was incorrect, this changes to timing.navigationStart, and if timeOrigin was correct it would continue using it.
In chrome where timeOrigin is usually correct this continues to use it
in Safari which only has timing.navigationStart this continues to use that.

[rhcarvalho]

I like this, it can likely mitigate the problems we're seeing on FF.

Thanks @wmak <3

[wmak]

Also, starting with Threshold == 1 hour, but this will likely mean we start seeing inaccurate durations up to an hour, if this solution works out we could drop Threshold down to a few seconds instead, just want to start with something safer for now

[rhcarvalho]

I'd love to see this in prod.

@wmak I had one idea since yesterday -- as a way to debug and quantify how this is working, we could set some internal variable with a string depending on what time origin is being used (timeOrigin, navigationStart or dateNow) and then in Sentry we can use this + event processor to set a tag on every transaction, so we can filter and see what fraction of users use which method, see if there is a clear browser correlation etc.
We could also mark/tag whenever we decided that timeOrigin or navigationStart is reliable or not.

@kamilogorek would you have some suggestion on how to implement the "internal global value"? E.g. how exactly to bind to the global sentry object?

[rhcarvalho]

Getting this in so we can test across more browsers in the wild.

[wmak]

• Trying to address the inconsistencies between browsers
• Always try to use the timeOrigin first, as long as its consistent with the current time
• Otherwise, use the navigationStart if its consistent with the current time
• And still fallback to date if all of the above fails
• Remember what source is used for the time origin, so we can tag events and analyze later
• An attempt to fixTiming issues using Performance API #2590

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests. -- Manually tested with Safari, Chrome + Firefox
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	20.51 KB (+0.19% 🔺)
@sentry/browser - Webpack	21.37 KB (+0.26% 🔺)
@sentry/react - Webpack	21.41 KB (+0.26% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	27.6 KB (+0.14% 🔺)

[dashed]

@wmak were you able to test this change in Safari, Chrome, and Firefox?

[wmak]

@dashed
Yup!
In firefox when timeOrigin was incorrect, this changes to timing.navigationStart, and if timeOrigin was correct it would continue using it.
In chrome where timeOrigin is usually correct this continues to use it
in Safari which only has timing.navigationStart this continues to use that.

[rhcarvalho]

I like this, it can likely mitigate the problems we're seeing on FF.

Thanks @wmak <3

[wmak]

Also, starting with Threshold == 1 hour, but this will likely mean we start seeing inaccurate durations up to an hour, if this solution works out we could drop Threshold down to a few seconds instead, just want to start with something safer for now

[rhcarvalho]

I'd love to see this in prod.

@wmak I had one idea since yesterday -- as a way to debug and quantify how this is working, we could set some internal variable with a string depending on what time origin is being used (timeOrigin, navigationStart or dateNow) and then in Sentry we can use this + event processor to set a tag on every transaction, so we can filter and see what fraction of users use which method, see if there is a clear browser correlation etc.
We could also mark/tag whenever we decided that timeOrigin or navigationStart is reliable or not.

@kamilogorek would you have some suggestion on how to implement the "internal global value"? E.g. how exactly to bind to the global sentry object?

[rhcarvalho]

Getting this in so we can test across more browsers in the wild.

[wmak]

• Trying to address the inconsistencies between browsers
• Always try to use the timeOrigin first, as long as its consistent with the current time
• Otherwise, use the navigationStart if its consistent with the current time
• And still fallback to date if all of the above fails
• Remember what source is used for the time origin, so we can tag events and analyze later
• An attempt to fixTiming issues using Performance API #2590

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests. -- Manually tested with Safari, Chrome + Firefox
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	20.51 KB (+0.19% 🔺)
@sentry/browser - Webpack	21.37 KB (+0.26% 🔺)
@sentry/react - Webpack	21.41 KB (+0.26% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	27.6 KB (+0.14% 🔺)

[dashed]

@wmak were you able to test this change in Safari, Chrome, and Firefox?

[wmak]

@dashed
Yup!
In firefox when timeOrigin was incorrect, this changes to timing.navigationStart, and if timeOrigin was correct it would continue using it.
In chrome where timeOrigin is usually correct this continues to use it
in Safari which only has timing.navigationStart this continues to use that.

[rhcarvalho]

I like this, it can likely mitigate the problems we're seeing on FF.

Thanks @wmak <3

[wmak]

Also, starting with Threshold == 1 hour, but this will likely mean we start seeing inaccurate durations up to an hour, if this solution works out we could drop Threshold down to a few seconds instead, just want to start with something safer for now

[rhcarvalho]

I'd love to see this in prod.

@wmak I had one idea since yesterday -- as a way to debug and quantify how this is working, we could set some internal variable with a string depending on what time origin is being used (timeOrigin, navigationStart or dateNow) and then in Sentry we can use this + event processor to set a tag on every transaction, so we can filter and see what fraction of users use which method, see if there is a clear browser correlation etc.
We could also mark/tag whenever we decided that timeOrigin or navigationStart is reliable or not.

@kamilogorek would you have some suggestion on how to implement the "internal global value"? E.g. how exactly to bind to the global sentry object?

[rhcarvalho]

Getting this in so we can test across more browsers in the wild.

[wmak]

• Trying to address the inconsistencies between browsers
• Always try to use the timeOrigin first, as long as its consistent with the current time
• Otherwise, use the navigationStart if its consistent with the current time
• And still fallback to date if all of the above fails
• Remember what source is used for the time origin, so we can tag events and analyze later
• An attempt to fixTiming issues using Performance API #2590

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests. -- Manually tested with Safari, Chrome + Firefox
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	20.51 KB (+0.19% 🔺)
@sentry/browser - Webpack	21.37 KB (+0.26% 🔺)
@sentry/react - Webpack	21.41 KB (+0.26% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	27.6 KB (+0.14% 🔺)

[dashed]

@wmak were you able to test this change in Safari, Chrome, and Firefox?

[wmak]

@dashed
Yup!
In firefox when timeOrigin was incorrect, this changes to timing.navigationStart, and if timeOrigin was correct it would continue using it.
In chrome where timeOrigin is usually correct this continues to use it
in Safari which only has timing.navigationStart this continues to use that.

[rhcarvalho]

I like this, it can likely mitigate the problems we're seeing on FF.

Thanks @wmak <3

[wmak]

Also, starting with Threshold == 1 hour, but this will likely mean we start seeing inaccurate durations up to an hour, if this solution works out we could drop Threshold down to a few seconds instead, just want to start with something safer for now

[rhcarvalho]

I'd love to see this in prod.

@wmak I had one idea since yesterday -- as a way to debug and quantify how this is working, we could set some internal variable with a string depending on what time origin is being used (timeOrigin, navigationStart or dateNow) and then in Sentry we can use this + event processor to set a tag on every transaction, so we can filter and see what fraction of users use which method, see if there is a clear browser correlation etc.
We could also mark/tag whenever we decided that timeOrigin or navigationStart is reliable or not.

@kamilogorek would you have some suggestion on how to implement the "internal global value"? E.g. how exactly to bind to the global sentry object?

[rhcarvalho]

Getting this in so we can test across more browsers in the wild.

[wmak]

• Trying to address the inconsistencies between browsers
• Always try to use the timeOrigin first, as long as its consistent with the current time
• Otherwise, use the navigationStart if its consistent with the current time
• And still fallback to date if all of the above fails
• Remember what source is used for the time origin, so we can tag events and analyze later
• An attempt to fixTiming issues using Performance API #2590

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests. -- Manually tested with Safari, Chrome + Firefox
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	20.51 KB (+0.19% 🔺)
@sentry/browser - Webpack	21.37 KB (+0.26% 🔺)
@sentry/react - Webpack	21.41 KB (+0.26% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	27.6 KB (+0.14% 🔺)

[dashed]

@wmak were you able to test this change in Safari, Chrome, and Firefox?

[wmak]

@dashed
Yup!
In firefox when timeOrigin was incorrect, this changes to timing.navigationStart, and if timeOrigin was correct it would continue using it.
In chrome where timeOrigin is usually correct this continues to use it
in Safari which only has timing.navigationStart this continues to use that.

[rhcarvalho]

I like this, it can likely mitigate the problems we're seeing on FF.

Thanks @wmak <3

[wmak]

Also, starting with Threshold == 1 hour, but this will likely mean we start seeing inaccurate durations up to an hour, if this solution works out we could drop Threshold down to a few seconds instead, just want to start with something safer for now

[rhcarvalho]

I'd love to see this in prod.

@wmak I had one idea since yesterday -- as a way to debug and quantify how this is working, we could set some internal variable with a string depending on what time origin is being used (timeOrigin, navigationStart or dateNow) and then in Sentry we can use this + event processor to set a tag on every transaction, so we can filter and see what fraction of users use which method, see if there is a clear browser correlation etc.
We could also mark/tag whenever we decided that timeOrigin or navigationStart is reliable or not.

@kamilogorek would you have some suggestion on how to implement the "internal global value"? E.g. how exactly to bind to the global sentry object?

[rhcarvalho]

Getting this in so we can test across more browsers in the wild.

[wmak]

• Trying to address the inconsistencies between browsers
• Always try to use the timeOrigin first, as long as its consistent with the current time
• Otherwise, use the navigationStart if its consistent with the current time
• And still fallback to date if all of the above fails
• Remember what source is used for the time origin, so we can tag events and analyze later
• An attempt to fixTiming issues using Performance API #2590

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests. -- Manually tested with Safari, Chrome + Firefox
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	20.51 KB (+0.19% 🔺)
@sentry/browser - Webpack	21.37 KB (+0.26% 🔺)
@sentry/react - Webpack	21.41 KB (+0.26% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	27.6 KB (+0.14% 🔺)

[dashed]

@wmak were you able to test this change in Safari, Chrome, and Firefox?

[wmak]

@dashed
Yup!
In firefox when timeOrigin was incorrect, this changes to timing.navigationStart, and if timeOrigin was correct it would continue using it.
In chrome where timeOrigin is usually correct this continues to use it
in Safari which only has timing.navigationStart this continues to use that.

[rhcarvalho]

I like this, it can likely mitigate the problems we're seeing on FF.

Thanks @wmak <3

[wmak]

Also, starting with Threshold == 1 hour, but this will likely mean we start seeing inaccurate durations up to an hour, if this solution works out we could drop Threshold down to a few seconds instead, just want to start with something safer for now

[rhcarvalho]

I'd love to see this in prod.

@wmak I had one idea since yesterday -- as a way to debug and quantify how this is working, we could set some internal variable with a string depending on what time origin is being used (timeOrigin, navigationStart or dateNow) and then in Sentry we can use this + event processor to set a tag on every transaction, so we can filter and see what fraction of users use which method, see if there is a clear browser correlation etc.
We could also mark/tag whenever we decided that timeOrigin or navigationStart is reliable or not.

@kamilogorek would you have some suggestion on how to implement the "internal global value"? E.g. how exactly to bind to the global sentry object?

[rhcarvalho]

Getting this in so we can test across more browsers in the wild.

[wmak]

• Trying to address the inconsistencies between browsers
• Always try to use the timeOrigin first, as long as its consistent with the current time
• Otherwise, use the navigationStart if its consistent with the current time
• And still fallback to date if all of the above fails
• Remember what source is used for the time origin, so we can tag events and analyze later
• An attempt to fixTiming issues using Performance API #2590

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests. -- Manually tested with Safari, Chrome + Firefox
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	20.51 KB (+0.19% 🔺)
@sentry/browser - Webpack	21.37 KB (+0.26% 🔺)
@sentry/react - Webpack	21.41 KB (+0.26% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	27.6 KB (+0.14% 🔺)

[dashed]

@wmak were you able to test this change in Safari, Chrome, and Firefox?

[wmak]

@dashed
Yup!
In firefox when timeOrigin was incorrect, this changes to timing.navigationStart, and if timeOrigin was correct it would continue using it.
In chrome where timeOrigin is usually correct this continues to use it
in Safari which only has timing.navigationStart this continues to use that.

[rhcarvalho]

I like this, it can likely mitigate the problems we're seeing on FF.

Thanks @wmak <3

[wmak]

Also, starting with Threshold == 1 hour, but this will likely mean we start seeing inaccurate durations up to an hour, if this solution works out we could drop Threshold down to a few seconds instead, just want to start with something safer for now

[rhcarvalho]

I'd love to see this in prod.

@wmak I had one idea since yesterday -- as a way to debug and quantify how this is working, we could set some internal variable with a string depending on what time origin is being used (timeOrigin, navigationStart or dateNow) and then in Sentry we can use this + event processor to set a tag on every transaction, so we can filter and see what fraction of users use which method, see if there is a clear browser correlation etc.
We could also mark/tag whenever we decided that timeOrigin or navigationStart is reliable or not.

@kamilogorek would you have some suggestion on how to implement the "internal global value"? E.g. how exactly to bind to the global sentry object?

[rhcarvalho]

Getting this in so we can test across more browsers in the wild.