402778 - Allow scope widening of cookie exceptions

Status: RESOLVED FIXED

(Camino Graveyard :: Preferences, enhancement)

Description

[Stuart Morgan]

I find myself periodically having to manually edit hostperm.1 to expand the scope of cookie block rules from ad servers that rotate through subdomains; i.e., I've blocked foo1.bar.com, foo2.bar.com, foo7.bar.com, foo19.bar.com, etc., and want to just block bar.com outright.

I was thinking it might be nice to have a context menu item for each entry in the exception list that would promote the exception. So the context menu for foo2.bar.com would have something like "Apply exception to all of bar.com"

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I support this and proposed something like it a long time ago, but it was sort of shrugged off.

With this UI, I would expect it to then eliminate all of the "duplicate" entries for foo1, foo2, and so forth.

Another possible UI might be to make the entries in "Website" column editable, which is less ugly than the CM/action menu route, but more prone to allowing users to mess things up.

Comment 2

[Chris Lawson (gone)]

Yeah, this seems like a really good idea. I do the same thing, but I did most of it about a year ago and haven't really thought about it much since then. If I did, though, I'd definitely be finding it annoying not to be able to do that directly in Camino's UI somewhere.

How difficult would it be to do proper validation of the "Website" column? Would trying to make an NSURL out of the text in there be sufficient? I think we do that in at least one other instance where we're interested in validating URI input (the homepage field in prefs, maybe?).

Comment 3

[Stuart Morgan]

(In reply to comment #1)
> With this UI, I would expect it to then eliminate all of the "duplicate"
> entries for foo1, foo2, and so forth.

Right, we'd want to find all subdomains that have the same permission, and remove them.

(In reply to comment #2)
> How difficult would it be to do proper validation of the "Website" column?
> Would trying to make an NSURL out of the text in there be sufficient?

What does "proper" mean to you here? After all, "com" is technically a valid entry.

Comment 4

[Chris Lawson (gone)]

(In reply to comment #3)
> > How difficult would it be to do proper validation of the "Website" column?
> > Would trying to make an NSURL out of the text in there be sufficient?
> 
> What does "proper" mean to you here? After all, "com" is technically a valid
> entry.

Hrm. That's true, and it throws a bit of a wrench in the idea of validating based on whether you can make a URI out of it. It'd be nice to have the ability to edit that column directly (I think a contextual menu option for this is sort of an interim solution at best), but as Smokey points out, it'd be difficult to do it without allowing users to make dumb mistakes.

How about validating based on { whether you can make a URI out of it } OR { if it's a valid TLD } ? That seems like it would be reasonably easy to code, and the list of valid TLDs doesn't change very often, so it would be low-maintenance. (Alternatively, and I'd need to look at the code/docs to see if this would work, we could prepend a string like "example." to the input and then validate the result as a URI.)

I'm just really keen on the idea of that column being editable while still providing protection against user stupidity/typos.

Comment 5

[Stuart Morgan]

Attachment: fiv

This adds a new context item that expands the selected item one level, and strips out anything that is redundant as a result. I fixed a few other things that came up while I was doing this:
- I noticed that the caps of most of the cookie context menu don't follow menu style, so I fixed that.
- I discovered that despite my best efforts, I screwed up the sort order on shorter domains (which became really obvious when I was playing with this)
- I fixed a few style things in places I was already touching so that I could be both right and consistent with the immediate surroundings, since I hate adding more wrong style to a file that's already inconsistent.

Comment 6

[Stuart Morgan]

Attachment: nib

Comment 7

[Stuart Morgan]

Attachment: fix v2

Oops, messed up the case where there was already a policy for the general host.

Comment 8

[Mark Mentovai]

Comment on attachment 295306 [details] [diff] [review]
fix v2

>   if (selfIndex < otherIndex)
>-    return NSOrderedDescending;
>-  else if (selfIndex > otherIndex)
>     return NSOrderedAscending;
>+  else if (selfIndex > otherIndex)
>+    return NSOrderedDescending;

Oops, we got this wrong?

>+    if ([perm policy] == policy && [[perm host] hasSuffix:expandedHost])

expandedHost doesn't have a leading dot, so this might be too broad.

"expand" doesn't sound right to me, something that conveys DNS-ness (superdomain?) might be better.

>+- (NSString*)expandedHostForHost:(NSString*)host

This doesn't need to be an instance method.

>+    return (expandedHost != nil);

I had to read this section a few times to get what you're doing and why you did it this way.  There should be a comment to make clear that we only want the item enabled if there's 1 item and it's expandable, and we set a dummy title if it's disabled.

Comment 9

[Stuart Morgan]

Landed on trunk and MOZILLA_1_8_BRANCH with comments addressed.