This happens sometimes. Fix it.

This is where we want to store the blacklisting of a user. The wiki lists several things that could be stored along with the unique data-ytid, but let's start simple. Here's a sample record:

{ "UCCat0XxZRbkylcy2MRSv9vg": "B" }

B is for blacklist, and W for a future whitelist feature. Using this format, each record takes 33 double bytes of memory (uglified).

I've just added the files hidden.png, hidden_75.png, and hidden_50.png to the project. The first is the original, the second is for top-level comments, and the third is for nested comments. Use these in the bit of code in the content script that hides comments.

This actually worked in the early verisons, but doesn't work now. Find out why.

The extension user is a Google Chrome user with this extension installed and enabled. We may want to know the data-ytid of this user if we add multi-user capability in the future. In a multi-user version, it would be useful to know who blacklisted who. Here's one way to find out the extension user:

var element = currentValue.querySelector('div.personal-item h3 a');
var userId = element.getAttribute('data-ytid');

This is a rather fragile path. Look for better options.

My best idea on "crowd-sourcing" blacklistings while preventing abuse involves keeping everything fully transparent. A person should be able to see who has blacklisted them, why, and for what. The why question is best answered with a list of reasons. Here's a draft:

• irrelevant - spam
• inappropriate - offensive, obscene
• hateful - attacks on groups
• insulting - attacks on individuals
• misleading - blatant lies and propaganda
• nonsensical - plain stupid, unintelligible

I'm undecided on whether it should be possible to select more than one of these when blacklisting a user for a comment. Also, let's make it clear that it's the comment, not the person that is described by these terms.

According to the docs, the extensions don't run in incognito windows by default. This suits our need well, because blacklisting a user could potentially give away what video a person has been watching. Make sure the extension is actually disabled in incognito mode.

To detect whether a window is in incognito mode, check the incognito property of the relevant tabs.Tab or windows.Window object.

If YouTube would change their HTML, this extension may crash. Look for a standard way of dealing with this problem. This may be it:

https://martinfowler.com/bliki/PageObject.html

Include the minimized jQuery file and make sure it works with the content script.

Here's how to do it in the manifest.json file:

"background": {
    "scripts" : [
        "background/eventListeners.js",
        "background/storage.js",
        "background/contextMenu.js"
        "background/main.js",
    ]
}

Not necessary yet, but it will be if the background script keeps growing. Note that the order the scripts are written in is the actual loading order.

Here's how a blacklisting needs to be stored to meet all our future requirements:

UC5XLvCbmVi4avGZCbswnUvg : {
    action: "B",
    author: "Felipe M.",
    reason: "hateful",
    video: "YUnm7utcGbM",
    comment: "z12nsd1jhoynyrnwm04chrkijr30svewy1c",
    user: "UCOkC6DT4HYTbNNPDjyYM2dg",
    time: "2017-04-02T01:21:19"
}

Only the key, action, and author are mandatory. The other fields will probably depend on user options. Whitelistings are stored similarily. If we'll ever receive these objects to a central logging server (with the user's consent, of course) we should probably log the IP too, to prevent abuse.

https://www.howtogeek.com/198964/how-to-view-the-source-code-of-a-chrome-extension/

Because it's fun and attractive. Ideally, we want to get the images from YouTube too. Websockets is probably the technology I need to learn to implement the live stream.

If the blacklisted commenter is the creator of the video, a blue blob will show after "Blacklisted user". Remove that blob.

If the blacklisting was successful (i.e. if the user ID was stored), show a success message. If the user clicked on something that is not a comment, or something happened so that the user ID was not found or couldn't be stored, tell the user that nothing was saved. Use a warning icon for the failure and a stop icon for success.

There are a number of problems with a multi-user version:

• Risk of abuse
• Performance/scalability
• Amount of work

Abuse

As the extension gains popularity​, it could become a tool for people to push an agenda, or to suppress dissidents. If the tool becomes sufficiently popular, some will use it to promote hate and propaganda. I can't think of a way to deal with this that will not include human moderators.

Performance/scalability

There is a performance cost in removing the posts of blacklisted users, and highlighting the posts of whitelisted users. The most performant way I can think of would be to collect the distinct data-ytid attributes on each loaded page, send them to a central server, and get them back with a number (-1 for blacklisted, 0 for neutral, 1 for whitelisted). I'm not sure how well this would scale when you get to millions of users in the blacklist/whitelist table. Also, I'm not sure if the server request would stall page loading, or if the page is first loaded with bozo comments which are then hidden.

Amount of work

Building the multi-user features it a much larger project that building a single-user version.

Add a enable/disable toggle to extension HTML page. Disabling the extension means showing all blacklisted comments.

Extensions can call other extensions. Using the multi-user features should be optional, especially if blacklisting is not anonymous. The multi-user extension could even be an extension of the single-user extension, so that it uses the same code for hiding comments etc. It just serves the single-user extension with blacklisted users from the cloud, on top of the ones in chrome.storage.

