safari

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-08-28

Final complete day: 2026-08-28. Attention was 2.1% — this entity appeared in 55 of 2,594 analyzed posts/comments in the seven days ending that day (75 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-08-28 13:54 UTCComment

   I usually use chrome.I think it's cause many people use it.But I check firefox and safari too.I think that there is no one perfect browser.I agree that testing only in Chrome can sometimes hide browser-specific issues. Something may work perfectly in Chrome and behave differently in Firefox.

2. 2026-08-28 11:08 UTCComment

   safari bad!!! now gimme upvotes!

3. 2026-08-28 08:22 UTCComment

   Safari is the IE of the current time..

4. 2026-08-27 16:37 UTCComment

   Worth checking one thing before picking a solution, because it changes the answer completely: www.client.com and info.client.com are the same site, not third parties. Same registrable domain means third-party cookie blocking does not apply to that pair at all. So the real question is where the session cookie actually lives. Open DevTools on the parent, Application, Cookies, and look at the Domain column of the cookie that represents the session. Case 1, the cookie is on .client.com or info.client.com. Then it should already be sent inside the iframe, because the request is same-site. If it is not, the attribute is the culprit, not the browser. SameSite=Strict is not sent in a framed context, so it needs SameSite=Lax at minimum, plus Secure. That is a one-line fix and no token plumbing at all. Case 2, the cookie belongs to the third-party OAuth platform on its own domain. Now it genuinely is a third-party cookie, and you have two standards-track options nobody has mentioned yet. CHIPS, which is the simpler one: the provider sets the cookie with SameSite=None; Secure; Partitioned. The cookie is then keyed to the top-level site, so it survives third-party cookie deprecation. The usual downside of partitioned cookies, that you get a separate jar per embedder, does not hurt you here because there is exactly one embedder. The Storage Access API, if you cannot change how the provider sets cookies: the iframe calls document.requestStorageAccess() and, once granted, its own cookies are available in the embedded context. It needs a user gesture, so it fits a "click to sign in" button rather than page load. Safari has had it for years and Chrome supports it now. Case 3, neither is possible, which is where the token handoff everyone described comes in. If you go that way, one thing to change from the top comment: do not pass the token as a query param on the iframe src. It lands in browser history, in the Apache access log on your side, and in the Referer header of any outbound request the iframe makes. postMessage with an explicit targetOrigin is the right channel, and on the receiving side check event.origin instead of trusting the message. Given you already control info.client.com and the two hosts are same-site, I would spend ten minutes on case 1 before building any of the token machinery. It is very often just a SameSite attribute.

5. 2026-08-27 14:34 UTCComment

   about time, been waiting for this since forever. the corner-shape thing in safari was always weird to work around