1005859 - console.log(...) in Firebug will log the string into bulit-in Browser Console of Firefox 29 (PageMod API's bug??)

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[92502073]

Attachment: page-mod-test.xpi

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140428193813

Steps to reproduce:

0. Using firefox 29
1. Create a new firefox profile
2. Install add-on: firebug ( https://blog.getfirebug.com/2014/03/21/firebug-1-13-alpha-10/ )
3. Install add-on: page-mod-test (as attachment, or goto https://github.com/Grassboy/page-mod-test -> page-mod-test.xpi for its source)
4. Restart browser
5. goto http://www.google.com
6. press F12, open firebug console
7. press ctrl+shift+J, open web console
8. in firebug console, execute "console.log(123)", string "123" will display in firebug's console
9. reload the page, repeat step 8, string "123" will display in browser console


Actual results:

console.log(...) in Firebug will log the string into bulit-in Browser Console of Firefox 29


Expected results:

console.log(...) in Firebug should log the string into firebug's console...

----

I've tried removing the code block of PageMod in the addon's source, 
( https://github.com/Grassboy/page-mod-test/blob/master/lib/main.js )
and then console.log will not log into browser console.

maybe we can say "That's firebug's bug, not firefox's"
but the fact is that the bug appeared after I updating firefox to 29
(firebug's version was always 1.13 alpha 10)

There are another addons will cause the bug
(this thread: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/firebug/U5Lik1KetOc/zuWhsgvOdD4J for more discussion)

I've tried that Greasemonkey's userscript with "// @grant GM_xmlhttpRequest" meta comment will cause the bug either.
But I don't know if the use of PageMod api cause this bug too...

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I can confirm the bug. It looks like the native console (WebConsole) is taking over Firebug's after page refresh.

Related Firebug report:
https://code.google.com/p/fbug/issues/detail?id=7442

Panos, anything changed in Firefox 29?
Firefox 28 works just fine.

Honza

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Panos, here is a regression range I found:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=73eefb421e2a&tochange=5e0a22097bff

Honza

Comment 3

[:Gijs (he/him)]

(moving to the devtools console component for now as that's where investigation is happening, but I would not be surprised if other stuff was involved)

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Any tips for workarounds we could do on Firebug side?

There is many users complaining and it's real blocker for Firebug.

Honza

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Note that I have been testing with Firefox 30 and it works well.

Honza

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

So, Firebug needs workaround to bridge the time till Fx 30 is released.
Honza

Comment 7

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Since DevTools toolbox doesn't have to be opened at all in order to reproduce this problem and it's enough to install a simple JetPack extension to cause the problem, it looks like the culprit could be somewhere in Add-ons SDK.

Simple Jetpack extension that causes the problem (see STRs in comment #0):

var pageMod = require("sdk/page-mod");
pageMod.PageMod({
	include: "*",
	contentScript: 'document.title="Page Mod Test"'
});


Honza

Comment 8

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

Clearing the NI? since we discussed this with Honza on IRC.

Comment 9

[Simon Lindholm]

> Panos, here is a regression range I found:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=73eefb421e2a&tochange=5e0a22097bff
Bug 964545 looks initially suspicious but was backed out. Maybe bug 945416 or bug 959012?

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

> Bug 964545 looks initially suspicious but was backed out. Maybe bug 945416
> or bug 959012?

Any tips if any of these commits could cause the problem?

Honza

Comment 11

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

(In reply to Jan Honza Odvarko from comment #10)
> > Bug 964545 looks initially suspicious but was backed out. Maybe bug 945416
> > or bug 959012?
> 
> Any tips if any of these commits could cause the problem?
> 
> Honza

I don't see how those changes would be related to be honest. Only thing I could think of to cause regression from SDK side would fixes for Bug 993520 but even then I don't see how that could be related.

Another thing I can imagine is if somehow expanded principals would interfer with whatever firebug does which gabor may able to answer, but since we don't know what firebug does it's hard to say.

Comment 12

[Gabor Krizsanits (INACTIVE)]

> Another thing I can imagine is if somehow expanded principals would interfer
> with whatever firebug does which gabor may able to answer, but since we
> don't know what firebug does it's hard to say.

I really doubt it. And I'm fairly positive that the answer lays somewhere in bug 965860

Comment 13

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

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #12)
> I really doubt it. And I'm fairly positive that the answer lays somewhere in
> bug 965860

Let's ask Andrea then.

Comment 14

[Andrea Marchesini [:baku]]

I didn't read the Firebug code so I don't know when the console object is overwritten but I guess this operation is done at any refresh of the page. Is this right?
Can you point me to the code where this operation is done? Thanks.

Comment 15

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Andrea Marchesini (:baku) from comment #14)
> I didn't read the Firebug code so I don't know when the console object is
> overwritten but I guess this operation is done at any refresh of the page.
> Is this right?
Yes

> Can you point me to the code where this operation is done? Thanks.
Here is the place where |window.console| object is set:
https://github.com/firebug/firebug/blob/master/extension/content/firebug/console/consoleInjector.js#L77

Honza

Comment 16

[Andrea Marchesini [:baku]]

> > Can you point me to the code where this operation is done? Thanks.
> Here is the place where |window.console| object is set:
> https://github.com/firebug/firebug/blob/master/extension/content/firebug/
> console/consoleInjector.js#L77

Sorry, I'm not familiar with Firebug code. When this object is used? At which point of the loading of the page the console is replaced?

Comment 17

[Florent Fayolle]

> Here is the place where |window.console| object is set:
> https://github.com/firebug/firebug/blob/master/extension/content/firebug/console/consoleInjector.js#L77
> 
> Honza

Just for the future, I give here the last version of this file today (since the code will probably evolve):
https://github.com/firebug/firebug/blob/2813cec2247821c98077d27ef7eb8a7d4e78a7d3/extension/content/firebug/console/consoleInjector.js#L77

> Sorry, I'm not familiar with Firebug code. When this object is used? 

Sorry, what object?

> At which point of the loading of the page the console is replaced?

The method that overrides the |window.console| object is called either : 
- when the user opens Firebug after the page load
- otherwise with the "onLocationChange" kind-of-event:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIWebProgressListener#onLocationChange%28%29
https://github.com/firebug/firebug/blob/2813cec2247821c98077d27ef7eb8a7d4e78a7d3/extension/content/firebug/chrome/tabWatcher.js

(For simplicity, I don't explain the case when the page has IFrames)

Florent

Comment 18

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@Andrea: does Florent's explanation help, or do you need more info?

Honza

Comment 19

[Boris Zbarsky [:bzbarsky]]

> And I'm fairly positive that the answer lays somewhere in bug 965860

It most certainly does not, since that bug was fixed for Firefox 30, but this bug is reported against Firefox 29.  In fact, I will bet bug 965860 fixed this issue; see comment 5.

So I assume the issue here is that when both Firebug and the devtools console are open they both race to define .console on the window, and it happens that Firebug wins the race and then the devtools console clobbers the value it set.

So a workaround might be to define the console in Firebug but then set a 0ms timeout to check whether it got changed and if so define it again, or something.

Comment 20

[92502073]

Excuse me, now I am using Firefox 33 & Firebug

this bug comes again...

is it cause by same issue?

or there is another issue cause this bug?

thanks for your help!!

Comment 21

[Sebastian Zartner [:sebo]]

I cannot reproduce the steps described in comment #0 nor the ones described in the issue Honza linked to in comment #1 using Firefox 32.0.2/33.0 + Firebug 2.0.4 on Win8.1.

So I assume it may be a new bug. Which version of Firebug do you use? What is your test case? If you have other extensions installed, you may disable them and check whether this problem still occurs afterwards. If not, enable the extensions one by one to see which one is the culprit.

Sebastian

Comment 22

[Erik Vold [:erikvold] (please needinfo? me)]

This looks related to WebConsole issues, Irakli can you take a look at this one please?

Comment 23

[Erik Vold [:erikvold] (please needinfo? me)]

(In reply to Boris Zbarsky [:bz] from comment #19)
> > And I'm fairly positive that the answer lays somewhere in bug 965860
> 
> It most certainly does not, since that bug was fixed for Firefox 30, but
> this bug is reported against Firefox 29.  In fact, I will bet bug 965860
> fixed this issue; see comment 5.
> 
> So I assume the issue here is that when both Firebug and the devtools
> console are open they both race to define .console on the window, and it
> happens that Firebug wins the race and then the devtools console clobbers
> the value it set.
> 
> So a workaround might be to define the console in Firebug but then set a 0ms
> timeout to check whether it got changed and if so define it again, or
> something.

Honza does this seem like a solution to you?

Comment 24

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Erik Vold [:erikvold] (please needinfo? me) from comment #23)
> (In reply to Boris Zbarsky [:bz] from comment #19)
> > > And I'm fairly positive that the answer lays somewhere in bug 965860
> > 
> > It most certainly does not, since that bug was fixed for Firefox 30, but
> > this bug is reported against Firefox 29.  In fact, I will bet bug 965860
> > fixed this issue; see comment 5.
> > 
> > So I assume the issue here is that when both Firebug and the devtools
> > console are open they both race to define .console on the window, and it
> > happens that Firebug wins the race and then the devtools console clobbers
> > the value it set.
> > 
> > So a workaround might be to define the console in Firebug but then set a 0ms
> > timeout to check whether it got changed and if so define it again, or
> > something.
> 
> Honza does this seem like a solution to you?
Yep, sounds reasonable, but first I need a reproducible test case that can
be used to see the problem on my machine.

Honza

Comment 25

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Given that there is proposed workaround I don't think my needinfo is required from me.

Comment 26

[Sebastian Zartner [:sebo]]

As the future of Firebug is being integrated into the DevTools, this might be closed as WONTFIX.
Honza, what do you think?

Sebastian

Comment 27

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Yes, I am closing this one.

Honza