And when you click, mark the user W instead of B.

It should contain the following, in order:

• Logo
• Title text
• Version number
• Disable/enable toggle button
• Number of blacklisted users
• Number of comments hidden on page
• User's YouTube ID
• Link to extension in Web Store

What do we want to do the options page?

• View blacklisted and whitelisted users (by username).
• Remove users from list.
• Completely hide nested blacklisted comments.

We use inline CSS for display: none and other things. More these styles into youtube.css instead. I've already confirmed that the youtube.css is "alive", thanks to its reference in the manifest file.

The user name link shall be replaced by an unlinked bold text, saying Blacklisted user.

The comment filtering can be temporarily disabled using the Disable button. After pressing the button it changes to an Enable button, to turn filtering on again.

Just google "blacklist" and start collecting good ideas on blacklisting features.

There should be an option to reveal hidden comments with a single click. For simplicity, this should be one way only, not a toggle.

Background pages hogs resources all the time; event pages only when they need to. This extension only needs to be running when the user is on YouTube. Sometime in the early days of development, I went from an event page to a background page, because I couldn't get it to work otherwise. Find out if this is still true.

https://developer.chrome.com/extensions/event_pages

Figure out what this means:
http://www.theverge.com/2016/11/3/13504804/youtube-pinned-comments-moderation-tools-harassment

See if we can save a few lines and make the code more readable with jQuery.

When a user right-clicks a comment (or possibly only the name or avatar parts of the comment), an extra option should be added to Chrome's context menu. The option should be named Blacklist and it should have a middle finger icon next to it.

This task does not include making the click listener, or anything else, other than showing the context menu option over YouTube comments.

The menu appears to be added for each time you visit a YouTube page.

Only pages that start with https://www.youtube.com/watch?v= should trigger the extension. Look for ways to make the https://www. part optional, to add flexibility.

Make it a page action type extension.

Today, the getUsers() function is called repeatedly in a wasteful way. We need to cache the users for each open tab (with a YouTube watch page) for a configurable amount of time, so that whenever we're about to call getUsers() we first check the cache and compare the timestamps.

Is this a side-effect of this extension? Find out.

This may be a total showstopper. Currently, we're able to handle the first batch of comments, but if the user loads more comments (using the button at the bottom of the page), we need to trigger a new call to getUsers(). I don't know if this is possible.

https://developer.chrome.com/extensions/i18n

There's already a stub. Read blacklisted users from storage.sync.

Apart from the 19 pixel toolbar icon, we need a 16 pixel favicon, a 48 pixel icon for the extensions management page, and a 128 pixel icon for the Chrome Web Store.

"icons": {
    "16": "icon16.png",
    "48": "icon48.png",
    "128": "icon128.png"
},

See https://developer.chrome.com/extensions/manifest/icons

This is a content script method that receives an array of blacklisted users from the event page and adds a CSS class named blacklisted-user to the appropriate comment elements.

Whitelisted comments should have their username in orange (the opposite color to YouTube's blue). Other than that, there should be no difference to normal (non-blacklisted) comments. Less is more.

See #44 for a general discussion on whitelisting.

Hidden comment text shall be replaced by this message, written in gray italic:

This comment was removed because the user is blacklisted.

In the future, we may want to indicate the reason for blacklisting, if there is one.

If you open a new tab and go to a YouTube watch page, the getUsers response message is often empty, even if there are comments on the page. But if you click another video, the getUsers response message will be populated as expected.

Also, even if the response message is not completely empty, the body part will often be empty. These two phenomenas are probably related.

When you look at a YouTube watch page loading, you can see that the comments load when you scroll down to see them. So perhaps there is no comment section when the page first loads (but that doesn't explain why it works on subsequent pages).

It does trigger when you paste a YouTube page URL into a new tab, but not when you click on another link video on the page. Obviously, both scenarios should trigger the event page listener.

https://labs.detectify.com/2015/11/19/chrome-extensions-aka-total-absence-of-privacy/

Read this and write something about what people need to know about privacy with Chrome extensions in general, and this extension in particular. Be transparent on what this extension will do and won't do in terms of collecting user data and tracking users.

Due to an unfortunate design flaw in the chrome.contentmenu API, you get an error if you attempt to create a context menu item with an ID that already exists. I've had this happen many times as I've tried to deal with the loading of comments, where some event listeners will attempt to add the context menu in case it's not already added. Maybe this won't be a problem now, as I prune the event listeners to a minimum.

In any case, it seems best to always show the the context menu on YouTube watch pages, but to show it disabled when using it makes no sense. So show it once, then toggle between enable and disable. That shouldn't raise any errors. First I need to specify when to add it, when to enable it and when to disable it.

In the content script, write a method that collects all the distinct users on a page and returns them as an array of data-ytid values.

When hiding text, we must also hide the "Read more" link.