Closed Bug 970914 Opened 6 years ago Closed 6 years ago

The Web Console logging API (console.log, console.info, console.warn, console.error) has been disabled by a script on this page

Categories

(DevTools :: Console, defect)

defect
Not set

Tracking

(firefox27 unaffected, firefox28 unaffected, firefox29 verified, firefox30 verified, firefox-esr24 unaffected, b2g18 unaffected, b2g-v1.1hd unaffected, b2g-v1.2 unaffected, b2g-v1.3 unaffected, b2g-v1.3T unaffected)

VERIFIED FIXED
Firefox 30
Tracking Status
firefox27 --- unaffected
firefox28 --- unaffected
firefox29 --- verified
firefox30 --- verified
firefox-esr24 --- unaffected
b2g18 --- unaffected
b2g-v1.1hd --- unaffected
b2g-v1.2 --- unaffected
b2g-v1.3 --- unaffected
b2g-v1.3T --- unaffected

People

(Reporter: sole, Assigned: msucan)

References

Details

(Keywords: regression)

Attachments

(1 file)

I am getting this thing occasionally while I try to debug scripts running in the Browser, and when that happens I can't see my console.log stuff - so I can't debug!

The setup is like this:

1. having the simulator open
2. open the Browser app
3. go to a URL where there's an app I want to simulate installing as a hosted app (currently using a local server)
4. in the app manager go to "Device"
5. click "Browser" -> Debug
6. go to the Console tab to see what's going on in the page running on the Browser
7. sometimes I get that message and then it's the end of it-no more console.log

I don't know why this happens but it's really annoying.
+1

This is happening to me constantly lately. It seems to be a bug in App Manager. What I've found that seems to work (but is still very annoying) is the following:

1. Disconnect USB
2. Start app on device to debug (e.g.: Browser or Camera)
3. Connect USB
4. Connect in App Manager
5. Click "Debug" on app in list in App Manager

When I do that, I seem to not get the message about the Web Console logging API being disabled.
I used to see a message like this when there were conflicts between the old firebug plugin and the new developer tools console.  I have no idea if that is related at all.
I don't have firebug installed.
No Firebug installed here either.
I've seen this bug with the console but only when the last-active tab is not the console tab. You shouldn't need to reconnect the USB at all. What I only needed to is to close the toolbox for that app and start Debug again.

If the situation is *that* bad you can try ./adb shell stop b2g, then ./adb shell start b2g.

Paul, did something change recently in the app manager that might affect the console?
Taking the bug. This is also happening with the following STR:

1. open firefox nightlies in your desktop OS (linux/mac/windows).
2. open devtools for a page tab.
3. switch to the network tab.
4. close devtools.
5. reopen devtools.
6. switch to the console tab.

At this point you will see the 'web console logging API disabled' warning, and messages from the console API are not displayed. Scripts and style errors are not displayed either.

Culprit identified, working on a fix.
Assignee: nobody → mihai.sucan
Status: NEW → ASSIGNED
Depends on: 933212
Keywords: regression
Attached patch bug970914-1.diffSplinter Review
This is caused by bug 933212 where if there's already a console client (attachConsole), we get the same WebConsoleClient instance, and startListeners is not called. The webconsole code gets confused: it receives an empty response, that seems to indicate the remote target doesnt have a native console API, and the listeners are not called - hence no console API logging happens, no page error logging.

This fix should probably go in aurora as well. I expect this is also going to fix the Firefox OS problems where there might be additional users of the console actor.

Try push: https://tbpl.mozilla.org/?tree=Try&rev=adf518ec5933

