I assume that is a rhetorical question, but just in case it isn't:

Firefox's "Set Cookie" permission relates to what kind of cookies sites can set, not what kinds of cookies are removed.

• Block => no cookies can be set
• Allow for Session => only session cookies can be set (expiration date is ignored)
• Allow => either session or persistent cookies can be set

If you do not take advantage of the site's option to "remember" you by creating a persistent cookie, you end up with a session cookie. And we know what happens with those.

If you don't want to use the wp-login page to set a persistent cookie, you could look for an add-on that replaces the built-in behaviors with ones more to your liking.

Note that you must remove existing cookies from a website when you make changes to the cookie permissions. Changes only apply to newly created cookies. It is possible that other domains are involved.

>>Note that you must remove existing cookies from a website when you make changes to the cookie permissions.

Yup, I know - but thanks for pointing it out. I'm clearing all cookies between each test.

>>If you don't want to use the wp-login page to set a persistent cookie

As stated quite a few times now, this is just *one* example site where this is occurring. There are several others (i.e. the NAS) where I cannot post a login for public testing, nor is there an alternative way to login. "If you don't want to use wp-login" is only relevant to this single case - not all cases.

>>I assume that is a rhetorical question, but just in case it isn't

It isn't rhetorical. Again, from an under-the-hood implementation perspective I do understand the logic. But as all developers know, what makes sense in terms of implementation rarely overlaps with what makes sense from a usability perspective. In this case, Firefox seems to have session cookies behaving one way when you "allow all," but a different way when you "allow some." While this may indeed make sense if you examine how each separate option is defined, usability-wise, it's very inconsistent. That's why I was confused enough after moving to Firefox that I needed to start this thread, and presumably why Chrome was implemented to behave predictably: session cookies are retained across browser restarts if you ask to 'restore tabs,' regardless of whether you choose to retain all cookies or only some. Firefox behaves one way in one case, a different way in the other.

But anyway, it looks like we've reached a conclusion of what's going on. Obviously I think it's pretty poor design, but now that I know what's happening I'll do my best to find a way to workaround it & get it behaving as I'd expect.

Maybe someone should file a bug? Sometimes making things work more like Chrome is a considered a good reason for a change. Not that such changes come quickly... and the user interface aspects of giving people more choices can really bog things down.

It's hard to decide exactly what the new behavior should be. Right now, the code dumps all the cookies from the session history file if you have Firefox set to "Keep until: I close Firefox" (see source code).

Checking every cookie against the permissions database might not be acceptable at shutdown for performance reasons. Having Firefox check earlier and not bother storing unwanted session cookies in the first place would make more sense for your purposes, but then a crash recovery would have less functionality.

Or perhaps the cookies could be marked in some manner when they are added to the file so Firefox knows which ones to remove at shutdown without having to look it up again. This assumes you didn't change the exceptions list between the time the cookie was set and shutdown, which may not be a good assumption.

A fourth possibility is to defer the flushing of unwanted session cookies to the next startup. This has privacy implications because your session history file would contain live cookies for many more sites after you exit Firefox. But it would be a reasonable compromise if it didn't delay tab loading too long when restoring the previous session.

I'm sure the developers have many other considerations...

All are interesting considerations - though unfortunately a bit deeper than I have the time/flexibility to delve at this point. Moreso I'd hoped (originally) to determine if there was some configuration (i.e. about:config) that could be used to get Firefox to behave "consistently" (aka like Chrome), but since it seems it natively cannot, I just figured I'd voice my opinion before moving on. Personally, either I'll just deal with the exceptions or find a workaround, but as you say, flushing out a core solution & waiting for its implementation can be very drawn-out.

In any case, thanks for all the replies. And please feel free to pass on my feedback, as I'd be extremely surprised if it weren't affecting others as well (there are definitely quite a few threads with confusion about "cookie retention=until close" not behaving as people expect, I read through half a dozen or so before posting this myself).

Thanks again~ :)