610609 - The console's logging API is disabled after closing and re-opening the console UI

Status: RESOLVED WORKSFORME

(DevTools :: General, defect, P1)

Description

[Maniac Vlad Florin (:vladmaniac)]

Build ID: 

Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101107 Firefox/4.0b8pre

Reproducible also with Fx4b7 candidates. 

=========================================================================
Steps: 
1. Open www.digg.com (this can be a page of your choice)
2. Open console 
3. Toggle in fullscreen mode (F11) 
4. Close console
5. Open again

=========================================================================
Behavior: 

Console echoes 

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

Comment 1

[David Dahl :ddahl]

I can reproduce that without going into full-screen mode. After a reload the console object is gone. Sounds like we need a mochitest for this. This is a regression for sure.

Comment 2

[Kevin Dangoor]

Is the lazy console API likely to change the behavior at all for this?

Comment 3

[David Dahl :ddahl]

(In reply to comment #2)
> Is the lazy console API likely to change the behavior at all for this?

It does change the way we test for the console object - as an instance of Ci.nsIConsoleAPI - which will change further once a patch is created for bug 609955

There will be impact.

Comment 4

[Mihai Sucan [:msucan]]

Checked the code we currently have:

The problem is in unregisterDisplay() where we check if aContentWindow.wrappedJSObject.console instanceof HUDConsole. The check returns false, thus we do not delete the console object from the web page.

Next time when the Web Console is open, it finds the old console object, and complains.

Weird thing is: console.constructor === HUDConsole also fails. (constructor is undefined). Is this compartments landing fun?

I know that this stuff used to work, and constructor === HUDConsole also worked in some other builds I had, since compartments landed.

Somehow, I expect this will still fail once the lazy console stuff lands.

Comment 5

[Kevin Dangoor]

OK, thanks for the investigation, Mihai.

I'm going to request blocking on this because we can't ship the feature with this problem. If we're lucky, the lazy console work will just fix this, but we'll want this bug to track it and make sure.

Comment 6

[Kevin Dangoor]

mass change: filter on PRIORITYSETTING

Comment 7

[Kevin Dangoor]

mass change: filter mail on BLOCKERSETTING

Comment 8

[Kevin Dangoor]

Lazy console has landed. we should check the status of this.

Comment 9

[David Dahl :ddahl]

fixed by bug 587734

Comment 10

[Maniac Vlad Florin (:vladmaniac)]

Build ID:

Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre 

when navigating to http://cnn.com this error reappears. It seems like only http://cnn.com triggers the script that blocks the console logging API. 
This is not happening on Safari. 

Are we letting cnn to block the console's logging API?

Comment 11

[Mihai Sucan [:msucan]]

(In reply to comment #10)
> Build ID:
> 
> Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre 
> 
> when navigating to http://cnn.com this error reappears. It seems like only
> http://cnn.com triggers the script that blocks the console logging API. 
> This is not happening on Safari. 
> 
> Are we letting cnn to block the console's logging API?

Yes, that is known.

CNN.com and other web sites define their own window.console object. We do not overwrite the window.console object, and the warning tells that.