(should we move the bug to the "Developer Tools: Console" component?)
Attachment #8381501 - Flags: review?(past)
Ugh, I see. Can't we just pass the cached response to attachConsole's callback, as we do in the tab client case? There shouldn't be any need for an extra protocol request if we are about to reuse the existing client.
Component: Simulator → Developer Tools: Console
Product: Firefox OS → Firefox
Version: unspecified → Trunk
(In reply to Panos Astithas [:past] from comment #8)
> Ugh, I see. Can't we just pass the cached response to attachConsole's
> callback, as we do in the tab client case? There shouldn't be any need for
> an extra protocol request if we are about to reuse the existing client.

That would cause the same error as now. The network monitor only starts the NetworkActivity listener, the webconsole starts all listeners. If we don't send the startListeners request, we are back to the same problem.
Comment on attachment 8381501 [details] [diff] [review]
bug970914-1.diff

Review of attachment 8381501 [details] [diff] [review]:
-----------------------------------------------------------------

I see, different tools may reuse the same client, so we would have to compare the requested listeners between the two protocol requests to see if we can skip the extra packet. That doesn't seem super important as I expect the repeated identical request to be less common than the request from a different tool.
Attachment #8381501 - Flags: review+
Thanks!
Keywords: checkin-needed
https://hg.mozilla.org/integration/fx-team/rev/4572f97a634e

Friendly reminder that your commit messages should be summarizing what the patch is doing, not re-stating the problem :)
Flags: in-testsuite+
Keywords: checkin-needed
Whiteboard: [fixed-in-fx-team]
Comment on attachment 8381501 [details] [diff] [review]
bug970914-1.diff

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 933212, details in comment #7.
User impact if declined: the web console fails to receive window.console messages, script errors and CSS warnings from the page, if other devtools that use the console actor are first opened - mainly the network monitor. This also impacts b2g.
Testing completed (on m-c, etc.): landed in fx-team, green try push.
Risk to taking this patch (and alternatives if risky): minimal, it only makes sure that the startListeners request to the console actor is always sent, even if the console actor is already attached to the client.
String or IDL/UUID changes made by this patch: none.
Attachment #8381501 - Flags: approval-mozilla-aurora?
OS: Mac OS X → All
Hardware: x86 → All
https://hg.mozilla.org/mozilla-central/rev/4572f97a634e
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 30
Mihai, could you update the status flags regarding b2g? I don't know which versions are affected. thanks!
Flags: needinfo?(mihai.sucan)
Attachment #8381501 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to Sylvestre Ledru [:sylvestre] from comment #15)
> Mihai, could you update the status flags regarding b2g? I don't know which
> versions are affected. thanks!

The problem this patch fixes impacts connections to b2g, but the fix is in the debugger client. Even if the dbg-client.jsm file is in the b2g codebase, it's not used. Panos can correct me if I am mistaken.

Thanks for the aurora approval.
Flags: needinfo?(mihai.sucan)
The debugger client is now used in the new Devtools HUD (b2g/chrome/content/devtools.js), but that use is quite limited and does not suffer from this bug from what I can tell (there is no network-monitor-like indicator there). So I don't think this fix needs uplift to b2g-specific branches.
(In reply to Panos Astithas [:past] from comment #17)
> The debugger client is now used in the new Devtools HUD
> (b2g/chrome/content/devtools.js), but that use is quite limited and does not
> suffer from this bug from what I can tell (there is no network-monitor-like
> indicator there). So I don't think this fix needs uplift to b2g-specific
> branches.

Do they use the console actor? For reflow activity or anything like that.
Yes, but with only one console client, which should be harmless even without this fix. See the single startListeners call in that file.
I just wanted to thank you guys for addressing this issue so quickly! It really helps improve my efficiency and workflow and is much MUCH appreciated!!
Keywords: verifyme
Reproduced the issue using the steps from comment 6.
Verified as fixed on Firefox 29 beta 4 (20140331125246) and latest Aurora 30.0a2 (20140401004001) under Win 7 64-bit, Ubuntu 32-bit and MAC OSX 10.8.5.
Status: RESOLVED → VERIFIED
Keywords: verifyme
QA Contact: petruta.rasa
Hi,
Platform
 Mac version :10.10.3 and firefox 43.
we are facing the issue "The Web Console logging API (console.log, console.info, console.warn, console.error) has been disabled by a script on this page" 

Am working on below projects
https://gist.github.com/CGenie/fc63536a8467ae6ef945

Am trying to print the console output in my pycharn console, am not able to get it. 

Is there any solution for getting the console output in firefox 43 ?
(In reply to Harikrishnan from comment #23)
> Hi,
> Platform
>  Mac version :10.10.3 and firefox 43.
> we are facing the issue "The Web Console logging API (console.log,
> console.info, console.warn, console.error) has been disabled by a script on
> this page" 
> 
> Am working on below projects
> https://gist.github.com/CGenie/fc63536a8467ae6ef945
> 
> Am trying to print the console output in my pycharn console, am not able to
> get it. 
> 
> Is there any solution for getting the console output in firefox 43 ?

Please file a new bug with this issue.
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.