ref: Drop Safari 14 support - remove navigationStart fallback and pagehide listeners#21293
ref: Drop Safari 14 support - remove navigationStart fallback and pagehide listeners#21293eddie333016 wants to merge 2 commits into
Conversation
…rt fallback and pagehide listeners Safari 15+ has full performance.timeOrigin support and reliable visibilitychange events. This removes: - performance.timing?.navigationStart fallback in getBrowserTimeOrigin() - pagehide event listeners in web-vitals vendored code (onHidden, getVisibilityWatcher, whenIdleOrHidden) - isPageHidden() helper that checked for pagehide event type - Updated integration tests to use visibilitychange instead of pagehide This saves ~100 bytes of unnecessary browser compatibility code. Closes getsentry#18707
eddie333016
requested review from
logaretm and
mydea
and removed request for
a team
logaretm
left a comment
logaretm
left a comment
There was a problem hiding this comment.
The Safari 14/pagehide removal is fine for v11, but the PR needs to clean up the stale tests.
At any case, this PR won't be merged at the moment until v11 is being prepared for release given its breaking changes nature.
| const navigationStart = performance.timing?.navigationStart; | ||
| if (typeof navigationStart === 'number') { | ||
| const navigationStartDelta = Math.abs(navigationStart + performanceNow - dateNow); | ||
| if (navigationStartDelta < threshold) { | ||
| return navigationStart; | ||
| } | ||
| } |
There was a problem hiding this comment.
Some tests still assert the navigationStart. Those tests will fail.
Addresses review feedback from @logaretm: - Remove test that asserted navigationStart fallback (code path removed) - Remove navigationStart stubs from remaining tests (no longer relevant) - Update test descriptions to reflect current behavior - Update replay fixture timeOrigin.mode from 'navigationStart' to 'timeOrigin' - Fix missing trailing newlines in all modified files
|
Thanks for the review @logaretm! You're right — the stale tests would have failed. I've pushed a follow-up commit that cleans everything up:
Understood on the v11 merge timing — happy for this to wait until the release prep begins. |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| }; | ||
|
|
||
| addPageListener('visibilitychange', onHiddenOrPageHide, { capture: true, once: true }); | ||
| // Some browsers have buggy implementations of visibilitychange, | ||
| // so we use pagehide in addition, just to be safe. | ||
| addPageListener('pagehide', onHiddenOrPageHide, { capture: true, once: true }); | ||
| addPageListener('visibilitychange', onHiddenCallback, { capture: true, once: true }); | ||
| }; |
There was a problem hiding this comment.
Bug: The visibilitychange listener uses { once: true }, causing it to be prematurely removed if a page loads in the background, preventing web vital metrics from being reported.
Severity: HIGH
Suggested Fix
Remove the { once: true } option from the addPageListener call for the visibilitychange event. Instead, the listener should be manually removed from within the callback function only after the document.visibilityState === 'hidden' condition is met and the provided callback cb has been executed. This ensures the listener persists across visibility state changes until it has successfully performed its action.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: packages/browser-utils/src/metrics/web-vitals/lib/onHidden.ts#L39-L42
Potential issue: The `visibilitychange` event listener in `onHidden.ts` is configured
with `{ once: true }`, which causes it to be removed after its first invocation. If a
page loads in a background tab and is later brought to the foreground, a
`visibilitychange` event fires. At this moment, `document.visibilityState` is
`'visible'`, so the callback's condition check fails. However, the listener is still
removed. When the user eventually navigates away, making the page hidden, no listener
exists to handle the event. This prevents the `onHidden` callback from ever executing,
leading to a complete loss of web vital metrics (like LCP and CLS) for any page loaded
in a background tab.
Did we get this right? 👍 / 👎 to inform future reviews.
2 participants
Summary
Closes #18707
Drops Safari 14 compatibility code by removing the
performance.timing.navigationStartfallback andpagehideevent listeners from the vendored web-vitals code.Changes
Core timing (
packages/core/src/utils/time.ts):performance.timing?.navigationStartfallback ingetBrowserTimeOrigin()— Safari 15+ supportsperformance.timeOriginnativelyWeb-vitals vendored code (
packages/browser-utils/src/metrics/web-vitals/lib/):onHidden.ts: Removedpagehideevent listener, now only listens tovisibilitychangegetVisibilityWatcher.ts: Removedpagehideevent listener, removedisPageHidden()helper, simplifiedonVisibilityUpdateto only checkdocument.visibilityStatewhenIdleOrHidden.ts: Removedpagehideadd/remove listener pairsIntegration tests:
hidePage()helpers to dispatchvisibilitychange(withdocument.visibilityState = 'hidden') instead ofpagehidepagehidedispatches to use the same patternsentry.report_event: 'pagehide'data labels unchanged (backend-facing API contract)Bundle size impact
Saves ~100 bytes by removing unnecessary fallback code paths and event listeners.