Closed Bug 966486 Opened 11 years ago Closed 10 years ago

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

Categories

(Core :: DOM: Workers, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1058644

People

(Reporter: Yoric, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [Async:blocker])

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.
Whiteboard: [Async:blocker]
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...
Summary: Make console object usable in chrome workers → Make console object usable in chrome workers not associated with a window
Flags: needinfo?(dteller)
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).
Flags: needinfo?(dteller)
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. :(
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.
(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.
> 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...
Flags: needinfo?(amarchesini)
(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.
Flags: needinfo?(amarchesini)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.