84232 - Opening the preferences dialog from a parallel browser window resets the current pref session

Status: VERIFIED FIXED

(Core :: Preferences: Backend, defect, P2)

Description

[[e-mail] (away - not reading bugmail)]

THis problem has been most recently observed in conjunction with a patch for 
bug 65251. Here are the relevant comments:

"If you attempt to select "Preferences" in your new browser instance, you 
original pref dialog will be reset... I know this is only a remote possibility, 
but it still needs to be considered."

...

"The problem you were seeing with opening prefs resetting the pref session
has been happening for some time - the pref window is not application modal,
only window-modal, and so if you have two browser windows up (likely) or
even a browser and a mail window up (also likely) then invoking the pref 
window twice will reset the session. The code above checks for an existing
window and focuses it, which should bring it, and its parent window to the
front."

Comment 1

[[e-mail] (away - not reading bugmail)]

accepting, moving to 0.9.3, marking as blocker for 65251

Comment 2

[[e-mail] (away - not reading bugmail)]

Attachment: attaching patch proposed by Ben (cvs diff -u -w -b)

Comment 3

[Frank Tang]

why the preference is window modal intead of app model ?

Comment 4

[Frank Tang]

reassign to ben

Comment 5

[Paul Chen]

nav triage team:

Marking nsbeta1+ and p2

Comment 6

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

Strictly speaking the preferences *window* shouldn't be modal at all. (See Mac
IE). But that's something to deal with after RTM. 

Applying patch into tree. Adding dataloss keyword as this could be quite
irritating. 

Comment 7

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

Attachment: updating original patch to include required change to pref.xul

Comment 8

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

What was happening is each time the user invoked the preferences dialog, a call
to openDialog would be made opening the preferences dialog XUL file as a named
window. When this happens, any existing preferences dialog is essentially
reloaded , user changes are lost. 

What this patch does is obtain the window-mediator (which keeps track of open
windows of a particular type) and look for any existing open preferences windows
(that is, windows with the windowtype attribute on their <window> XUL element
set to "mozilla:preferences"). If one is found, it is focused. Otherwise, a new
one is opened. 

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

ok, makes sense.  r=dbaron

Comment 10

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

Fix checked in on trunk. 

Comment 11

[Paul Chen]

nav triage team:

Marking nsBrnach since the fix is done

Comment 12

[Viswanath Ramachandran]

QA please verify on trunk. 

Comment 13

[sairuh (rarely reading bugmail)]

testing recipe:

0. let's say your default home page is http://bugzilla.mozilla.org
1. have two browser windows open, at two different pages. eg, window A at
http://yahoo.com and window B at http://bugzilla.mozilla.org
2. from window A, open the prefs dialog.
3. click "Use Current Page" button in the Navigator panel so that yahoo.com
becomes the default home page.
4. click in window B to bring it to the front.
5. open the prefs dialog from window B.

results: focus is moved to the prefs dialog opened from window A, and the
setting made at step (3) to change the home page is not clobbered.

vrfy'd fixed using the following comm trunk builds:

linux 2001.07.05.08
winnt 2001.07.05.09
mac 2001.07.05.08 - n/a, since the pref dialog here is modal, i cannot switch to
another browser window

removing vtrunk kw.

Comment 14

[sairuh (rarely reading bugmail)]

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

Comment 15

[Viswanath Ramachandran]

out of branch consideration now. 

Comment 16

[sairuh (rarely reading bugmail)]

okay, since this won't be checked into the branch, will mark as vrfy'd.