966486 - Make console object usable in chrome workers not associated with a window

Status: RESOLVED DUPLICATE of bug 1058644

(Core :: DOM: Workers, defect)

Description

[David Teller [:Yoric] - still alive but not very active]

Bug 620935 introduced console for web workers. My recent attempts to use it in OS.File cause the following to be displayed instead of any expected message:

0:44.35 [56683] WARNING: NS_ENSURE_TRUE(window) failed: file /Users/david/Documents/Code/mc-osfile/dom/workers/Console.cpp, line 264

Note that bug 620935 actually causes a regression in OS.File, since OS.File used the presence of the |console| object to determine how to display its logs.

Comment 1

[Boris Zbarsky [:bzbarsky]]

What behavior are you looking for?

What we do right now is we proxy the calls over to the console associated with the window.  But you're asking for this API in a context in which there is no window and no associated console...

Comment 2

[David Teller [:Yoric] - still alive but not very active]

Well, I expected it to go to the browser console, which I believe isn't associated to any window (given that we can use it from xpcshell, I'm rather confident in that belief).

Comment 3

[Boris Zbarsky [:bzbarsky]]

The browser console doesn't expose an API compatible with the console API...  It would basically need yet another (5th now?) implementation of the console API.  :(

Comment 4

[David Teller [:Yoric] - still alive but not very active]

In that case, I believe that we should deactivate the console API for chrome workers. In the current state, it just doesn't make sense. Rather, we should provide the necessary support to access the browser console from chrome workers and develop a JS module providing the console API on top of this support.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Boris Zbarsky [:bz] from comment #3)
> The browser console doesn't expose an API compatible with the console API...
> It would basically need yet another (5th now?) implementation of the console
> API.  :(

Can you explain what you mean by this? Are you referring to Console.jsm? I think Mihai's plan has been to eventually unify all the implementations as much as possible, even if that would entail a C++ and a JS part.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> In that case, I believe that we should deactivate the console API for chrome workers.

That seems reasonable for now, yeah.  Andrea?

> and develop a JS module providing the console API on top of this support

I think everyone involved in the console API would _really_ rather not have yet another divergent implementation of it.  We should figure out how to make this work.

> Are you referring to Console.jsm? 

Yes, and Console.js, and the existing worker C++ API and the mainthread C++ reflection of the worker API.

> I think Mihai's plan has been to eventually unify all the implementations as much as
> possible

I think Andrea has some prototype patches for that, fwiw.  But only for the case when we have a Console, which means having a Window...

Comment 7

[Andrea Marchesini [:baku]]

(In reply to Boris Zbarsky [:bz] from comment #6)
> > In that case, I believe that we should deactivate the console API for chrome workers.
> 
> That seems reasonable for now, yeah.  Andrea?

For the moment, yes.

> I think Andrea has some prototype patches for that, fwiw.  But only for the
> case when we have a Console, which means having a Window...

I have a patch that re-implements the Console API in C++. This patch is almost ready for main-thread but I'll submit it once it covers Console API in worker as well. No window is needed.