-
Notifications
You must be signed in to change notification settings - Fork 20.6k
Manipulation: Detect sneaky no-content replaceWith input #2206
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
Closed
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we make
buildFragment
private and change it signature, 5 arguments usually considered as bad API, even for helpers. One object as an argument?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is performance-critical code, I'm afraid wrapping it in an object might have a perf penalty (and it'll almost certainly be larger).
As for making it fully private, it seems like a good idea. We should do that with almost everything that's not documented IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need proof for that statement
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The burden of proof is on the person that wants to introduce a change, i.e. here it's you. ;)
I just said it might introduce a perf penalty, I don't know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the bigger issue is why
buildFragment
is so complex that it needs that many args, and why we had to add another one. I thought for sure there would be an easier way to deal with this crazy edge case, but couldn't find a reasonable way around it. It is a pretty hot path in our code.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In short, because of self-manipulation.
.replaceWith
is the worst offender, but it's basically a problem any time there's a nonempty intersection between the input and the context collection, and exacerbated by the fact that.domManip
lies in between the outer method andbuildFragment
.That said, the
scripts
parameter is probably unnecessary and safe to remove whenbuildFragment
is made private. In fact, that's an opportunity to look at more sweeping changes... why exactly do we pluck nodes from the DOM and into a fragment inbuildFragment
instead of.domManip
anyway? It's an operation thatparseHTML
has to undo!