Closed Bug 774660 Opened 12 years ago Closed 12 years ago

openPreferences should consistently not return a window object

Categories

(Firefox :: Settings UI, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 17

People

(Reporter: ehsan.akhgari, Assigned: sawrubh)

Details

(Whiteboard: [good first bug][mentor=dao][lang=js])

Attachments

(1 file, 2 obsolete files)

See <http://mxr.mozilla.org/mozilla-central/source/browser/base/content/utilityOverlay.js#477>.  This will be a problem when we use the return value in the test case for bug 722978.
The current return value appears to be unused and returning a window is non-trivial in the in-content case, so we should instead remove it. The test in bug 722978 should use observers or something.
OS: Mac OS X → All
Hardware: x86 → All
Summary: openPreferences no longer returns the window object for the preferences window when in-content prefs are active → openPreferences should consistently not return a window object
(In reply to comment #1)
> The current return value appears to be unused and returning a window is
> non-trivial in the in-content case, so we should instead remove it. The test in
> bug 722978 should use observers or something.

How would using observers get us to the right window object?
(In reply to Ehsan Akhgari [:ehsan] from comment #2)
> (In reply to comment #1)
> > The current return value appears to be unused and returning a window is
> > non-trivial in the in-content case, so we should instead remove it. The test in
> > bug 722978 should use observers or something.
> 
> How would using observers get us to the right window object?

Via the subject argument, or the test would just look for the window itself using window watcher and tabbrowser APIs.
Whiteboard: [good first bug][mentor=dao][lang=js]
@Dao, @Ehsan, will this bug block bug 722978 ?

BTW, I think I can work on this :)
(In reply to Saurabh Anand [:sawrubh] from comment #4)
> @Dao, @Ehsan, will this bug block bug 722978 ?

No, I morphed it. This bug is now about making openPreferences never return a window.
Attached patch Patch v1 (obsolete) — Splinter Review
Assignee: nobody → saurabhanandiit
Status: NEW → ASSIGNED
Attachment #643365 - Flags: feedback?(dao)
(In reply to comment #4)
> @Dao, @Ehsan, will this bug block bug 722978 ?

Hmm, I think so, yes, since now you cannot use the openPreferences() function in a straightforward manner there.

> BTW, I think I can work on this :)

Great!
Attached patch Patch v2 (obsolete) — Splinter Review
Attachment #643365 - Attachment is obsolete: true
Attachment #643365 - Flags: feedback?(dao)
Attachment #643378 - Flags: feedback?(dao)
Comment on attachment 643378 [details] [diff] [review]
Patch v2

>+    openDialog("chrome://browser/content/preferences/preferences.xul",
>                       "Preferences", features, paneID, extraArgs);

Looks good except for the indentation in the second line here.
Attachment #643378 - Flags: feedback?(dao) → feedback+
Attached patch Patch v3Splinter Review
Fixed indentation.
Attachment #643378 - Attachment is obsolete: true
Attachment #643391 - Flags: review?(dao)
Attachment #643391 - Flags: review?(dao) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/61b822ad93a1
Target Milestone: --- → Firefox 17
https://hg.mozilla.org/mozilla-central/rev/61b822ad93a1
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: