Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

textarea标签的默认文本在播放时翻倍出现 #112

Closed
ZITnew opened this issue Aug 7, 2019 · 2 comments
Closed

textarea标签的默认文本在播放时翻倍出现 #112

ZITnew opened this issue Aug 7, 2019 · 2 comments

Comments

@ZITnew
Copy link

ZITnew commented Aug 7, 2019

页面中存在textarea标签,若是标签中有默认的文本,不改动这些默认的文本,在播放时,这些未改动的文本会翻倍出现,比如,默认文本是hello,播放时就是hellohello

@YanJie-001
Copy link

这bug也没解决啊,怎么就完成了

eoghanmurray added a commit to eoghanmurray/rrweb that referenced this issue Nov 9, 2023
 - this is to fix up 'historical' recordings, as duplicate textarea content should no longer be being created at record time (see previous commit in this PR)
 - new test shows what the snapshot generated by previous versions of rrweb used to look like, hence 'bad'
 - original 0efe23f fix either didn't work or no longer works due to childNodes being appended subsequent to this part of the code
@eoghanmurray
Copy link
Contributor

I've a new fix and test for this as part of #1351
either this fix never worked, or else there was a regression since.

eoghanmurray added a commit to eoghanmurray/rrweb that referenced this issue Nov 28, 2023
 - this is to fix up 'historical' recordings, as duplicate textarea content should no longer be being created at record time (see previous commit in this PR)
 - new test shows what the snapshot generated by previous versions of rrweb used to look like, hence 'bad'
 - original 0efe23f fix either didn't work or no longer works due to childNodes being appended subsequent to this part of the code
eoghanmurray added a commit that referenced this issue Dec 1, 2023
* Fix serialization and mutation of <textarea> elements taking account the duality that the value can be set in either the child node, or in the value _parameter_ (not attribute)

* Backwards compatibility: Bug fix and regression test for #112
 - this is to fix up 'historical' recordings, as duplicate textarea content should no longer be being created at record time
 - new test shows what the snapshot generated by previous versions of rrweb used to look like, hence 'bad'
 - original 0efe23f fix either didn't work or no longer works due to childNodes being appended subsequent to this part of the code
 - during review, we also verified that the `_cssText` case should still be handled okay, as there's currently no scenario where csstext is present with css child nodes of a <style>

* Masking: Fix that textarea values were being missed by the masking system if the value was recorded as a child node
 - I didn't notice that form.html was used in other tests, so lucky that I noticed that those tests also should have the 'pre value' masked out

* Simplify by always storing the textarea value in the `.value` attribute (from it's DOM property) and not as a childNode. It should still be rebuilt as a childNode rather than a property
---------

Authored-by: eoghanmurray <eoghan@getthere.ie>
p-mazhnik pushed a commit to p-mazhnik/rrweb that referenced this issue Mar 12, 2024
jxiwang pushed a commit to amplitude/rrweb that referenced this issue Jul 31, 2024
* Fix serialization and mutation of <textarea> elements taking account the duality that the value can be set in either the child node, or in the value _parameter_ (not attribute)

* Backwards compatibility: Bug fix and regression test for rrweb-io#112
 - this is to fix up 'historical' recordings, as duplicate textarea content should no longer be being created at record time
 - new test shows what the snapshot generated by previous versions of rrweb used to look like, hence 'bad'
 - original 0efe23f fix either didn't work or no longer works due to childNodes being appended subsequent to this part of the code
 - during review, we also verified that the `_cssText` case should still be handled okay, as there's currently no scenario where csstext is present with css child nodes of a <style>

* Masking: Fix that textarea values were being missed by the masking system if the value was recorded as a child node
 - I didn't notice that form.html was used in other tests, so lucky that I noticed that those tests also should have the 'pre value' masked out

* Simplify by always storing the textarea value in the `.value` attribute (from it's DOM property) and not as a childNode. It should still be rebuilt as a childNode rather than a property
---------

Authored-by: eoghanmurray <eoghan@getthere.ie>
lewgordon-amplitude pushed a commit to amplitude/rrweb that referenced this issue Aug 1, 2024
* Fix serialization and mutation of <textarea> elements taking account the duality that the value can be set in either the child node, or in the value _parameter_ (not attribute)

* Backwards compatibility: Bug fix and regression test for rrweb-io#112
 - this is to fix up 'historical' recordings, as duplicate textarea content should no longer be being created at record time
 - new test shows what the snapshot generated by previous versions of rrweb used to look like, hence 'bad'
 - original 0efe23f fix either didn't work or no longer works due to childNodes being appended subsequent to this part of the code
 - during review, we also verified that the `_cssText` case should still be handled okay, as there's currently no scenario where csstext is present with css child nodes of a <style>

* Masking: Fix that textarea values were being missed by the masking system if the value was recorded as a child node
 - I didn't notice that form.html was used in other tests, so lucky that I noticed that those tests also should have the 'pre value' masked out

* Simplify by always storing the textarea value in the `.value` attribute (from it's DOM property) and not as a childNode. It should still be rebuilt as a childNode rather than a property
---------

Authored-by: eoghanmurray <eoghan@getthere.ie>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants