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 r###lt 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 r###lts, 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 r###lts from that IP address, don't click the block button.

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

Can you give an example r###lts 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 r###lts 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 R###lts.

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([ghhr###lt]), .irc_but_r:not([ghhr###lt]), .irc_ab:not([ghhr###lt]), .irc_but_pdfr:not([ghhr###lt])');

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 r###lt?