220451 - Popup Manager's "Allowed Sites" dialog doesn't persist size and position

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Stefan Borggraefe]

It should, because then you don't have to resize it to your preferred size every
time you use it.

Patch follows...

Comment 1

[Stefan Borggraefe]

.

Comment 2

[Stefan Borggraefe]

Attachment: Patch

When I created the fix for this bug, I encountered that this dialog was
sometimes opened modal and sometimes not. This caused a problem because modal
windows remember their position relative to their parent window and non-modal
windows relative to the origin of the screen.

Luckily it turned out that this dialog never really needs to be modal. It was
opened modal in two places:

1. From the Preferences Panel. This was done because the dialog calls the
function setButtons() of the Popup-Preferences panel. setButtons() changes the
disabled-state of the buttons in the Popup-Preferences so they are always
consistent:

http://lxr.mozilla.org/seamonkey/source/extensions/cookie/resources/content/pref-popups.xul#143


setButtons() only does something when gPolicyCheckbox.checked has changed.
Since it is never changed from the "Allowed Sites" dialog, it doesn't make
sense to call it when closing "Allowed Sites". The call can be removed and thus
popupManager.js doesn't need a reference to the Preference panel anymore. So it
is now allowed to close the Preferences window while "Allowed Sites" is still
open and the dialog don't need to be modal anymore.

2. From the Popup Icon in the Navigator window. I think this was done so the
icon can be cleared when the dialog is closed. Here the dialog doesn't need to
be modal, too. When the browser tab/window with the Popup Icon is closed in the
meantime, the icon doesn't need to be cleared anymore and the function to clear
the icon does the necessary checks so there are no JavaScript errors in this
situation. So the "Allowed Sites" dialog doesn't need to be modal in this
situation, too.


Because the last parameter in the openDialog() call was only needed to
determine when to call setButtons() on the opener-window and setButtons() does
nothing, the parameter could be removed.

Now the dialog is never modal and its position is remembered relative to the
screen origin.

Comment 3

[[e-mail]]

Comment on attachment 132310 [details] [diff] [review]
Patch

I don't have an issue with removing the modality from the pref panel launcher,
it was handled incorrectly anyway, although I think the ... should now be
removed from the "Allowed Sites" button.

Comment 4

[Alec Flett]

Comment on attachment 132310 [details] [diff] [review]
Patch

sr=alecf

Comment 5

[Stefan Borggraefe]

I think the ...-issue should be handled in another bug. The usage of it seems to
be inconsistent in the Preferences dialog in several places. So a global "make
the ellipsis-usage consistent in Preferences"-bug seems appropriate.

This one is FIXED. Thanks for the checkin timeless! :-)