FQDNs handled incorrectly

[bmwiedemann]

DNS standards say that proper FQDNs end in a dot (.) to signify the root zone.
Other names like foo.bar might or might not be evaluated relative to the local machine's search domain, depending on local configuration. They might give unexpected results after new TLDs like .box or .cloud get delegated by ICANN. This is why I try to use a trailing dot everywhere (even if others usually dont).

However, accessing pages like https://www.google.com./ with NoScript active, only offers to block or allow the "com." domain.
This would pretty much defeat the purpose of NoScript.

IMHO, https://www.google.com./ should be handled the same as https://www.google.com/

Might need careful testing if relative internal domains would be negatively affected by such a change.

[Giorgio Maone]

IMHO, https://www.google.com./ should be handled the same as https://www.google.com/

Do you mean they should be treated equally, but not as if they're were the same site, right?
So, in order to let google.com actually work, you should set as TRUSTED at least two entries: both .google.com. (for your top site) and .google.com (for links from google.com. to other domains or absolute URLs), correct?

[bmwiedemann]

Either way would be an improvement of the current state.
I guess, they could even be treated the same (to save me managing even more rules).
Overlap of FQDNs with private relative names will be rare
and if it happens, it should not be too bad either.