visited: not working on external links

[wpas81]

I'm applying visited:text-red-500 on links. This works fine for interal links but is not applied to links pointing to external domains. Why is this and how can I fix this?

Eg

<a href="https://mysite/somepage" class="visited:text-red-500">Internal</a> << this works 

<a href="https://google.com" class="visited:text-red-500">External</a> << this does not work

[RobinMalfait]

You cannot fix this, it's a security feature by browsers. Otherwise you would be able to compute the browser history of a person.

[wpas81]

different link colors for visited links are default behaviour and still allowed

[wongjn]

Consider checking you've clicked on the external link before. It seems to work in this Tailwind Play. I click the External link and when I go back to it, the link is red. Otherwise, it could be browser privacy settings or some other privacy-preservation interaction.

[wpas81]

I tried with several browers... Via my own PC I don't get the colored link, I tried via a different system now with default Chrome and Edge installs (no plugins, no settings). Chrome doesn't but Edge does show the link in red. So not tailwind but a browser issue.

[wpas81]

got it! Tansk for you pointing me in the right direction my Google skills found the right answer :) seems to be a Chrome flag. Disabling this option chrome://flags/#partition-visited-link-database-with-self-links makes the links colored again after visit.

Source: https://www.reddit.com/r/bugs/comments/1f25i60/chrome_visited_links_not_changing_color/

[rozsazoltan]

Related: Tailwind CSS visited variant not applied on external links

• Chromium #40064793 - Partition :visited links history - Chromium Issues
  • Feature: Partitioning :visited links history - Chrome
  • Docs: explainers-by-googlers/Partitioning-visited-links-history - GitHub
• mozilla/standards-positions issue #1040 - Partitioned :visited links history - Firefox
• WebKit/standards-positions issue #363 - Partitioning :visited links history - Safari

The motivation behind the development is the deeper understanding and complete resolution of the data leakage issue I originally mentioned. Although many restrictions have already been introduced in response to data leakage, the best solution in the future may be full separation or the ability to disable it entirely - which is already actively being tested.

Motivation: Since 2010, the number of side-channel attacks to leak the user’s browsing history from :visited links styling has grown, including user interaction attacks, timing attacks, pixel color attacks, and process-level attacks. While these attack vectors are slowed down by the 2010 mitigations, they are not eliminated; browsers are still actively leaking user browsing history today. [...]

[wpas81]

thanks for the extra info & references. I understand the potential issues but this seems very low-risk to me since it's client based (the browsers knows what you've visited, not the server) and it must match the exact url. Anyway it's resolved.. for now. When they do block it off I'll figure a way around it.