135837 - Key commands don't work in P3P summary window (except for up/down keys)

Status: VERIFIED INVALID

(SeaMonkey :: UI Design, defect, P1)

Description

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

1. Go to www.msn.com (or any other site supporting P3P).
2. Open Page Info dialog and select Privacy Tab.
3. Hit Summary button
4. Try Ctrl+W (close window), Ctrl+F (find), ...

Expected results: key commands should work, like close window, find on page...

Actual results: nothing seems to happen

You need to apply the patch from bug 124503 to test this.

This might be duplicate of bug 135825.

Comment 1

[Samir Gehani]

I have a hard time seeing how this is ADT1.  Renominating for nav triage time to
consider.

Comment 2

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

Well, this is accessibility. If you open the summary window there is no way to
close it without a mouse.

Btw, the issue with accelerators not working properly in the page info dialog
(Alt+P does not go to Privacy, does not work for any other tab either) is worse
on Linux where Ctrl+Tab does not work either: you MUST use the mouse on Linux to
access those tabs. I don't know what bug that would be although I am sure
someone has filed that.

Comment 3

[Paul Wyskoczka]

qa --> [e-mail]

Comment 4

[Peter Trudelle]

nsbeta1+/adt2 per Nav triage team

Comment 5

[Samir Gehani]

This really should be a bugscape bug.

Comment 6

[Samir Gehani]

Attachment: Patch v1.0.

Comment 7

[Samir Gehani]

Mail sent to law and jag for r and sr, respectively.

Comment 8

[Samir Gehani]

Attachment: Patch v2.0 (with comments this time).

Comment 9

[Samir Gehani]

Attachment: Patch v3.0.

Fixed typos in comments.

Comment 10

[harishd]

Comment on attachment 81557 [details] [diff] [review]
Patch v3.0.

>Index: nsPolicyViewer.js
>===================================================================
>RCS file: /m/src/ns/extensions/p3p/resources/content/nsPolicyViewer.js,v

>-  var resultWin = window.openDialog("chrome://p3p/content/p3pSummary.xul", "_blank", "chrome,all,dialog=no", 
>+  // We launch the dialog with chrome=no so that the launching window loads
>+  // our XUL doc (i.e., p3pSummary.xul) inside navigator.xul.  We need to
>+  // be launched inside navigator.xul in order to get the key bindings
>+  // like ctrl-f etc.  The chrome dialog that pops up really contains
>+  // generated HTML.  
>+  var resultWin = window.openDialog("chrome://p3p/content/p3pSummary.xul", 
>+                                    "_blank", "chrome=no,dialog=no", 
>                                     gXSLTProcessor, getDocument(), gStyle);

Make sure to change gXSLTProcessor, getDocument(), and gStyle to
this.mXSLTProcessor, this.getDocument(),
and this.mStyle respectively if you're landing on the TRUNK.

---

Also, I noticed that, with the patch, the policy summary window gets populated
a bit
slower than before!

Comment 11

[Bill Law]

Comment on attachment 81557 [details] [diff] [review]
Patch v3.0.

r=law

Comment 12

[Samir Gehani]

In comment 10 harishd said:

> Also, I noticed that, with the patch, the policy summary window gets 
> populated a bit slower than before!

Have you timed this?  I think this might be perception.  You may be right
though.  We do a dynamic sizeToContent() which may be flashing so it looks like
it's slower when it's not.  That problem is fixed by speeding up document
transformation -or- not displaying the document till it is transformed (needs
more thought).

If you are in fact correct about this, do we care about this performance drop
against the functionality gain?  If we think this is too slow we should consider
showing progress.

At any rate, my vote is that I don't think we should hold up this patch.

Comment 13

[harishd]

>Have you timed this?  I think this might be perception.  
I haven't timed it!. It just appears to be slow :-/

>If you are in fact correct about this, do we care about this performance drop
>against the functionality gain?  

Definitely functionality. I just mentioned what I noticed..that's all.

>If we think this is too slow we should consider showing progress.

Regardless we should consider showing progress post beta.

>At any rate, my vote is that I don't think we should hold up this patch.

That's my vote too :). 

Comment 14

[jag (Peter Annema)]

Comment on attachment 81557 [details] [diff] [review]
Patch v3.0.

You are aware that calling window.sizeToContent() there will mess up
navigator's window size stored in localstore.rdf when the window is closed,
right? Of course, popup windows already do that, but it seems worse if we're
doing it ourselves, especially since the window won't look like a navigator
window. Is there any way you could do something similar to what "View Source"
does? It has a <browser> and all the necessary overlays needed to hook up menus
and find.

Comment 15

[Samir Gehani]

> You are aware that calling window.sizeToContent() there will mess up
> navigator's window size stored in localstore.rdf when the window is closed,
> right?

That didn't occur to me.  I'll look into immitating view source.

Comment 16

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

If we make P3P inherit the navigator accels & context menu and what have you, we
give the user the tools to get really confused. For example: if they reload the
page, the XSLT transformation will not be applied and they will see the raw P3P
policy as every element with only one CSS style: display:inline. View source
does not make sense either, and save does not work now (you'd need to save the
transformed doc but I have disabled that for now, too many dataloss issues) and
so forth.

P3P needs its own menu bar and accels. Things like find, copy, zoom etc. make
sense for P3P summary, but we must evaluate case by case what makes sense and
what does not. Harish started working on this, I believe.

Comment 17

[Samir Gehani]

Harish and I have a working patch based on the view-source window.  Harish has
volunteered to drive the patch to checkin.  This is now bugscape 15105:
<http://bugscape.netscape.com/show_bug.cgi?id=15105>

Comment 18

[John Unruh]

V