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.

Sign up for GitHub

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

Jump to bottom

Add custom event for SponsorBlock #740

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add custom event for SponsorBlock #740

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions inject.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -453,6 +453,10 @@ function setupListener() {
if (coolDown) {
log("Speed event propagation blocked", 4);
event.stopImmediatePropagation();

// Send custom event for other extensions
const customEvent = new Event('videoSpeed_ratechange');
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already dispatch a custom event in:

videospeed/inject.js

Lines 704 to 707 in 113ec89

video.dispatchEvent(
new CustomEvent("ratechange", {
detail: { origin: "videoSpeed", speed: speedvalue }
})

Is that one not sufficient? Anything we can refactor? My intuition is that we should only be dispatching one event.

Copy link
Author

@ajayyy ajayyy Dec 16, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This custom event is being still being accepted by videospeed, which is then stopping propagation.

videospeed/inject.js

Lines 451 to 455 in 113ec89

"ratechange",
function (event) {
if (coolDown) {
log("Speed event propagation blocked", 4);
event.stopImmediatePropagation();

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per the current logic, that should only stop propagation is we're in cool-down phase and intentionally want to block another speed update, and proceed otherwise — right? You should be able to catch this event upstream.. what am I missing?

Copy link
Author

@ajayyy ajayyy Dec 19, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could the issue be that refreshCoolDown is getting called before the CustomEvent fires? That could cause coolDown to always not be false.

videospeed/inject.js

Lines 700 to 717 in 113ec89

function setSpeed(video, speed) {
log("setSpeed started: " + speed, 5);
var speedvalue = speed.toFixed(2);
if (tc.settings.forceLastSavedSpeed) {
video.dispatchEvent(
new CustomEvent("ratechange", {
detail: { origin: "videoSpeed", speed: speedvalue }
})
);
} else {
video.playbackRate = Number(speedvalue);
}
var speedIndicator = video.vsc.speedIndicator;
speedIndicator.textContent = speedvalue;
tc.settings.lastSpeed = speed;
refreshCoolDown();
log("setSpeed finished: " + speed, 5);
}

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After some testing, ratechange events do work when using the YouTube settings, and only don't get passed to my extension when the buttons on the video speed extension are pressed. So, it seems to be an issue with coolDown being true when it should not be.

Could you explain what the purpose of the cool down is?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ChadBailey implemented the logic and can provide full context. The short version though, if I recall correctly, it helps protect from auto-revert that some players invoke after we force a speed update.

I don't see a reason why we can't or shouldn't emit a ratechange event for button presses. That logic should not be subject to cooldown though; we don't want to throttle user-initiated changes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, that's what I was thinking. I was thinking that this custom event would allow videospeed to hide the ratechange from the website while still allowing other extensions to know about it. This way, it can still prevent the auto-revert issue,

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is a wayyy late reply, but I never saw this until now :( I figure I will give the explanation, better late than never.

This effort was done to fix a few problematic sites which would de-apply rate changes directly after applying them since the rate change did not originate from the site itself. If we are finding that this is having unintended side-effects, it may be a good idea to try and implement a second list similar to the disable-list which informs videospeed controller when to enable this behavior.

Copy link
Author

@ajayyy ajayyy Aug 12, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea, this is what I was thinking. If so, a disable-list like you said could work, or an extra event like the one added here so that it will not be picked up by the site itself, but only by "compatible" extensions.

The change here should have the least chance at breaking something since it just adds a new event

event.target.dispatchEvent(customEvent);
}
var video = event.target;

Expand Down