Canvas permission and HTTP auth still use FQDN isolation

In #15933 (moved), we relaxed our domain isolation to use TLD instead of FQDN, because FQDN isolation was breaking several sites. However, the HTTP auth and the canvas permissions were not using the same ThirdPartyUtil::GetFirstPartyHostForIsolation() API as everything else was.

We should fix their behavior to use TLD isolation for consistency. I bet some sites will still break due to FQDN isolated HTTP auth in particular..

added component::applications/tor browser owner::tbb-team priority::medium severity::normal status::new tbb-linkability tbb-usability-website type::defect labels

Trac:
Cc: N/A to gk

Trac:
Cc: gk to gk, brade, mcs

The FQDN HTTP auth check here might actually be the root cause of #14089 (moved).

Replying to mikeperry:

We should fix their behavior to use TLD isolation for consistency. I bet some sites will still break due to FQDN isolated HTTP auth in particular..

#16450 (moved) might be another case where this happens.

Ticket for adding to Mozilla first-party isolation effort.

Trac:
Reviewer: N/A to N/A
Severity: N/A to Normal
Sponsor: N/A to N/A

Do we have a testcase for this showing that it is still an issue? Even with the patches landed in mozilla52?

Trac:
Keywords: N/A deleted, tbb-linkability added

gk: Try making yourself an account on addons.mozilla.org and log in.

Trac:
Username: vynX

Trac:
Username: tokotoko
Cc: gk, brade, mcs to gk, brade, mcs, fdsfgs@krutt.org

mentioned in issue #16450 (moved)

moved to tpo/applications/tor-browser#15954