-
Notifications
You must be signed in to change notification settings - Fork 7.4k
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
feat: add several debugging aides #5854
Conversation
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.
Also, I don't think any PRs against video.js should be ignore:
.
@@ -553,6 +554,8 @@ videojs.computedStyle = computedStyle; | |||
*/ | |||
videojs.dom = Dom; | |||
|
|||
videojs.domData = DomData; |
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 am against this being in a production build of Video.js, though, I do see the usefulness of it when debugging.
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.
If we can have this be here during local dev but not when releasing, that's fine.
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.
For local development we can just import DomData (as long as we let it export elData
). I think that plugins could also benefit from being able to see what elData
they may be leaking, but I am not quite sure how to do that without exposing it here.
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.
Perhaps we can expose it somewhere else? or put elData
on the player somehow so that the player can remove it all on dispose?
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'm not sure we can safely expose it and not deal with consequences down the line or have issues with people fiddling with it and causing issues.
@@ -280,6 +280,7 @@ const EventedMixin = { | |||
// Use the same function ID as the listener so we can remove it later | |||
// it using the ID of the original listener. | |||
wrapper.guid = listener.guid; | |||
wrapper.original_ = listener.original_ || listener; |
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.
we'd want to make sure to null these out so that we're not leaking references.
@@ -44,6 +44,9 @@ export const bind = function(context, fn, uid) { | |||
// currently used in text tracks | |||
bound.guid = (uid) ? uid + '_' + fn.guid : fn.guid; | |||
|
|||
bound.original_ = fn.original_ || fn; |
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.
we should make sure to null these out when they're no longer needed.
After thinking about this more, maybe we just want to have another build target. Something like |
A debug build is fine, or having a rollup directive via envify or something that removes the exposing of domData when in production |
The issue in question #5858 |
TODO: Add some tests in this pull request to verify: