Closed Bug 1136995 Opened 9 years ago Closed 5 years ago

[e10s] Browser Console fails to logging from page contents console.log(event.target);

Categories

(DevTools :: Console, defect, P2)

Product:
DevTools
Component:
Console
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1441711

People

(Reporter: alice0775, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

consolelogging.html
272 bytes, text/html
Details
console.html
329 bytes, text/html
Details
Attached file consolelogging.html — 
Build Identifier:
https://hg.mozilla.org/mozilla-central/rev/07c04d7a483a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 ID:20150225030226

Steps To Reproduce:
1. Open e10s window
2. Open Browser Console (Ctrl+Shift+J)
3. Open the attached
4. Click "Click here"

Actual results:
"<unavailable>"

Expected results:
<div id="d">
Blocks: dte10s
OS: Windows 7 → All
Hardware: x86_64 → All
Status: NEW → UNCONFIRMED
Ever confirmed: false
I can reproduce the problem on latest Nightly with clean new profile.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file console.html — 
Confirmed on:
Firefox Nightly 41.0a1 (2015-05-16)
____________________________________________________________________________________________________

var o = {
  n: null,
  b: true,
  i: 100,
  s: "text",
  a: [1, 2],
  o: {k: 1},
  d: document.body,
}
 
console.log(o, o.n, o.b, o.i, o.s, o.a, o.o, o.d, Object.keys(o));
____________________________________________________________________________________________________

With e10s on:
<unavailable> null true 100 text <unavailable> <unavailable> <unavailable> <unavailable>

With e10s off:
Object { n: null, b: true, i: 100, s: "text", a: Array[2], o: Object, d: <body> }
null true 100 "text" Array [ 1, 2 ] Object { k: 1 } <body>
Array [ "n", "b", "i", "s", "a", "o", "d" ]
Why do you need to see this message in the Browser Console? It appears fine in the web console, where content messages are supposed to be logged.

I agree that it is a bug to display <unavailable> in the Browser Console, but in bug 860705 we are going to remove content messages from the browser console anyway.
Flags: needinfo?(alice0775)
(In reply to Panos Astithas [:past] from comment #5)
> Why do you need to see this message in the Browser Console? It appears fine
> in the web console, where content messages are supposed to be logged.
> 
> I agree that it is a bug to display <unavailable> in the Browser Console,
> but in bug 860705 we are going to remove content messages from the browser
> console anyway.

Web console is not enough sometimes.

Because, web console would not open automatically when page was opened in new tab/nnew window/new popup window.
So, It is not possible to see the log without reload. Reloading page is sometimes impossible.
Because the behavior of the page is different between initial load and reloading due to referrer/cache/login/session cookies/etc...
Flags: needinfo?(alice0775)
Can you post an example page that doesn't display log messages in the web console? Opening the console in a new tab or window should work.
(In reply to Panos Astithas [:past] from comment #7)
> Can you post an example page that doesn't display log messages in the web
> console? Opening the console in a new tab or window should work.

This breaks the Hello case - in bug 1154273 we're switching to have the conversation window run in the e10s process. Our only console access there is via the browser console/toolbox.

Specifically, when running in e10s mode, we now have:

[Dispatcher] Dispatching action <unavailable>

in the browser console, whereas in non-e10s mode we have object information.

This can be tested currently by switching the "loop.remote.autostart" pref to true and starting in e10s mode, then opening the conversation window (note: the panel also displays the dispatching action messages, but interacting with items in the conversation window should display this unavailable messages).
Blocks: loop-e10s
Flags: needinfo?(past)
In this case you want to use the console in the Browser Content Toolbox. It provides proper access to frame scripts and code running in the content process with chrome privileges.
Flags: needinfo?(past)
Thank you that works for getting the descriptions.

I think I can see some cases where its going to make things a lot harder for us - e.g. we're not going to be able to simply request logs and debugging when we're tracking events going between the chrome & content process is going to be a lot harder.

Is there a likelihood that could be fixed/improved?
(In reply to Mark Banner (:standard8) from comment #10)
> Thank you that works for getting the descriptions.
> 
> I think I can see some cases where its going to make things a lot harder for
> us - e.g. we're not going to be able to simply request logs and debugging
> when we're tracking events going between the chrome & content process is
> going to be a lot harder.
> 
> Is there a likelihood that could be fixed/improved?

I think this is the same problem as bug 1215120.  Which is, object serialization is failing so we need a console actor running per thread/process and hook the frontend up to multiple actors.
See Also: → 1215120
Wasn't sure if this is related, but I'm getting the error message <unavailable>, if I used a comma instead of using a plus sign when calling console.error().

http://i.imgur.com/9DrCJHh.png

http://i.imgur.com/d5j26SE.png

This is happening while developing the WebExtension add-on in FF Beta v56.0b3. Unfortunately, the codebase I'm working on cannot be viewed publicly. 

The code is pretty much the following:

new Promise((resolve) => { ... }).catch((e) => {
    console.error("(shoptoolbar.js) Error - ", e);
    console.error("(shoptoolbar.js) Error (with commas) -", e);
    console.error("(shoptoolbar.js) Error (without commas) -" + e);    
});

Swapping the console.error() calls is what I've got for the second screenshot. It is hard to reproduce in test codes, because I'm not sure what is triggering this problem. I'm still researching into it.
Product: Firefox → DevTools

Pretty sure we have another bug for this, will try to find it_

I think Fission will help here.

tracking-e10s: + → ---
Priority: -- → P2
Blocks: dt-fission-console
No longer blocks: dte10s, loop-e10s
No longer depends on: dt-fission

Note that STR from comment 0 is now fixed by Bug 1441711 (if devtools.browsertoolbox.fission pref is set to true)

No longer blocks: dt-fission-console
Depends on: 1578228
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: