Record href with click

[eoghanmurray]

See #503 for my proposal on this.

The idea is that the actual href of an anchor is a useful distinguishing feature of a click.

I'm going for the low hanging fruit here, but if it's deemed to be a good idea, I could extend this PR with detecting <button type="submit"> clicks and interrogating the associated <form target=""> (we might need to also record POST/GET for that).

[meatflavourdev]

Right, the consequentiality of a click can be determined by the metadata of the click event is sort of a generalization of the idea here. Is there other data that might be relevant? You mentioned buttons, etc.

[Yuyz0112]

This code looks too 'analytics tool specific' for me. Obviously, we can have more of these data along with the core data structure for analytics usage, but other users do not care.

Not quite sure how users will consume these data but do a separate event can do the same thing?

[
  click event,
  custom click event(with href, button type, etc.),
]

If this works for the backend and replayer, I think it's a better implementation because we can move it to a plugin.

[eoghanmurray]

The application on our end is to show a tooltip on the timeline so that users can inspect clicks. It's also useful in the context of a multi-pageview session to see whether a click on one page resulted in a corresponding Meta event with the same url for the next page load. This can be useful if there are multiple tabs open at once in terms of joining up a session correctly.

I think it's a better implementation because we can move it to a plugin

That's fine by me! I'm also planning to add CSS selectors to click events (and maybe mutations also for debugging purposes) e.g. via https://github.com/antonmedv/finder — given the extra js include, it's definitely something that should be done via a plugin.
I thought this PR might be more generally useful in the trunk given that it doesn't require extra javascript. Also click events (on links) aren't all that common, so shouldn't add much to an average recording, but I think are just as significant as pageloads e.g. if the user is exiting the website.

Aside: I've also considered adding a slimDOM option to replace all href values with e.g. an 'X', as hrefs can contain long urls with bloated query strings which don't get rendered during replay (with the possible exception of a tailored CSS rule). This PR would be necessary to preserve only the relevant href info in that case.

[eoghanmurray]

Is there other data that might be relevant?

I've just thought of whether SHIFT/META keys are held down during the click; that is significant in terms of opening the link in a new tab.

[Yuyz0112]

Yes, the main concern is even we provide some options to not collecting these data, the code of these implementations still makes the rrweb's core code getting a bit more complicated.

So a standalone plugin may be helpful because it moves the code to a single place and decoupled with the core.

[eoghanmurray]

I'll try to get time to implement this as a plugin, but am not exploring this at the moment so if anyone wants to take up the mantle, go ahead.

@Yuyz0112 00fd6eb might otherwise be useful as it is independent of this PR

[Yuyz0112]

@eoghanmurray , yes, we can pick the test commit.

[eoghanmurray]

That test commit 00fd6eb has been merged now in 3ce6903 as it was useful in #1201 (which fixes up #1129 )