682587 - Application.activeWindow is undefined

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Stanimir Stamenkov]

1. Install Open in Browser extension [1] (currently at version 1.11), and restart.  You'll need to install Add-on Compatibility Reporter [2] prior that;
2. Try to open any of the attachments to <https://www.mozdev.org/bugs/show_bug.cgi?id=22167>;
3. When you get the "Open with" dialog, choose:

   (x) Open in browser as [_Image______]

   and click "OK".

Now, apparently nothing happens and observing the Error Console one sees:

Error: Application.activeWindow is undefined
Source File: chrome://openinbrowser/content/openInBrowser.js
Line: 139

Philip Chee has suggested [3] there's need to port the relevant parts of:

Bug 658632 (Provide easy way to add non-leaky classinfo to JS components)

[1] https://addons.mozilla.org/seamonkey/addon/open-in-browser/
[2] https://addons.mozilla.org/seamonkey/addon/add-on-compatibility-reporter/
[3] http://groups.google.com/group/mozilla.dev.apps.seamonkey/msg/dbe765637717454b

Comment 1

[Justin Wood (:Callek)]

Changes in Bug 658632 look relatively non-trivial and have *some* API change issues. That said, I think these JS errors warrant a drive into aurora/beta.

I'll work on this among my other duties this coming week, anyone agree that we should take this in beta/aurora?

Comment 2

[[e-mail]]

We should take the changes to smileApplication.js in aurora/beta, but I don't know which flags to set for that.

Comment 3

[[e-mail]]

Attachment: Proposed patch

Comment 4

[Justin Wood (:Callek)]

Comment on attachment 556397 [details] [diff] [review]
Proposed patch

>diff --git a/suite/smile/src/smileApplication.js b/suite/smile/src/smileApplication.js
>--- a/suite/smile/src/smileApplication.js
>+++ b/suite/smile/src/smileApplication.js
>@@ -673,37 +673,37 @@ var ApplicationFactory = {
> function Application() {
>   this.initToolkitHelpers();
>   this._bookmarks = null;
> }
> 
> //=================================================
> // Application implementation
> Application.prototype = {
>-  // for nsIClassInfo + XPCOMUtils
>+  // for XPCOMUtils
>   classID:          Components.ID("{c9ba8f65-c936-4ac6-a859-8936832b0c12}"),

Nit: would rather this pulled out to a CONST, but not a requirement.

>   // for nsISupports
>   QueryInterface : XPCOMUtils.generateQI(
>                      [Components.interfaces.smileIApplication,
>                       Components.interfaces.extIApplication,
>                       Components.interfaces.nsIObserver,
>                       Components.interfaces.nsIClassInfo]),

need to drop Ci.nsIClassInfo from here.

The rest of this file looks good, I wanted to treat this bug to be used for all these classInfo usages in suite/ (http://mxr.mozilla.org/comm-central/search?string=nsIClassInfo&find=suite/) but if you want to land JUST this part, please resolve the bug, request approvals, and open a new bug for the rest of our uses.

If you go the new bug route, please file one for Fallen and calendar, as there are a lot of uses there as well.

Comment 5

[[e-mail]]

Pushed changeset ff9cd429ade8 to comm-central with the nsIClassInfo change.

Comment 6

[Philip Chee]

Comment on attachment 556397 [details] [diff] [review]
Proposed patch

a=me for comm-aurora and comm-beta

Comment 7

[Philip Chee]

Pushed
http://hg.mozilla.org/releases/comm-aurora/rev/8d6af20d3293
http://hg.mozilla.org/releases/comm-beta/rev/fbdf31492ffc