Closed
Bug 774660
Opened 12 years ago
Closed 12 years ago
openPreferences should consistently not return a window object
Categories
(Firefox :: Settings UI, defect)
Firefox
Settings UI
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)
1.42 KB,
patch
|
dao
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•12 years ago
|
||
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
Reporter | ||
Comment 2•12 years ago
|
||
(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?
Comment 3•12 years ago
|
||
(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.
Updated•12 years ago
|
Whiteboard: [good first bug][mentor=dao][lang=js]
Assignee | ||
Comment 4•12 years ago
|
||
@Dao, @Ehsan, will this bug block bug 722978 ?
BTW, I think I can work on this :)
Comment 5•12 years ago
|
||
(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.
Assignee | ||
Comment 6•12 years ago
|
||
Reporter | ||
Comment 7•12 years ago
|
||
(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!
Assignee | ||
Comment 8•12 years ago
|
||
Attachment #643365 -
Attachment is obsolete: true
Attachment #643365 -
Flags: feedback?(dao)
Attachment #643378 -
Flags: feedback?(dao)
Comment 9•12 years ago
|
||
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+
Assignee | ||
Comment 10•12 years ago
|
||
Fixed indentation.
Attachment #643378 -
Attachment is obsolete: true
Attachment #643391 -
Flags: review?(dao)
Updated•12 years ago
|
Attachment #643391 -
Flags: review?(dao) → review+
Reporter | ||
Comment 11•12 years ago
|
||
Target Milestone: --- → Firefox 17
Comment 12•12 years ago
|
||
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.
Description
•