1210379 - Allowing an exception in the cookie permission manager adds the prefix http:// and breaks the connection to some websites

Status: RESOLVED WORKSFORME

(Core :: Permission Manager, defect)

Description

[Loic]

STR:
1) Start a new profile (or delete all your cookies)
2) Open about:preferences#privacy
3) Set "Use custom settings for history > Accept third-party cookies: Never"
4) Allow "www.usarmyregistry.org" in the cookie exceptions list
5) Open http://armyhistory.org/the-registry-of-the-american-soldier/
6) Click on "Login here" (middle page) and log in with:
U:bugzilla
P:azerty123!

Result: error message "A system exception has occured."
http://i.imgur.com/ESZe6nj.jpg

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=443582420f2c6643112ebe3869c75294478c3f0b&tochange=fb346b9b9f9878df57fef570612ef043c7d2ba4e

Suspected bug: bug 1173523 or bug 1165263

Comment 1

[Alice0775 White]

It needs to allow https://www.usarmyregistry.org instead of "www.usarmyregistry.org"

Indeed, the UI is unkind and non-intuitive.

Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=443582420f2c&tochange=fb346b9b9f98

Regressed by : Bug 1165263

Comment 2

[Nika Layzell [:nika] (ni? for response)]

The UI could probably be improved, but the new permissions behavior (of treating http://example.com and https://example.com differently) is expected.

Comment 3

[Loic]

Ah yes, it's my fault, I forgot to add the domain as HTTPS instead of HTTP.

Comment 4

[(no longer active)]

So is this INVALID?

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Not tracking then.

Comment 7

[Gingerbread Man]

(In reply to Michael Layzell [:mystor] from comment #2)
> The UI could probably be improved, but the new permissions behavior (of
> treating http://example.com and https://example.com differently) is expected.

Previously, it was possible to enter foo.bar which would apply the exception to *.foo.bar. This was especially useful since it would apply to subdomains that aren't known or random, e.g. www1.foo.bar through www999.foo.bar. It's at best highly impractical to create individual exceptions for each subdomain, and at worst completely impossible.

Now,
1. It's possible to enter http*://example.com but the resulting exception is http://http*
2. It's possible to enter http://*.foo.bar and https://*.foo.bar, but the exceptions have no effect.

Comment 8

[Nika Layzell [:nika] (ni? for response)]

(In reply to Gingerbread Man from comment #7)
> (In reply to Michael Layzell [:mystor] from comment #2)
> > The UI could probably be improved, but the new permissions behavior (of
> > treating http://example.com and https://example.com differently) is expected.
> 
> Previously, it was possible to enter foo.bar which would apply the exception
> to *.foo.bar. This was especially useful since it would apply to subdomains
> that aren't known or random, e.g. www1.foo.bar through www999.foo.bar. It's
> at best highly impractical to create individual exceptions for each
> subdomain, and at worst completely impossible.
> 
> Now,
> 1. It's possible to enter http*://example.com but the resulting exception is
> http://http*
> 2. It's possible to enter http://*.foo.bar and https://*.foo.bar, but the
> exceptions have no effect.

I believe that adding an exception for http://foo.bar and https://foo.bar should have the same effect as the old foo.bar exception (assuming that the entries are only accessed with the http and https schemas). There is no wildcard support in the schema, but requests which used to be for permissions entries on a domain or any superdomain (up to the eTLD) should still perform the "wildcard"-like check even with the new system.

Comment 10

[Gingerbread Man]

(In reply to Michael Layzell [:mystor] from comment #8)
> I believe that adding an exception for http://foo.bar and https://foo.bar
> should have the same effect as the old foo.bar exception (assuming that the
> entries are only accessed with the http and https schemas). There is no
> wildcard support in the schema, but requests which used to be for
> permissions entries on a domain or any superdomain (up to the eTLD) should
> still perform the "wildcard"-like check even with the new system.

Thank you for the reply.

That's really confusing UI-wise, but the underlying functionality does indeed seem to work.

Shouldn't the * input be rejected, rather than creating invalid exceptions? Chrome and Opera support wildcards; users familiar with those browsers could end up saving exceptions that don't work.

Comment 11

[magicp]

[Tracking Requested - why for this release]:

In case of allowing any cookies, I can agree to the existing behavior. But in case of BLOCKING, I cannot agree to it.

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

At this point, is this counting as a regression? Or are we talking about suggesting UI improvements?
Josh you are a peer on this module, what do you think? Is Monica still the module owner?

Comment 13

[Josh Matthews [:jdm]]

I don't believe Monica is involved any more. This doesn't sound like something that requires tracking to me.

Comment 14

[Benjamin Kerensa [:bkerensa]]

We do not feel the need to track this based on the comments.

Comment 17

[Johann Hofmann [:johannh]]

This doesn't really seem actionable to me at this point, when you enter example.com we add the http and https prefixes automatically and that's the best we can do with an origin-based permission manager, for now.