1232855 - navigator.cookieEnabled sometimes ignores per-site exceptions

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Commander]

Attachment: Blocked.png

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
Build ID: 20151103191810

Steps to reproduce:

1. Set the browser to block all cookies
2. Add an exception for stanfordhealthcare.org to set session cookies
3. Go to https://myhealth.stanfordhealthcare.org/



Actual results:

The front page complains that cookies are disabled (see Blocked.png).


Expected results:

The front page should have allowed logging in (see Enabled.png)

Comment 1

[Commander]

Attachment: Allowed.png

Comment 2

[Commander]

As far as I understand, all the cookie logic for this site is located in this file:

https://prodstaticcdn.stanfordhealthcare.org/resources/js/login.js

More specifically, the actual cookie check is done in this function:

var cookiesEnabled = function () {
    var cookieEnabled = (navigator.cookieEnabled) ? true : false;
    if (typeof navigator.cookieEnabled === "undefined" && !cookieEnabled) {
        document.cookie = "test";
        cookieEnabled = (document.cookie.indexOf("test") !== -1) ? true : false;
    }
    return (cookieEnabled);
};

This appears to be a standard way to check if cookies are enabled or not.
When I debugged this code in Firebug, I do see that navigator.cookieEnabled
returns "false", which is wrong.

The strange thing is that if I try a very similar code on this page,
I see that navigator.cookieEnabled correctly analyzes per-site exceptions.

http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_nav_cookieenabled

Thus, this appears to dependent on when exactly navigator.cookieEnabled
is called during the page loading process.

Comment 3

[Commander]

BTW, forgot to mention, if I set the browser to allow all cookies,
then this page works correctly as expected.

Comment 4

[Philip Chee]

The problem is that the new permissions model uses origins instead of hosts so http:// and https:// are different. However the data manager has not been updated to recognise this.

Bug 1180871 dealt with this by a workaround.
1. Go to https://myhealth.stanfordhealthcare.org/
2. Open Page Info View -> Page Info (CTRL-I)
3. Select the permissions tab.
4. Under Cookies choose Allow or Allow for Session.
5. Reload. Bingo!

From Bug 1180871 Comment 6
([e-mail])
> We need to implement the nsILoadContextInfo changes first anyway. I think it
> would be better to land and uplift this work done so far, and then fix the
> other bustage.

Perhaps it's time to fix the rest of the bustage?

Comment 5

[Commander]

(In reply to Philip Chee from comment #4)
> Bug 1180871 dealt with this by a workaround.
> 1. Go to https://myhealth.stanfordhealthcare.org/
> 2. Open Page Info View -> Page Info (CTRL-I)
> 3. Select the permissions tab.
> 4. Under Cookies choose Allow or Allow for Session.
> 5. Reload. Bingo!

Yes, that works.

> From Bug 1180871 Comment 6
> ([e-mail])
> > We need to implement the nsILoadContextInfo changes first anyway. I think it
> > would be better to land and uplift this work done so far, and then fix the
> > other bustage.
> 
> Perhaps it's time to fix the rest of the bustage?

The problem is that this website has several subdomains:

https://myhealth.stanfordhealthcare.org/
https://mychart.stanfordhealthcare.org/

With the Data Manager I would set a single permission for
the top domain (stanfordhealthcare.org) and be done with it.
The workaround described in comment #4 allows me to set
a permission only for the actual URL I am looking at, which
means myhealth.stanfordhealthcare.org. To get the website
to work, I had to open mychart.stanfordhealthcare.org separately
and use the workaround to allow cookies for it. It still
works, but using the Data Manager would be much simpler and
more straightforward.

Bottom line - yes, please fix the Data Manager :)

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to Philip Chee from comment #4)
> From Bug 1180871 Comment 6
> ([e-mail])
> > We need to implement the nsILoadContextInfo changes first anyway. I think it
> > would be better to land and uplift this work done so far, and then fix the
> > other bustage.
> 
> Perhaps it's time to fix the rest of the bustage?

and NEEDINFO NeilZZZ

No reply in over two months. I'm tempted to RESOLVE this bug INCOMPLETE. But I won't yet.

Comment 7

[Commander]

It appears that the Data Manager in SeaMonkey 2.46 now supports
specifying http:// or https:// when configuring cookie permissions
for sites. This resolves the issue reported in this bug, thus
I am going to mark it as resolved.