191920 - P3P Summary button does not work anymore

Status: VERIFIED FIXED

(Core :: XML, defect, P1)

Description

[harishd]

Jonas, please take a look at comment #31 (
http://bugzilla.mozilla.org/show_bug.cgi?id=177822#c31 ) in bug 177822.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Harish, where is the stylesheet linked from?  What is the URI used?  What _is_
"aProvider" at that point?

Comment 2

[harishd]

Boris, the style sheets ( *.xsl ) are under extensions/p3p/resources/content. We
select the appropriate style sheet based on the site you visit ( to reproduce
the problem go to www.ibm.com and click on pageInfo->Privacy->Summary ).
"aProvider" was empty at that point. However, in today's build I don't get any
assertions but the policy viewer window renders blank :-( 

Comment 3

[harishd]

Btw, the style sheet loading happens in nsPolicyViewer.js.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> nsPolicyViewer.js

This file does not exist in LXR, in my tree, or in the last patch attached to
bug 177822

> "aProvider" was empty at that point

That's almost certainly a bug in the chrome registration of the package.

So what _is_ the URI used to link to the sheet?  The exact URI?

Comment 5

[harishd]

>This file does not exist in LXR, in my tree, or in the last patch attached to
>bug 177822

This is not in mozilla tree yet. However, it should be available in patch v1.1
in bug 177822. Sorry about that.

>So what _is_ the URI used to link to the sheet?

chrome://communicator/content/p3p/p3p200201.xsl"

Comment 6

[harishd]

With the recent build ( yesterday's ) I see "content" for aProvider and
"p3p/p3p200201.xsl" for aFile. That is, I don't hit the error  NS_ERROR("unknown
provider"); anymore but the policy viewer window renders blank.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm... with that URL you should never be hitting the "unknown provider"
assertion, since that has a filename...

Comment 8

[harishd]

Boris: Like I said I don't see the "Unknown provider" problem anymore however
the policy viewer window renders blank.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

i wonder if this could be bug 185498. Harish, does the P3P code still use the
old js-interface with transformDocument?

Comment 10

[harishd]

>i wonder if this could be bug 185498. Harish, does the P3P code still use the
>old js-interface with transformDocument?

Looks like it. If this is what you meant:

  xsltp.transformDocument(source, style, result, null);

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

exactly, i'm checking in bug 185498 as soon as the tree opens and then we should
see if that was it.

Comment 12

[harishd]

Jonas: This bug still exists even after your checkin to bug 185498.

Comment 13

[Grace Bush]

taking P3P bugs

Comment 14

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

P3P code is now in the Mozilla tree, but not yet built by default. To build,
give this option to configure:

--enable-extensions=default,p3p

Comment 15

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

To reproduce, go to a P3P supporting site (see
http://www.w3.org/P3P/compliant_sites ), open the Page Info dialog (View > Page
Info), select the Privacy tab, and click the Summary button.

Comment 16

[Peter Van der Beken [:peterv]]

Pfff, this is so not an XSLT bug. That was clear even from before the bug was
filed: the stylesheet is not loading. Jonas: feel free to reassign as needed.

Comment 17

[Peter Van der Beken [:peterv]]

Trying to load chrome://communicator/content/p3p/p3p200012.xsl in a recent
version of Mozilla just shows a blank page.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

oh, thanks for investigating! Reassining to harish then, probably a packaging
problem? On the bright side this should be an easy fix then :-)

Comment 19

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

Attachment: Fix some JS errors

I can load the XSLT files from the chrome URLs just fine with recent builds.

What happens though (after applying this patch) is that I get JS errors from
mailNavigatorOverlay.xul! And then a blank summary page... This seems bizarre,
to say the least...

I tested with http://www.1-800-buy-cheap-phentermine-online.com/ , click lock
icon, select Privacy tab (and wait for the progress control to finish?) and
click Summary button.

Comment 20

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

Attachment: www.att.net "empty" privacy summary saved

It seems like we actually do the transformation, but we fail to show the result
document. Save Page As saves the document, and DOM Inspector can also "see" the
transformed document. 

Another strange thing is that for some reason the transformed document has
question marks in places where I would expect section numbers.

Btw, one more minor nit in the JS: the document.load() does not take mime type
arg, remove |, "text/xml"|.

Comment 21

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 118836 [details] [diff] [review]
Fix some JS errors

r=sicking on this one

Comment 22

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

Now I am hitting the "unknown provider" assertion/error as well with today's
build. I don't know what changed since my last pull that caused this. 

I can make this "work" again (i.e. to get the "blank" summary window) by forcing
nsCodebasePrincipal::GetOrigin() to go through the else clause, ie. GetSpec() so
that the chrome URL for the XSLT file does not get truncated to
"chrome://communicator". I am wondering why GetHostPort() returns success for
chrome URLs...

Comment 23

[harishd]

>Now I am hitting the "unknown provider" assertion/error as well with today's
>build. 

This is the error I reported in
http://bugzilla.mozilla.org/show_bug.cgi?id=177822#c31.

Comment 24

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

*** Bug 203851 has been marked as a duplicate of this bug. ***

Comment 25

[Samir Gehani]

adt: nsbeta1+/adt3

Comment 26

[Peter Van der Beken [:peterv]]

I'm stuck at the same point as comment 22. Can we resolve the problems with
nsCodebasePrincipal and chrome URIs? I'll try to figure out why the transform
doesn't result in something visible.

Comment 27

[Peter Van der Beken [:peterv]]

Attachment: WIP v1

This fixes most of the issues. The policy shows up, but we're missing
scrollbars. Note that this does not fix the issue with chrome urls.

Comment 28

[Peter Van der Beken [:peterv]]

Bz: the trouble with the chrome URLs is coming from
nsScriptSecurityManager::GetCodebasePrincipal
(http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp#1722)
which calls nsCodebasePrincipal::GetOrigin
(http://lxr.mozilla.org/seamonkey/source/caps/src/nsCodebasePrincipal.cpp#177).
Since chrome urls use nsStandardURL we end up in the codepath where GetHostPort
succeeds and so we truncate the URL to chrome://package and the NS_NewURI in
nsScriptSecurityManager::GetCodebasePrincipal
(http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp#1745)
fails because that doesn't have a provider. So we don't get the principal and
return an error. We could special case chrome in GetOrigin to get the complete
spec. On the other hand, it kind of makes sense to use chrome://package as the
origin (and that used to be a valid chrome url).

Comment 29

[Boris Zbarsky [:bzbarsky]]

Mitch already has a bug on the issue with GetOrigin.  There is some discussion
in it as to why this is no longer a valid URL (the short of it is that the only
reason it used to be valid is that there was no sanity-checking of chrome urls
until you tried to open them, at which point that URL would spectacularly fail).

Comment 30

[Axel Hecht]

I bet the scrollbars issue is the same as bug 202809.
Add blocking bug 204727, as we should have the fragment as stylesheet param, which
needs the new interface.

Comment 31

[Mitchell Stoltz (not reading bugmail)]

I think the origin for chrome should be just "chrome://", so maybe I should
special-case GetOrigin.

Comment 32

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

Peter has been working on this, reassigning.

Peter, could you attach a patch that is the best so far, something that we could
ship with? We are running out of time, so I think we should take whatever works
best now, and see if we can finish the work later.

Comment 33

[Peter Van der Beken [:peterv]]

Yeah, I've fixed most of the problems. I'm rebuilding right now and will attach
a patch after I've tested it once more.

Comment 34

[Peter Van der Beken [:peterv]]

Attachment: v1

I had to work around some bugs in other Mozilla code. Also, I need to set the
anchor links to a complete URI, otherwise I get a security exception. I used
the policy URI (minus the ref) for resolving the anchors. It's not really
correct, but it works.

Comment 35

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

Comment on attachment 124758 [details] [diff] [review]
v1

Really weird, but if it works I am happy, r/sr=heikki.

Harishd, could you also have a look?

I noticed you took out some context menu items - didn't they work?

Comment 36

[harishd]

Comment on attachment 124758 [details] [diff] [review]
v1

You can remove the following lines in nsP3PModule.cpp as well

  {"P3P Service",
   NS_P3PSERVICE_CID,
   "@mozilla.org/p3p/p3pservice;1",
   nsP3PServiceConstructor,
  },

no?

With an answer to heikki's question and mine r=harishd :)

Comment 37

[harishd]

Comment on attachment 124758 [details] [diff] [review]
v1

oops didn't mean to sr= :)

Comment 38

[Peter Van der Beken [:peterv]]

The context menu was never hooked up, I just removed the unused items. I tried
hooking it up, but for example the "Find again" item was always enabled, even if
I didn't do "Find" first. I think we should not enable it until someone fixes
it. And I'll remove the lines from nsP3PModule.cpp.

Comment 39

[Peter Van der Beken [:peterv]]

Attachment: v1.1

Comment 40

[Johnny Stenback (:jst)]

Comment on attachment 124812 [details] [diff] [review]
v1.1

sr=jst

Comment 41

[Peter Van der Beken [:peterv]]

Comment on attachment 124812 [details] [diff] [review]
v1.1

This is a low-risk patch that fixes the P3P Summary button in the privacy tab
in Page Info. Without this fix the feature is completely broken (the button
doesn't do anything). I've tested this with a couple of sites that have a P3P
policy.

Comment 42

[Samir Gehani]

a=adt to land this on the 1.4 branch.  Please add the fixed1.4 keyword once you
land this.  Thanks.

Comment 43

[Peter Van der Beken [:peterv]]

Checked in on trunk, waiting for drivers.

Comment 44

[Brendan Eich [:brendan]]

Comment on attachment 124812 [details] [diff] [review]
v1.1

Can you cite the bug #s in the comment?

+// XXX Temporary function to workaround disappearing scrollbars
+//	and bug in document.appendChild(DocumentFragment).


a=brendan,rjesup for 1.4.

/be

Comment 45

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

Bummer, the patch does not work! I get a security exception, and then a dialog
saying there is no policy. My guess is that Peter had an additional patch/hack
in his local tree to get round the security error, but forgot about it. Peter is
gone for the weekend, but Harish is now looking at this.

Comment 46

[harishd]

<strange> works with new profile but not with existing ones AFAICT </strange>

Comment 47

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

Filed bug 208559 for the comment issue and bug 208560 for the profile issue.

Comment 48

[harishd]

Patch landed on 1.4 branch. Will open a separate bug for the profile issue ( P3P
summary works only in new profile ).

Comment 49

[Grace Bush]

strange- I was able to see the summary window populated on the trunk builds

Comment 50

[Grace Bush]

verified on branch builds 
mac 2003060905
win 2003060905
linux 2003060907

Comment 51

[Grace Bush]

verified on trunk builds, all platforms
mac 2003060905
win 2003060905
linux 2003060907