Last Comment Bug 609890 - window.console API messages from before the Web Console is opened don't show
: window.console API messages from before the Web Console is opened don't show
Status: RESOLVED FIXED
[console-1]
: dev-doc-complete
Product: Firefox
Classification: Client Software
Component: Developer Tools (show other bugs)
: Trunk
: x86 All
: P1 normal with 1 vote (vote)
: Firefox 12
Assigned To: Mihai Sucan [:msucan]
:
:
Mentors:
: 606793 713385 (view as bug list)
Depends on: 612658
Blocks: devtools4 611032 664466
  Show dependency treegraph
 
Reported: 2010-11-05 07:37 PDT by David Dahl :ddahl
Modified: 2012-04-23 10:04 PDT (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
v 0.1 Display Cached ConsoleAPI Messages (8.82 KB, patch)
2010-11-17 19:29 PST, David Dahl :ddahl
no flags Details | Diff | Splinter Review
v 0.2 removed usage of sendToWebConsole (8.93 KB, patch)
2010-11-22 14:46 PST, David Dahl :ddahl
gavin.sharp: review-
Details | Diff | Splinter Review
v 0.3 updated as per comments (7.49 KB, patch)
2010-12-16 16:44 PST, David Dahl :ddahl
no flags Details | Diff | Splinter Review
v 0.3.1 updated for bitrot and changes in storageSvc patch (7.10 KB, patch)
2010-12-20 15:41 PST, David Dahl :ddahl
gavin.sharp: review+
Details | Diff | Splinter Review
v 0.3.2 Comments Address (7.08 KB, patch)
2011-01-03 19:57 PST, David Dahl :ddahl
bugzilla: review+
Details | Diff | Splinter Review
v 0.3.2 Comments Address (7.08 KB, patch)
2011-01-03 19:59 PST, David Dahl :ddahl
bugzilla: review+
Details | Diff | Splinter Review
v 0.3.3 Comments Address (8.01 KB, patch)
2011-01-06 13:32 PST, David Dahl :ddahl
bugzilla: review+
Details | Diff | Splinter Review
v 0.3.4 unbitrot (7.36 KB, patch)
2011-02-11 12:06 PST, David Dahl :ddahl
bugzilla: review+
Details | Diff | Splinter Review
v 0.3.5 unbitrot (7.33 KB, patch)
2011-03-28 16:07 PDT, David Dahl :ddahl
bugzilla: review+
Details | Diff | Splinter Review
0.3.6 Un bitrot (7.36 KB, patch)
2011-05-10 20:52 PDT, David Dahl :ddahl
bugzilla: review+
Details | Diff | Splinter Review
v 0.4 updated for innerWindow IDs. now we have a broken test (13.66 KB, patch)
2011-05-13 11:55 PDT, David Dahl :ddahl
no flags Details | Diff | Splinter Review
0.5 Updated the logConsoleAPI call (13.66 KB, patch)
2011-05-20 14:51 PDT, David Dahl :ddahl
bugzilla: review+
Details | Diff | Splinter Review
v 0.6 test fixes, plus a tweak to HUDService where we throw because of undefined hud (16.96 KB, patch)
2011-06-15 09:38 PDT, David Dahl :ddahl
gavin.sharp: review-
Details | Diff | Splinter Review
v 0.7 fixed wonkey undefined hud behavior (14.56 KB, patch)
2011-06-15 17:40 PDT, David Dahl :ddahl
gavin.sharp: review-
Details | Diff | Splinter Review
v 0.8 removed conditional hud checks. all tests pass (12.77 KB, patch)
2011-06-28 08:44 PDT, David Dahl :ddahl
no flags Details | Diff | Splinter Review
v 0.9 rebase and cleanup (11.68 KB, patch)
2011-07-05 13:52 PDT, Mihai Sucan [:msucan]
no flags Details | Diff | Splinter Review
v 0.10 rebase, fix for iframes and scroll to bottom (12.50 KB, patch)
2011-07-06 13:04 PDT, Mihai Sucan [:msucan]
gavin.sharp: review+
Details | Diff | Splinter Review
v 0.11 comments addressed (12.89 KB, patch)
2011-07-07 05:43 PDT, Mihai Sucan [:msucan]
no flags Details | Diff | Splinter Review
v 0.12 rebase (12.76 KB, patch)
2011-08-02 11:27 PDT, Mihai Sucan [:msucan]
no flags Details | Diff | Splinter Review
v 0.13 rebase (12.78 KB, patch)
2011-08-04 05:38 PDT, Mihai Sucan [:msucan]
no flags Details | Diff | Splinter Review
[in-fx-team] v 0.14 rebase (12.53 KB, patch)
2012-01-06 13:04 PST, Mihai Sucan [:msucan]
no flags Details | Diff | Splinter Review

Description David Dahl :ddahl 2010-11-05 07:37:07 PDT
Followup bug to the lazy console integration. We need to display console api log messages that are cached when the web console opens.
Comment 1 Kevin Dangoor 2010-11-08 09:14:55 PST
Requesting blocking status for this. Before the console is opened, the messages will be held in a cache. That cache isn't useful if it's not displayed when the user opens the console (which is what this bug is to address.)
Comment 2 Kevin Dangoor 2010-11-16 09:41:11 PST
Unassigning so that this can be picked up by anyone after the caching lands.
Comment 3 David Dahl :ddahl 2010-11-16 10:26:02 PST
I already have a patch for this.
Comment 4 David Dahl :ddahl 2010-11-17 16:11:20 PST
*** Bug 606793 has been marked as a duplicate of this bug. ***
Comment 5 David Dahl :ddahl 2010-11-17 19:29:12 PST
Created attachment 491435 [details] [diff] [review]
v 0.1 Display Cached ConsoleAPI Messages
Comment 6 David Dahl :ddahl 2010-11-17 19:30:41 PST
(In reply to comment #5)
> Created attachment 491435 [details] [diff] [review]
> v 0.1 Display Cached ConsoleAPI Messages

Current patch is not using the refactor of "sendToWebConsole" methods - yet.
Comment 7 David Dahl :ddahl 2010-11-17 20:40:40 PST
(In reply to comment #6)
> Current patch is not using the refactor of "sendToWebConsole" methods - yet.

Also, this patch requires the one from bug 612658
Comment 8 Kevin Dangoor 2010-11-22 11:14:38 PST
mass change: filter on PRIORITYSETTING
Comment 9 Kevin Dangoor 2010-11-22 11:32:06 PST
mass change: filter on PRIORITYSETTING
Comment 10 David Dahl :ddahl 2010-11-22 14:46:02 PST
Created attachment 492458 [details] [diff] [review]
v 0.2 removed usage of sendToWebConsole

updated patch to latest trunk, terminated using "CAO_sendToWebConsole()"
Comment 11 Kevin Dangoor 2010-11-23 06:46:51 PST
mass change: filter mail on BLOCKERSETTING
Comment 12 Rob Campbell [:rc] (:robcee) 2010-11-29 10:15:51 PST
Marking as assigned.
Comment 13 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-12-08 18:32:50 PST
Comment on attachment 492458 [details] [diff] [review]
v 0.2 removed usage of sendToWebConsole

>diff --git a/dom/tests/browser/browser_ConsoleAPICachedMessages.js b/dom/tests/browser/browser_ConsoleAPICachedMessages.js

>+XPCOMUtils.defineLazyGetter(this, "HUDService", function () {
>+  Cu.import("resource:///modules/HUDService.jsm");

Can't have a dom/ test that depends on the HUD service, since it's Firefox-only. This could just move to live next to the other hudservice tests, though. A really simple dom/ test that just tests that messages are being cached (calling console.log() and checking the cache manually) would be good.

>diff --git a/toolkit/components/console/hudservice/HUDService.jsm b/toolkit/components/console/hudservice/HUDService.jsm

>+  displayCachedConsoleMessages: function HUD_displayCachedConsoleMessages()
>+  {
>+    // get the messages from the storageService:
>+    let messages = [];
>+    try {
>+      let windowId = HUDService.getWindowId(this.contentWindow);
>+      messages = gConsoleStorage.getConsoleStorage(windowId);
>+    }

Doesn't look like either of these calls can really fail, so the try is unnecessary.

>+    let len = messages.length;
>+    if (len) {
>+      for (let i = 0; i < len; i++) {

No need to check len beforehand.

>+        HUDService.logConsoleAPIMessage(this.hudId,

We should take this opportunity to move the logConsoleAPIMessage implementation to the HeadsUpDisplay objects themselves rather than HUDService (part of bug 592523). That way you can just do messages.forEach(this.logConsoleAPIMessage, this); (adjusting logConsoleAPIMessage's signature as needed).
Comment 14 David Dahl :ddahl 2010-12-16 16:44:18 PST
Created attachment 498256 [details] [diff] [review]
v 0.3 updated as per comments
Comment 15 David Dahl :ddahl 2010-12-20 15:41:37 PST
Created attachment 498886 [details] [diff] [review]
v 0.3.1 updated for bitrot and changes in storageSvc patch
Comment 16 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-12-22 07:48:17 PST
Comment on attachment 498886 [details] [diff] [review]
v 0.3.1 updated for bitrot and changes in storageSvc patch

>diff --git a/dom/tests/browser/Makefile.in b/dom/tests/browser/Makefile.in

>+		browser_ConsoleStorageTests.js \

This is part of some other patch, I think?

>diff --git a/toolkit/components/console/hudservice/HUDService.jsm b/toolkit/components/console/hudservice/HUDService.jsm

>+  displayCachedConsoleMessages: function HUD_displayCachedConsoleMessages()

>+      HUDService.logConsoleAPIMessage(this.hudId,

I suppose ideally logConsoleAPIMessage would be a method of the HUD object rather than the service, and then displayCachedConsoleMessages could be called from the constructor for HeadsUpDisplay objects rather than manually after registerHUDReference. That probably requires some refactoring though, so no need to block on that.

>diff --git a/toolkit/components/console/hudservice/tests/browser/browser_ConsoleAPICachedMessages.js b/toolkit/components/console/hudservice/tests/browser/browser_ConsoleAPICachedMessages.js

>+const Cc = Components.classes;
>+const Ci = Components.interfaces;
>+const Cu = Components.utils;
>+
>+Cu.import("resource://gre/modules/Services.jsm");
>+Cu.import("resource://gre/modules/XPCOMUtils.jsm");

Browser chrome tests run in the browser chrome window scope, where these are already imported/defined, so you shouldn't import/define them again.

>+function testOpenUI()

>+  function testLogEntry(aOutputNode, aMatchString, aSuccessErrObj)

Can't you use the one defined in head.js?
Comment 17 David Dahl :ddahl 2010-12-22 08:01:04 PST
(In reply to comment #16)
> Comment on attachment 498886 [details] [diff] [review]
> v 0.3.1 updated for bitrot and changes in storageSvc patch
> 
> >diff --git a/dom/tests/browser/Makefile.in b/dom/tests/browser/Makefile.in
> 
> >+		browser_ConsoleStorageTests.js \
> 
> This is part of some other patch, I think?

Ah, crap. Looks like it.

> 
> >diff --git a/toolkit/components/console/hudservice/HUDService.jsm b/toolkit/components/console/hudservice/HUDService.jsm
> 
> >+  displayCachedConsoleMessages: function HUD_displayCachedConsoleMessages()
> 
> >+      HUDService.logConsoleAPIMessage(this.hudId,
> 
> I suppose ideally logConsoleAPIMessage would be a method of the HUD object
> rather than the service, and then displayCachedConsoleMessages could be called
> from the constructor for HeadsUpDisplay objects rather than manually after
> registerHUDReference. That probably requires some refactoring though, so no
> need to block on that.

OK, filed followup bug 620958
> 
> >diff --git a/toolkit/components/console/hudservice/tests/browser/browser_ConsoleAPICachedMessages.js b/toolkit/components/console/hudservice/tests/browser/browser_ConsoleAPICachedMessages.js
> 

> >+Cu.import("resource://gre/modules/Services.jsm");
> >+Cu.import("resource://gre/modules/XPCOMUtils.jsm");
> 
> Browser chrome tests run in the browser chrome window scope, where these are
> already imported/defined, so you shouldn't import/define them again.
> 
Gotcha.

> >+function testOpenUI()
> 
> >+  function testLogEntry(aOutputNode, aMatchString, aSuccessErrObj)
> 
> Can't you use the one defined in head.js?

Yep, not sure why this is like this - perhaps I copied a test from dom/tests
Comment 18 David Dahl :ddahl 2011-01-03 19:57:32 PST
Created attachment 500962 [details] [diff] [review]
v 0.3.2 Comments Address

r+ by gavin with the current changes
Comment 19 David Dahl :ddahl 2011-01-03 19:59:45 PST
Created attachment 500963 [details] [diff] [review]
v 0.3.2 Comments Address

Forgot to qref a slight test change. r+ by gavin with current changes
Comment 20 David Dahl :ddahl 2011-01-06 13:32:17 PST
Created attachment 501795 [details] [diff] [review]
v 0.3.3 Comments Address

moved the lazyGetter for the consoleStorageSvc (inHUDService.jsm) to this patch from the consoleStorageSvc patch
Comment 21 Mihai Sucan [:msucan] 2011-01-07 07:58:50 PST
Comment on attachment 501795 [details] [diff] [review]
v 0.3.3 Comments Address

In dom/tests/browser/Makefile.in:

+		browser_ConsoleAPICachedMessages.js \

This change is not needed. You have the test in the hudservice tests. This also breaks Make - compilation fails.
Comment 22 :Ehsan Akhgari 2011-02-09 21:52:42 PST
Out of curiosity, what is this bug waiting for before it can land?
Comment 23 David Dahl :ddahl 2011-02-10 05:36:27 PST
(In reply to comment #22)
> Out of curiosity, what is this bug waiting for before it can land?

It depends on bug 612658 - which is so close - we were in mid-review when we paused for hardblockers
Comment 24 David Dahl :ddahl 2011-02-11 12:06:52 PST
Created attachment 511799 [details] [diff] [review]
v 0.3.4 unbitrot
Comment 25 Mike Beltzner [:beltzner, not reading bugmail] 2011-03-03 07:11:36 PST
** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 19 being moved from blocking2.0:betaN+ to blocking2.0:- as we reached the endgame of Firefox 4. The rationale for the move is:

 - the bug had been identified as a "soft" blocker which could be fixed in some follow up release
 - the bug had been identified as one requiring beta coverage, thus is not appropriate for a ".x" stability & security release

The owner of the bug may wish to renominate for .x consideration.
Comment 26 Mike Beltzner [:beltzner, not reading bugmail] 2011-03-03 07:18:19 PST
(er updating flag to "-" as per previous comment!)
Comment 27 David Dahl :ddahl 2011-03-28 16:07:19 PDT
Created attachment 522511 [details] [diff] [review]
v 0.3.5 unbitrot
Comment 28 David Dahl :ddahl 2011-05-10 20:52:42 PDT
Created attachment 531532 [details] [diff] [review]
0.3.6 Un bitrot
Comment 29 David Dahl :ddahl 2011-05-12 17:16:06 PDT
hrmmm, getting a failure in 1 test now after updating bug 612658 and the patch on this bug:

TEST-PASS | chrome://mochitests/content/browser/toolkit/components/console/hudservice/tests/browser/browser_webconsole_notifications.js | we have a console ID
TEST-PASS | chrome://mochitests/content/browser/toolkit/components/console/hudservice/tests/browser/browser_webconsole_notifications.js | message node id is not null
*** WebConsoleTest: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebProgress.removeProgressListener]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource:///modules/HUDService.jsm :: HS_deactivateHUDForContext :: line 1473"  data: no]
*** WebConsoleTest: undefined


And of course, this is in an 'unrelated' test.

msucan: do you know why that exception would throw in this case?

very strange.
Comment 30 David Dahl :ddahl 2011-05-13 11:55:46 PDT
Created attachment 532300 [details] [diff] [review]
v 0.4 updated for innerWindow IDs. now we have a broken test

Mihai, somehow this patch breaks the notifications test. very strange, do you think you could look at the exception - would love some feedback on why it is breaking. We throw in HUDService.jsm on line 1474: 

      browser.webProgress.removeProgressListener(hud.progressListener);
Comment 31 David Dahl :ddahl 2011-05-20 14:51:07 PDT
Created attachment 534118 [details] [diff] [review]
0.5 Updated the logConsoleAPI call

Working all tests pass
Comment 32 David Dahl :ddahl 2011-05-20 14:51:42 PDT
Also, the latest patch was rebased against the devtools branch
Comment 33 David Dahl :ddahl 2011-06-15 09:38:55 PDT
Created attachment 539566 [details] [diff] [review]
v 0.6 test fixes, plus a tweak to HUDService where we throw because of undefined hud

This should be re-reviewed. A check in the test toolkit/components/console/hudservice/tests/browser/browser_webconsole_notifications.js was not passing after the consoleAPIStorage patch was applied and this patch was updated. I filed bug 664466 as a followup - i think we may just need to return early or call the UI node removal and return if the hud object is undefined. 

Anyway, all tests pass now.
Comment 34 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-06-15 11:54:51 PDT
Comment on attachment 539566 [details] [diff] [review]
v 0.6 test fixes, plus a tweak to HUDService where we throw because of undefined hud

>diff --git a/toolkit/components/console/hudservice/HUDService.jsm b/toolkit/components/console/hudservice/HUDService.jsm

>     let displayNode = chromeDocument.getElementById(hudId);
> 
>     if (hudId in this.hudReferences && displayNode) {

>       let hud = this.hudReferences[hudId];
>+      try {
>+        // hud can sometimes be undefined at this point

I don't think that should be possible, particularly given the checks above. We shouldn't wallpaper over this, we need to figure out what's going on.
Comment 35 David Dahl :ddahl 2011-06-15 17:40:35 PDT
Created attachment 539692 [details] [diff] [review]
v 0.7 fixed wonkey undefined hud behavior

Found a place or two where we assume the existence of a hud reference and there is not one
Comment 36 David Dahl :ddahl 2011-06-15 17:41:32 PDT
this patch also fixes the followup: bug 664466
Comment 37 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-06-21 14:34:50 PDT
Comment on attachment 539692 [details] [diff] [review]
v 0.7 fixed wonkey undefined hud behavior

>diff --git a/toolkit/components/console/hudservice/HUDService.jsm b/toolkit/components/console/hudservice/HUDService.jsm

>+    var hud = this.hudReferences[hudId];
>+
>     if (hudId in this.hudReferences && displayNode) {

This code pattern doesn't make much sense - this change doesn't look necessary, though.

>   logConsoleAPIMessage: function HS_logConsoleAPIMessage(aHUDId, aMessage)

>     let hud = HUDService.hudReferences[aHUDId];
>+    if (!hud) {
>+      return;
>+    }

This method is called with the return value of HUDService.getHudIdByWindow, so if aHUDId is bogus, something more fundamental is wrong. Can't just wallpaper over it.

>   disableAnimation: function HS_disableAnimation(aHUDId)

>+    let reference = HUDService.hudReferences[aHUDId];
>+    if (!reference) {
>+      return;

Similarly, it should be impossible for this to be null (this is only called from activateHUDForContext).
Comment 38 Panos Astithas [:past] 2011-06-27 04:31:39 PDT
(In reply to comment #37)
> Comment on attachment 539692 [details] [diff] [review] [review]
> v 0.7 fixed wonkey undefined hud behavior
> 
> >diff --git a/toolkit/components/console/hudservice/HUDService.jsm b/toolkit/components/console/hudservice/HUDService.jsm
> 
> >   logConsoleAPIMessage: function HS_logConsoleAPIMessage(aHUDId, aMessage)
> 
> >     let hud = HUDService.hudReferences[aHUDId];
> >+    if (!hud) {
> >+      return;
> >+    }
> 
> This method is called with the return value of HUDService.getHudIdByWindow,
> so if aHUDId is bogus, something more fundamental is wrong. Can't just
> wallpaper over it.
> 
> >   disableAnimation: function HS_disableAnimation(aHUDId)
> 
> >+    let reference = HUDService.hudReferences[aHUDId];
> >+    if (!reference) {
> >+      return;
> 
> Similarly, it should be impossible for this to be null (this is only called
> from activateHUDForContext).

I removed these two checks and I don't get any failed tests on OS X. Were the failures we are investigating consistent or intermittent oranges?
Comment 39 David Dahl :ddahl 2011-06-27 07:54:23 PDT
(In reply to comment #38)
> > Similarly, it should be impossible for this to be null (this is only called
> > from activateHUDForContext).
> 
> I removed these two checks and I don't get any failed tests on OS X. Were
> the failures we are investigating consistent or intermittent oranges?

They were consistent, but I may have tweaked some other things. Need to look at an interdiff.
Comment 40 David Dahl :ddahl 2011-06-28 08:44:29 PDT
Created attachment 542487 [details] [diff] [review]
v 0.8 removed conditional hud checks. all tests pass

ok, looks like I may have had a wonkey build. clobbered, removed hud checks and all tests do pass now. very weird.
Comment 41 Mihai Sucan [:msucan] 2011-07-05 13:52:18 PDT
Created attachment 544049 [details] [diff] [review]
v 0.9 rebase and cleanup

Updated the patch.

Rebased, some cleanup and exceptions fixed.

Looking forward to your review. Thank you!
Comment 42 Mihai Sucan [:msucan] 2011-07-06 12:43:23 PDT
Updating bug title to reflect what the patch is about.
Comment 43 Mihai Sucan [:msucan] 2011-07-06 13:04:53 PDT
Created attachment 544320 [details] [diff] [review]
v 0.10 rebase, fix for iframes and scroll to bottom

Updated the patch. Rebased, fixed code for iframes and added logic to scroll to the bottom of the outputNode. Minimal changes, actually (only +20 lines or so).
Comment 44 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-07-06 13:31:03 PDT
Comment on attachment 544320 [details] [diff] [review]
v 0.10 rebase, fix for iframes and scroll to bottom

>diff --git a/toolkit/components/console/hudservice/HUDService.jsm b/toolkit/components/console/hudservice/HUDService.jsm

>+  getInnerWindowId: function HS_getInnerWindowId(aWindow)

Don't think it's necessary to add a generic helper given that you're only adding one caller - just inline this code.

>+  displayCachedConsoleMessages: function HUD_displayCachedConsoleMessages()

>+    // get the messages from the storageService:
>+    let windowId = HUDService.getInnerWindowId(this.contentWindow.top);

Isn't contentWindow.top == contentWindow guaranteed to be true? I would hope that HUDs only get attached to top-level windows, so if it isn't I think we have a bug to fix!

>+    // Scroll to bottom.
>+    if (this.outputNode.firstChild) {
>+      this.outputNode.ensureIndexIsVisible(this.outputNode.childNodes.length - 1);

How about:
let numChildren = this.outputNode.childNodes.length;
if (numChildren)
  this.outputNode.ensureIndexIsVisible(numChildren - 1);

(I would suggest using itemCount, but its getter seems horribly expensive. :( )

r=me with those addressed.
Comment 45 Mihai Sucan [:msucan] 2011-07-07 01:59:16 PDT
Pushed this patch and the dependencies to the try server.

Results are green:

http://tbpl.mozilla.org/?tree=Try&rev=c43bd1b03e3c

Builds and logs:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mihai.sucan@gmail.com-c43bd1b03e3c
Comment 46 Mihai Sucan [:msucan] 2011-07-07 05:39:25 PDT
(In reply to comment #44)
> Comment on attachment 544320 [details] [diff] [review] [review]
> v 0.10 rebase, fix for iframes and scroll to bottom
> 
> >diff --git a/toolkit/components/console/hudservice/HUDService.jsm b/toolkit/components/console/hudservice/HUDService.jsm
> 
> >+  getInnerWindowId: function HS_getInnerWindowId(aWindow)
> 
> Don't think it's necessary to add a generic helper given that you're only
> adding one caller - just inline this code.

If you do not mind, I am going to keep this because it's also used in multiple places in bug 611032.


> >+  displayCachedConsoleMessages: function HUD_displayCachedConsoleMessages()
> 
> >+    // get the messages from the storageService:
> >+    let windowId = HUDService.getInnerWindowId(this.contentWindow.top);
> 
> Isn't contentWindow.top == contentWindow guaranteed to be true? I would hope
> that HUDs only get attached to top-level windows, so if it isn't I think we
> have a bug to fix!

Good point! Checked the code and yes contentWindow == contentWindow.top.

Thanks for your r+!
Comment 47 Mihai Sucan [:msucan] 2011-07-07 05:43:09 PDT
Created attachment 544446 [details] [diff] [review]
v 0.11 comments addressed

Comments addressed.

Thanks!
Comment 48 Mihai Sucan [:msucan] 2011-08-02 11:27:08 PDT
Created attachment 550136 [details] [diff] [review]
v 0.12 rebase

Rebased patch.
Comment 49 Mihai Sucan [:msucan] 2011-08-04 05:38:35 PDT
Created attachment 550661 [details] [diff] [review]
v 0.13 rebase

Another rebase.
Comment 50 Rob Campbell [:rc] (:robcee) 2011-10-05 14:51:41 PDT
what's going on here? This bug hasn't been poked in a couple of months so I'm giving it a stern poking.
Comment 51 Mihai Sucan [:msucan] 2011-12-24 10:44:28 PST
*** Bug 713385 has been marked as a duplicate of this bug. ***
Comment 52 Mihai Sucan [:msucan] 2012-01-06 13:04:20 PST
Created attachment 586537 [details] [diff] [review]
[in-fx-team] v 0.14 rebase

Rebased patch.
Comment 53 Mihai Sucan [:msucan] 2012-01-11 07:50:04 PST
Comment on attachment 586537 [details] [diff] [review]
[in-fx-team] v 0.14 rebase

Landed:
https://hg.mozilla.org/integration/fx-team/rev/7c20376168c8
Comment 54 Tim Taubert [:ttaubert] 2012-01-13 02:57:14 PST
https://hg.mozilla.org/mozilla-central/rev/7c20376168c8
Comment 55 Eric Shepherd [:sheppy] 2012-04-23 10:04:27 PDT
Documentation updated:

https://developer.mozilla.org/en/DOM/console

Mentioned on Firefox 12 for developers.

Note You need to log in before you can comment on or make changes to this bug.