bug(recordings): HTML select elements don't show the correct selected option

[kamranayub]

Bug description

When viewing session recordings, I noticed that <select> dropdown elements don't show the correct selected option, making for a confusing experience (I thought this was a bug in my app).

How to reproduce

I have a session replay recording of me using Cypress to test this issue, so you can clearly see it.

1. Watch this session replay
2. Skip to when I click the "More" button
3. It opens a modal, and the "Privacy" dropdown is showing "Public" as the selected option

In reality, the selected option is "Private" if you view it in the browser:

When you select "Public", some more UI shows up, which is how I realized the session recordings were wrong 😅

Environment

• [x] PostHog Cloud US, project ID: 35181

Additional context

This may be a limitation of the recorder, I am not sure. I tried looking around for troubleshooting tips or other issues and didn't see this mentioned yet.

[kamranayub]

I wonder if it is because of React's way of handling selection? Normally you would have selected on the <option> elements but instead with React I am setting the <select value={selectedValue}> since that's the way for controlled state.

You can see there is no value attribute or selected attributes in the rendered HTML.

So the session recorder just takes the last option as the selected. 🤔

[pauldambra]

"instead with React I am setting the since that's the way for controlled state."

Are you saying that your rendered HTML doesn't get the selected attribute set?

The recorder listens to DOM mutations and stores them, that's what is played back. So, if the DOM is never mutated to set selected on the element, the recording can't replay it.

(or have I misundestood? 😊)

kamranayub commented 10 months ago

"instead with React I am setting the since that's the way for controlled state." Are you saying that your rendered HTML doesn't get the selected attribute set? The recorder listens to DOM mutations and stores them, that's what is played back. So, if the DOM is never mutated to set selected on the element, the recording can't replay it. (or have I misundestood? 😊)

The screenshot above is the rendered HTML of the recording screenshot. In other words, "Private" is selected but React doesn't render selected attribute since it handles setting the value of the element instance itself.

So I think it might make sense based on what you said; the DOM is never mutated to add a selected attribute, so it's never picked up by the recorder.

There's a SO post about why it works this way in React.

pauldambra commented 10 months ago

React should be something we can ignore here, since we only care about the HTML that was output not the technology that caused it to be output.

So long as we're outputting valid HTML then recording should cope.

I'll need to make time to build a select into our example project in posthog-js and check what happens 🤔

pauldambra commented 10 months ago

(and tbh enough website use React - including posthog - that I'd be amazed that we hadn't had this reported before now)

kamranayub commented 9 months ago

@pauldambra My guess as to why that is: people are using design frameworks and libraries that would hide this. I'm using raw HTML <select> elements, whereas things like React Select, Material, or likely other libraries wrap the native selects to hide this issue.

e.g. Posthog doesn't even use <select> it seems:

jeremylanger commented 3 weeks ago

We are running into this same issue. Also using React and seeing the exact same as @kamranayub described. The session recording is displaying the last <option> in the <select>, regardless of the selection. In fact for us, once a selection is made, the displayed value in the recording is empty.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[kamranayub]

"instead with React I am setting the since that's the way for controlled state." Are you saying that your rendered HTML doesn't get the selected attribute set? The recorder listens to DOM mutations and stores them, that's what is played back. So, if the DOM is never mutated to set selected on the element, the recording can't replay it. (or have I misundestood? 😊)

The screenshot above is the rendered HTML of the recording screenshot. In other words, "Private" is selected but React doesn't render selected attribute since it handles setting the value of the element instance itself.

So I think it might make sense based on what you said; the DOM is never mutated to add a selected attribute, so it's never picked up by the recorder.

There's a SO post about why it works this way in React.

[pauldambra]

React should be something we can ignore here, since we only care about the HTML that was output not the technology that caused it to be output.

So long as we're outputting valid HTML then recording should cope.

I'll need to make time to build a select into our example project in posthog-js and check what happens 🤔

[pauldambra]

(and tbh enough website use React - including posthog - that I'd be amazed that we hadn't had this reported before now)

[kamranayub]

@pauldambra My guess as to why that is: people are using design frameworks and libraries that would hide this. I'm using raw HTML <select> elements, whereas things like React Select, Material, or likely other libraries wrap the native selects to hide this issue.

e.g. Posthog doesn't even use <select> it seems:

[jeremylanger]

We are running into this same issue. Also using React and seeing the exact same as @kamranayub described. The session recording is displaying the last <option> in the <select>, regardless of the selection. In fact for us, once a selection is made, the displayed value in the recording is empty.