Greasy Fork

About blocking PDF images and websites with domain names being IP addresses

Hello, When the Enable 1-click blocking and always the partial domain options are checked, if the domain name is an IP address, the IP will be incorrectly treated as a domain name.

When the result of Google Image Search is a picture in a PDF file, the Block button does not appear.

The title has been modified.

This is already discussed in an earlier thread: https://greasyfork.org/en/forum/discussion/54791/x

Oh, it is this question, thank you for your reminder, please delete.

I have modified the issue.

I have modified the issue.

@sfwf said: When the Enable 1-click blocking and always the partial domain options are checked, if the domain name is an IP address, the IP will be incorrectly treated as a domain name.

I do not normally see IP address URLs in search results, so I have not tested this. I guess "partial" should be ignored for IP addresses; always the full IP should be blocked. That would be correct, wouldn't it? If you don't want to hide results from that IP address, don't click the block button.

When the result of Google Image Search is a picture in a PDF file, the Block button does not appear.

Can you give an example results link that returns a picture inside a PDF file? I haven't been able to figure out a way to see that.

Can you give an example results link that returns a picture inside a PDF file?

Please search https://www.adobe.com/content/dam/acom/en/accessibility/products/acrobat/pdfs/A9-accessible-pdf-from-word.pdf The first picture is PDF.

I also found that when the blocked domain name contains a port, the script will add the port to the block list. And the blocked picture at this time will not disappear, but will be darkened. I think the port should be ignored.

Please use image search to search Http://tu.1817tk.com:96/sqcaitu/bs01.jpg View Results.

PDF:

Okay, I've never seen them before, but yes: https://www.google.com/search?q=site:adobe.com/content/dam/acom/en/accessibility/products/acrobat/pdfs&source=lnms&tbm=isch

The fix only seems to need two changes but I haven't tested a lot of searches to make sure it doesn't break anything:

Line 394: var buttondivs = el.querySelectorAll('.irc_butc:not([ghhresult]), .irc_but_r:not([ghhresult]), .irc_ab:not([ghhresult]), .irc_but_pdfr:not([ghhresult])');

Line 1228: var ameta = viewer.parentNode.children[0].querySelector('._r3 a, span > a').href.split("/")[2];

Port Number:

Looks like we need a new line:

Line 1229: if (ameta.indexOf(":")> -1) ameta = ameta.substr(0,ameta.indexOf(":")); // Strip port number

This is important because a colon in a domain name is not really compatible with the ancient data structure used by the script. What follows the first : is supposed to be the block type. If it's not a p then it is treated as a regular block, which would explain the problem you've observed.

I also found that the address of the ftp protocol could not be blocked.

@sfwf said: I also found that the address of the ftp protocol could not be blocked.

I can look at that next month. Could you start a new discussion with an example query that retrieves an ftp result?