[franga2000]

If it's callstack-based the event handler could easily just run the redirect in setTimeout. Making it time-based might work, but would break a lot of common use-cases. Maybe they could block only cross-origin redirects?

There still is the issue of Mozilla being the only one without a direct incentive to prevent this fix from rolling out. With their whopping 3 percent market share, I doubt they'd be willing to break a web feature we've had for decades.

[Dylan16807]

Time based? If that's equivalent to "toggling a flag" then yes that's what I'm suggesting.

What use cases would it break? Why do you need a fake URL to show up when the link is hovered?

[franga2000]

The way the faking works is that the site catches your click event and redirects you to somewhere else. Therefore, the only fix is to prevent such redirects. Preventing JS redirects would break many things. AJAX form submission with a redirect at the end, for example, is very common.

Preventing them in onclick handlers of a[href] elements would break fewer, but then you have the issue of correlating the redirect with the click. If you simply ban window.href= in the handler, sites could simply use setTimeout or set a flag and have a repeating background task trigger the redirect when the flag is set. Alternatively, you could do something like prevent all redirects X seconds after a link is clicked. Unfortunately, that would only discourage sites that are trying to be fast (like Google). Scam sites are usually slow and bloated anyways.

[Dylan16807]

> AJAX form submission with a redirect at the end, for example, is very common.

Why does that AJAX form need to pretend it's a link to a specific URL?

A button would have no problem, and a link that stays on the page would have no problem.

[franga2000]

The trick works by cancelling the link click event and redirecting somewhere else in JS. The only way to prevent that would be to not allow any redirects in JS, including buttons.