Last Comment Bug 588642 - WebConsole contentwindow setter and getter to allow coexistence of console objects
: WebConsole contentwindow setter and getter to allow coexistence of console ob...
Status: RESOLVED FIXED
[console-3]
:
Product: Firefox
Classification: Client Software
Component: Developer Tools: Console (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: lazy-console
Blocks: 529086
  Show dependency treegraph
 
Reported: 2010-08-18 17:25 PDT by David Dahl :ddahl
Modified: 2012-01-17 10:14 PST (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description David Dahl :ddahl 2010-08-18 17:25:04 PDT
I just spoke with jst about trying to intercept an existing console object and preserve it if possible.

If we create a setter and getter on the inner contentWindow called console, it will be triggered before (he thinks) our console is fully inited. Our init function should be able to  check if there is console.log already in place. If so, we can return undefined from the init function and preserve the existing console.

Before returning, we can then report an error to an already open WebConsole or open the WebConsole and report that there is a console api already in place.
Comment 1 Kevin Dangoor 2010-08-19 11:42:24 PDT
To differentiate between this and bug 583476, I'm setting the subject to note that this bug is about maintaining both our console object and a third party console object that gets defined so that logging could potentially go to both places.

This would be nice to have but is not critical and is potentially fraught with peril.
Comment 2 Rob Campbell [:rc] (:robcee) 2010-10-29 06:04:21 PDT
seems like this should depend on the lazy-console.
Comment 3 David Dahl :ddahl 2010-10-29 07:16:04 PDT
I have since talked to jst about this and this does depend on further polatform work that has not been initiated yet (pretty sure about that).
Comment 4 Nochum Sossonko [:Natch] 2010-11-10 09:28:32 PST
I *think* this can be done by defining and freezing the console (if "console" can't be used, perhaps an __underscore__ object name can? I believe underscores are reserved...) object so that it can be overwritten/changed. I'm still not 100% sure why the console object has to be exposed to content, why shouldn't it be privileged (like the error console and its associated methods)?
Comment 5 David Dahl :ddahl 2010-11-10 11:35:49 PST
(In reply to comment #4)
> I'm still not
> 100% sure why the console object has to be exposed to content, why shouldn't it
> be privileged (like the error console and its associated methods)?

Are you talking about "privileged" as in chrome code? Content devs need to be able to call methods on this object from content JS.
Comment 6 Kevin Dangoor 2010-11-10 11:38:36 PST
The console object needs to be exposed to content because console.log and friends are becoming a de facto standard. Safari, Chrome, Firefox+Firebug and even, it seems, IE8+ have console.log and developers are started to expect it to be there.
Comment 7 Kevin Dangoor 2012-01-17 06:26:59 PST
Is this bug still relevant? I think this was filed before we put a solution in place to handle when Firebug's console was active.
Comment 8 Mihai Sucan [:msucan] 2012-01-17 10:14:06 PST
This seems to be already fixed. Please reopen if I am mistaken. Thanks!

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