137199 - Wrong error message if no opt-in/opt-out policy

Status: VERIFIED INVALID

(SeaMonkey :: General, defect)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

1. Go to URL & Open Privacy tab
2. Click Policy, click Summary, and notice they work ok
3. Click Opt-in/opt-out

Expected results: message box saying no opt-in/opt-out page or something similar

Actual results: message saying "cannot load privacy policy"

This is really confusing because I just saw that policy loaded ok for the two
other buttons.

Is this needed for Policy as well, i.e. can that part be missing from the XML
policy file?

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Maybe "No opt-in/opt-out section in privacy policy" ?

Comment 2

[harishd]

Attachment: patch v1.1

Added error messages based on the action.

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 79015 [details] [diff] [review]
patch v1.1

I don't know JS but maybe "class" in the comment is wrong. Should it be called
"object"?

The comment on overrideMimeType() is misleading. It should say something like:
without this XMLHttpRequest hangs on certain sites that serve HTML instead of
XML.

PolicyFetchFailed is unneeded, I think. If we can't find or load policy
(errors) I think we can simply say cannot load policy.

The errors are still misleading, I think. If there is no opt-in/opt-out section
in the XML policy, we should not say cannot load. We should say something to
the effect I proposed.

Also if we found policy, doesn't the summary load always succeed?

And is the human readable patr is missing we should also say so, and not say
"cannot load".

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 79015 [details] [diff] [review]
patch v1.1

And add newline to end of .properties file.

Comment 5

[harishd]

>I don't know JS but maybe "class" in the comment is wrong. Should it be called
>"object"?
nsPolicyViewer is almost treated like a class and hence I called it so. I'm not
sure what's appropriate here.

>PolicyFetchFailed is unneeded, I think. If we can't find or load policy
>(errors) I think we can simply say cannot load policy.

There is a subtle difference between find and load. If the error message says 
"Cannot find policy" then it means that we weren't able to locate the policy. If
the message says "Cannot load policy" then it means that we've found the policy
but for some reason the load failed. So, IMO, this distinction is necessary.

Note: These error messages are temporary and are subject to change.

>Also if we found policy, doesn't the summary load always succeed?
What if the transformation failed for whatever reason? And what if the policy
had a wrong namespace? So, just finding a policy does not guarantee a successful
load.

>And is the human readable patr is missing we should also say so, and not say
>"cannot load".
For a normal user it wouldn't matter. However, I've to reiterate that these
error messages are subject to change.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

If the policy has wrong namespace, we transform without error and you get the
summary with headings only.

Comment 7

[harishd]

>If the policy has wrong namespace, we transform without error and you get the
>summary with headings only.

hmm...if that's the case then it should be a bug. For a wrong namespace we
should probably display an error ( "Cannot load policy for <URI>" ).

Comment 8

[harishd]

Attachment: patch v1.2 [ with Heikki's suggestions ]

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 79465 [details] [diff] [review]
patch v1.2 [ with Heikki's suggestions ]

r/sr=heikki

Add newline to properties file.

This patch has a part of the help button fix, which you might not want to check
in at this time. It does no harm, though.

nsPolicyReference is also new change, from another bug?

Comment 10

[harishd]

This bug is now covered in bugscape bug 13828. Marking this bug INVALID.

Comment 11

[James Cox]

-> vrfy