STR:

• set network.cookie.cookieBehavior=5
• connect to https://www.pixnet.net/
• click "登入" to log in, fill correct account and password
• when it redirects back to home page, it's still not logged in, and the log-in button doesn't work anymore.

See bug 1316019 comment 1 for more information.

I see that this website does a test to see whether third-party cookies are enabled (see how it loads this iframe). Have you tried testing with the privacy.dynamic_firstparty.limitForeign pref?

(In reply to :ehsan akhgari from comment #1)

I see that this website does a test to see whether third-party cookies are enabled (see how it loads this iframe). Have you tried testing with the privacy.dynamic_firstparty.limitForeign pref?

Yes, the pref doesn't affect the test result.

Can you do me a favour? Could you check to see what attributes do the cookies that the login on this site relies to be accessible in the 3p context have as they are being set? I'm specifically interested to know if each cookie has any or all of the following attributes, HttpOnly, SameSite and Secure. Thanks!

The table contains cookie accepted by Firefox from submitting login-form until redirected back to home page.

And this table shows the cookies SENT related to above table:

So the heuristic I'm thinking about is roughly like this:

• https://foo.com redirects to https://bar.com in the top-level as a result of user interaction. (Here, https://panel.pixnet.cc to https://www.pixnet.net)
• https://bar.com makes a network connection to http://foo.com within 2 minutes after that.
• If bar.com has no cookies with firstPartyDomain=foo.com copy HttpOnly/Secure/SameSite=None cookies from bar.com's cookie jar into foo.com's cookie jar (the foo.com cookie jar means firstPartyDomain=foo.com). This should pick up PIXCCSESSION.

Not sure why you have many PIXCCSESSION cookies, but perhaps this could serve as a baseline for a heuristic to fix this kind of breakage...

(In reply to :ehsan akhgari from comment #5)

So the heuristic I'm thinking about is roughly like this:

• https://foo.com redirects to https://bar.com in the top-level as a result of user interaction. (Here, https://panel.pixnet.cc to https://www.pixnet.net)
• https://bar.com makes a network connection to http://foo.com within 2 minutes after that.
• If bar.com has no cookies with firstPartyDomain=foo.com copy HttpOnly/Secure/SameSite=None cookies from bar.com's cookie jar into foo.com's cookie jar (the foo.com cookie jar means firstPartyDomain=foo.com). This should pick up PIXCCSESSION.

Not sure why you have many PIXCCSESSION cookies, but perhaps this could serve as a baseline for a heuristic to fix this kind of breakage...

In this case, I manually clone PIXCCSESSION (host=.pixnet.cc, isSecure=1, isHttpOnly=1, sameSite=0) and set originAttributes to ^firstPartyDomain=pixnet.net. And this fixes the issue.

I have some approaches to implement this copy mechanism.

1. clone cookies from first-party cookie jar (FPD="") to partitioned cookie jar (FPD="pixnet.net")
   This fixes this issue, but makes another issue for sign-out because the same cookies in different cookie jars are not synchronized.

2. read cookies from first-party cookie jar (FPD="") directly
   This fixes bug 1616612 for both sign-in/out issue, but will make pixnet.net failure to log-in.
   Because after successfully login, pixnet.cc will write an additional cookie to partitioned cookie jar (FPD="pixnet.net"), which stops from reading from first-party cookie jar (FPD="") in the following requests because the cookie jar is not empty anymore.

To solve above issues completely, we might need a "reference cookie" that can point to cookies in another cookie jar.

https://hg.mozilla.org/mozilla-central/rev/663509b17a83

Heuristic description:
When redirection happens on site B to site A, check:

• if privacy.restrict3rdpartystorage.heuristic.recently_visited is set to true
• if dFPI is current cookie policy
• if both site A and B have user interaction and were visited within 10 minutes (privacy.restrict3rdpartystorage.heuristic.recently_visited_time)
  The permission to access first-party sotrage will be granted for 30 days (privacy.restrict3rdpartystorage.expiration_visited) if all above conditions are met.

Reproduced the initial issue described in comment 0 using an old Nightly build from 2020-02-19, verified that there the user is successfully logged in into pixnet.net using Firefox 77.0b7 across platforms (Windows 10 64bit, macOS 10.15.5 beta 3 and Ubuntu 18.04 64bit).