56048 - Cannot dismiss Help:Privacy dialog

Status: VERIFIED FIXED

(Core :: Networking: Cookies, defect, P3)

Description

[Tom Everingham]

Overview Description:  There is no way to exit the help privacy dialog on the 
Mac.  It is modal so once you are there, you may have to force quit your app.

Steps to Reproduce:
1.)  Goto prefs - advanced - cookies - more information
2.)  try to close window

Actual Results:  cannot close window

Build Date & Platform Bug Found:
Mac os9 2000100910

Additional Builds and Platforms Tested On:
works on winNT and Linux

Comment 1

[Tom Everingham]

*spam* - nominating for rtm.   

Comment 2

[sairuh (rarely reading bugmail)]

not sure if this is a prefs bug, so over the the cookies owner. if not, punt to
appropriate person.

Comment 3

[Matthew T (active 1999-2002)]

Steve, you need to do the same thing here as you did in bug 50097.

Comment 4

[Stephen P. Morse]

Grrr!  This means that instead of bringing up vera's privacy document 
directly from the pref panel, we instead need to bring up an intermediate xul 
dialog which just has an OK button and contains a frame whose source is vera's 
privacy document.  And this all needs to be done in such a way that it affects 
the netscape build only and be transparent to the mozilla build.

Not difficult but there are several files that need to be changed, especially 
since it involves the addition of a new file (updating makefiles, manifests, jar 
files, etc).  Are you sure we want to do all this at this stage?

What are the alternatives?  I can think of several.

1. Do nothing.  After all, it's only the mac users that are affected. :-/

2. Back out part of the change that was done in bug 52674, at least the part 
having to do with bringing up the tutorial from the pref panel.  That means that 
vera's document would be brought up from the tasks menu but that my original 
document would be brought up from the prefs panel.

3. Bite the bullet and add the new xul file, modify the makefile.win, 
Makefile.in, manifest and jar.ns files, as well as the file that identifies the 
xul file to be brought up.

Of course 1 has zero risk but it probably not acceptable (user is effectively 
locked into a mode).  Solution 2 is minimum risk but would it be acceptable to 
legal?  Solution 3 is the most risk but is the full solution.

Comment 5

[Stephen P. Morse]

BTW, taking solution 2 would also solve bug 55558 whereas if we go with solution 
3 we still need to come up with a fix for 55558 as well.

Comment 6

[verah (gone)]

Solution 2.... I have thought along those lines as well. However, we'd have to 
do a quick re-work of your document, Steve. It does not contain some of the 
things legal wants (and hasn't been reviewed by legal), and it does contain the 
problemmatic "sheep.com" and "wolf.com" examples. (I know, I know, it would be 
nice if we could use such generic terms, but while we can use the words "wolf" 
and "sheep" to our hearts' content, "wolf.com" and "sheep.com" belong to third 
parties.)

How about if I work up a version of my document that does not require the Help 
chrome? I'd put the table of contents at the top, and make it a regular HTML 
document (no XUL). It would take me no more than 30 minutes. Just say the word, 
and I'll get on it.

Comment 7

[verah (gone)]

By the way, this is the same as Bugscape bug 2468. NONE of the help windows can 
be dismissed.

Comment 8

[Daniel Veditz [:dveditz]]

Bugscape 2468 has been double-plussed -- can I expect this one to get fixed 
magically, so we don't have to worry about it any more?

Otherwise, rtm- unless Vera wants to whip up a new version of the doc that 
doesn't require the help chrome -- that sounds like the quickest and safest fix 
at this point.

Comment 9

[Stephen P. Morse]

This has nothing to do with 2648 which is a cross-platform bug.  This bug is 
mac-only.  And the presence or absense of the help chrome also has nothing to do 
with it.

The problem is that the mac does not give you an X in the upper right corner for 
closing dialogs whereas both unix and win32 do.  So without the X, there is no 
way to close it on the mac.  The solution is to use an intermediate xul file (as 
I described above) which contains a "Close" button.  That's my solution #3.

This is exactly what I did when I had my own privacy-tutorial come up instead of 
Vera's.  When we switched over the vera's dialog, we lost this intermediate file 
and so we lost the ability to close on a mac.

Comment 10

[Stephen P. Morse]

I'm trying to work on a simple change to my privacy.xul dialog (which is used in 
the mozilla tree to bring up my tutorial) so that the tutorial it brings up 
depends on which tree it is in.  That would be the simplest change to make to 
solve this problem.  So far I have not yet been able to get this to work.

Comment 11

[Stephen P. Morse]

I have a simple fix for this problem.

Basically we are currently bringing up an intermediary in the mozilla tree but 
going directly to the tutorial in the netscape tree.  So my fix is to bring up 
the same intermediary in both cases and have that intermediary make the test to 
determine which of the two dialogs to bring up.  Am about to attach patches.

Comment 12

[Stephen P. Morse]

Attachment: patch to fix the problem

Comment 13

[Daniel Veditz [:dveditz]]

r=dveditz

Need super review, but due to shortness of time want to rtm+ this for
provisional PDT approval

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

a=ben. 

Comment 15

[Jim Roskind]

rtm double plus.  You won't get a lot of chances at this late date... so this
better be good.  We're counting on very tight reviews.

Please land asap on branch.

Comment 16

[Stephen P. Morse]

Checked in on branch and on tip.

Comment 17

[Tom Everingham]

verified on branch:
Mac os9 2000101608
- also checked
WinNT 2000101608
Linux 2000101309

needs verified on trunk

Comment 18

[Rodney Velasco]

verified on these trunk builds
Oct. 23 Mac OS9
also checked
Oct. 24 Linux rh7
Oct. 24 WinNT 4.0
Marking bug as verified and removing vtrunk keyword