Third->third line issues

[jonathanKingston]

I'm seeing when loading:

• https://www.wikipedia.org/
• searching sdsd
• getting: https://en.wikipedia.org/wiki/Special:Search?search=sdsd&go=Go&searchToken=e4s8zqqpwutej8y7gvkerdca6
• clicking first result: https://en.wikipedia.org/wiki/South_Dakota_School_for_the_Deaf

This gets the following:

{
  "en.wikibooks.org": {
    "hostname": "en.wikibooks.org",
    "favicon": "",
    "firstPartyHostnames": [
      "en.wikipedia.org"
    ],
    "firstParty": false,
    "thirdParties": []
  },
  "en.wikipedia.org": {
    "hostname": "en.wikipedia.org",
    "favicon": "https://en.wikipedia.org/static/favicon/wikipedia.ico",
    "firstPartyHostnames": [
      "www.wikipedia.org",
      "en.wikipedia.org"
    ],
    "firstParty": false,
    "thirdParties": []
  },
  "login.wikimedia.org": {
    "hostname": "login.wikimedia.org",
    "favicon": "",
    "firstPartyHostnames": [
      "en.wikipedia.org"
    ],
    "firstParty": false,
    "thirdParties": []
  },
  "meta.wikimedia.org": {
    "hostname": "meta.wikimedia.org",
    "favicon": "",
    "firstPartyHostnames": [
      "en.wikipedia.org"
    ],
    "firstParty": false,
    "thirdParties": []
  },
  "upload.wikimedia.org": {
    "hostname": "upload.wikimedia.org",
    "favicon": "",
    "firstPartyHostnames": [
      "www.wikipedia.org",
      "en.wikipedia.org"
    ],
    "firstParty": false,
    "thirdParties": []
  },
  "www.wikipedia.org": {
    "hostname": "www.wikipedia.org",
    "favicon": "https://www.wikipedia.org/static/favicon/wikipedia.ico",
    "firstPartyHostnames": [
      "www.wikipedia.org"
    ],
    "firstParty": false,
    "thirdParties": []
  }
}

So for some reason we are seeing third parties having third parties which isn't expected. We then are not rendering third->third parties which maybe we should do anyway (not that the data should ever do this - this could be part of the ft+tp fix).

[biancadanforth]

I believe this is a combination of first party as third party #110 and also our recent change from using response.originUrl instead of response.documentUrl in PR #155 . The latter can give us a third party (let's call it Site A) as the origin URL linking to another third party (Site B). If Site A is on the allowlist for its original first party site (and is therefore hidden), we can see these detached nodes.

[jonathanKingston]

My initial hunch as I mentioned on slack is that the code there didn't make anything worse due to documentUrl actually being wrong for certain cases but it perhaps just appeared less wrong.

Perhaps the assumption of non visible tabs are a third party should be questioned more.

[biancadanforth]

I agree it was the right decision to change to originUrl, we now just need to make sure we handle third parties making third party requests in the setThirdParty logic.

[jonathanKingston]

@biancadanforth I'm still testing my patch however I think it solves a lot of the issues we have been having here.

[jonathanKingston]

Should be fixed with latest patch.