Resize Stops Working after Browser Back #247
Comments
|
I'm in a similar boat to @yucho. Can this be merged in? |
|
Please prepare a PR for this and I will take a look at it then. |
|
Wow, didn't expect this resurrection. I'll work on it when I get a chance! |
mendelk
added a commit
to mendelk/react-textarea-autosize
that referenced
this issue
Jul 28, 2020
In situations where the `document.body` was replaced, the check if `hiddenTextarea.parentNode === null` would return `false` even if in fact the _new_ `document.body` had no current `hiddenTextarea`, thus requiring a new one to be appended. The new logic checks if `!document.body.contains(hiddenTextarea)`, which should account for the _current_ `document.body`. An alternative solution would be to check if `hiddenTextarea.isConnected`, which is probably more performant. Unfortunately, this property is not present in IE. Yet another solution which _might_ be more performant at the expense of being more verbose, is to recursively check if `hiddenTextarea.parentNode === null` to confirm that it's in fact still in the _current_ DOM tree. Fixes Andarist#247
mendelk
added a commit
to mendelk/react-textarea-autosize
that referenced
this issue
Jul 28, 2020
In situations where the `document.body` was replaced, the check if `hiddenTextarea.parentNode === null` would return `false` even if in fact the _new_ `document.body` had no current `hiddenTextarea`, thus requiring a new one to be appended. The new logic checks if `!document.body.contains(hiddenTextarea)`, which should account for the _current_ `document.body`. An alternative solution would be to check if `hiddenTextarea.isConnected`, which is probably more performant. Unfortunately, this property is not present in IE. Yet another solution which _might_ be more performant at the expense of being more verbose, is to recursively check if `hiddenTextarea.parentNode === null` to confirm that it's in fact still in the _current_ DOM tree. Fixes Andarist#247
mendelk
added a commit
to mendelk/react-textarea-autosize
that referenced
this issue
Jul 28, 2020
In situations where the `document.body` was replaced, the check if `hiddenTextarea.parentNode === null` would return `false` even if in fact the _new_ `document.body` had no current `hiddenTextarea`, thus requiring a new one to be appended. The new logic checks if `!document.body.contains(hiddenTextarea)`, which should account for the _current_ `document.body`. An alternative solution would be to check if `hiddenTextarea.isConnected`, which is probably more performant. Unfortunately, this property is not present in IE. Yet another solution which _might_ be more performant at the expense of being more verbose, is to recursively check if `hiddenTextarea.parentNode === null` to confirm that it's in fact still in the _current_ DOM tree. Fixes Andarist#247
mendelk
added a commit
to mendelk/react-textarea-autosize
that referenced
this issue
Jul 28, 2020
In situations where the `document.body` was replaced, the check if `hiddenTextarea.parentNode === null` would return `false` even if in fact the _new_ `document.body` had no current `hiddenTextarea`, thus requiring a new one to be appended. The new logic checks if `!document.body.contains(hiddenTextarea)`, which should account for the _current_ `document.body`. An alternative solution would be to check if `hiddenTextarea.isConnected`, which is probably more performant. Unfortunately, this property is not present in IE. Yet another solution which _might_ be more performant at the expense of being more verbose, is to recursively check if `hiddenTextarea.parentNode === null` to confirm that it's in fact still in the _current_ DOM tree. Fixes Andarist#247
mendelk
pushed a commit
to mendelk/react-textarea-autosize
that referenced
this issue
Jul 28, 2020
In situations where the `document.body` was replaced, the check if `hiddenTextarea.parentNode === null` would return `false` even if in fact the _new_ `document.body` had no current `hiddenTextarea`, thus requiring a new one to be appended. The new logic checks if `!document.body.contains(hiddenTextarea)`, which should account for the _current_ `document.body`. An alternative solution would be to check if `hiddenTextarea.isConnected`, which is probably more performant. Unfortunately, this property is not present in IE. Yet another solution which _might_ be more performant at the expense of being more verbose, is to recursively check if `hiddenTextarea.parentNode === null` to confirm that it's in fact still in the _current_ DOM tree. Fixes Andarist#247
mendelk
added a commit
to mendelk/react-textarea-autosize
that referenced
this issue
Jul 28, 2020
In situations where the `document.body` was replaced, the check if `hiddenTextarea.parentNode === null` would return `false` even if in fact the _new_ `document.body` had no current `hiddenTextarea`, thus requiring a new one to be appended. The new logic checks if `!document.body.contains(hiddenTextarea)`, which should account for the _current_ `document.body`. An alternative solution would be to check if `hiddenTextarea.isConnected`, which is probably more performant. Unfortunately, this property is not present in IE. Yet another solution which _might_ be more performant at the expense of being more verbose, is to recursively check if `hiddenTextarea.parentNode === null` to confirm that it's in fact still in the _current_ DOM tree. Fixes Andarist#247
mendelk
added a commit
to mendelk/react-textarea-autosize
that referenced
this issue
Jul 28, 2020
In situations where the `document.body` was replaced, the check if `hiddenTextarea.parentNode === null` would return `false` even if in fact the _new_ `document.body` had no current `hiddenTextarea`, thus requiring a new one to be appended. The new logic checks if `!document.body.contains(hiddenTextarea)`, which should account for the _current_ `document.body`. An alternative solution would be to check if `hiddenTextarea.isConnected`, which is probably more performant. Unfortunately, this property is not present in IE. Yet another solution which _might_ be more performant at the expense of being more verbose, is to recursively check if `hiddenTextarea.parentNode === null` to confirm that it's in fact still in the _current_ DOM tree. Fixes Andarist#247
|
Sorry for the spam. @yucho Beat you to it :) |
derrickreimer
pushed a commit
to svycal/react-textarea-autosize
that referenced
this issue
Feb 28, 2021
In situations where the `document.body` was replaced, the check if `hiddenTextarea.parentNode === null` would return `false` even if in fact the _new_ `document.body` had no current `hiddenTextarea`, thus requiring a new one to be appended. The new logic checks if `!document.body.contains(hiddenTextarea)`, which should account for the _current_ `document.body`. An alternative solution would be to check if `hiddenTextarea.isConnected`, which is probably more performant. Unfortunately, this property is not present in IE. Yet another solution which _might_ be more performant at the expense of being more verbose, is to recursively check if `hiddenTextarea.parentNode === null` to confirm that it's in fact still in the _current_ DOM tree. Fixes Andarist#247
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First off, I wanna say thanks for this awesome module! I'm thoroughly happy with it. Now, the issue I'm experiencing might be specific to my project because I'm using
react-routerandturbolinks. After navigating through pages via browser back/forward, resizing no longer works.I did some debugging and found out the cause. Sometimes, the browser creates a new
document.body, buthiddenTextareakeeps pointing at oldbody(and hence causing memory leak. Not sure where this behavior is from, BFCache might be the culprit here).The quick fix I found is to change the following statement in
calculateNodeHeight.jsThis way, you can always check for the latest
bodyto see whether or nothiddenTextareaexists in the currentbodyinstance. There might be a better way, but this is a one-liner fix.If you'd like, I can quickly make the change, add some tests, and submit a PR. Let me know what you think :)
The text was updated successfully, but these errors were encountered: