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

NEW
Unassigned

Status

()

Core
Permission Manager
2 years ago
2 years ago

People

(Reporter: Loic, Unassigned)

Tracking

({ux-error-prevention})

42 Branch
ux-error-prevention
Points:
---

Firefox Tracking Flags

(firefox41 unaffected, firefox42-, firefox43-, firefox44-, firefox45-, firefox46-, firefox47-, firefox-esr45-)

Details

(Reporter)

Description

2 years ago
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
(Reporter)

Updated

2 years ago
status-firefox41: --- → unaffected
tracking-firefox42: --- → ?
tracking-firefox43: --- → ?
tracking-firefox44: --- → ?
Flags: needinfo?(michael)

Comment 1

2 years ago
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
Blocks: 1165263
Keywords: ux-error-prevention
The UI could probably be improved, but the new permissions behavior (of treating http://example.com and https://example.com differently) is expected.
Flags: needinfo?(michael)
(Reporter)

Comment 3

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

Comment 4

2 years ago
So is this INVALID?
Not tracking then.
tracking-firefox42: ? → -
tracking-firefox43: ? → -
tracking-firefox44: ? → -

Updated

2 years ago
Duplicate of this bug: 1220350

Comment 7

2 years ago
(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.
Has Regression Range: --- → yes
Flags: needinfo?(michael)
OS: Unspecified → All
Hardware: Unspecified → All
(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.
Flags: needinfo?(michael)

Updated

2 years ago
Duplicate of this bug: 1221909

Comment 10

2 years ago
(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

2 years ago
[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.
tracking-firefox45: --- → ?
tracking-firefox46: --- → ?
tracking-firefox47: --- → ?
tracking-firefox-esr45: --- → ?
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?
Flags: needinfo?(josh)
I don't believe Monica is involved any more. This doesn't sound like something that requires tracking to me.
Flags: needinfo?(josh)
We do not feel the need to track this based on the comments.
tracking-firefox45: ? → -
tracking-firefox46: ? → -
tracking-firefox47: ? → -
tracking-firefox-esr45: ? → -
Keywords: regression
(Reporter)

Updated

2 years ago
Duplicate of this bug: 1294673
You need to log in before you can comment on or make changes to this bug.