392570 - "No chrome package registered for chrome://browser/content/contentAreaUtils.js", starting Venkman

Status: RESOLVED FIXED

(Other Applications Graveyard :: Venkman JS Debugger, defect)

Description

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007081702 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Starting Venkman, each time, all (new) profiles,
Error Console says:
{{
No chrome package registered for chrome://browser/content/contentAreaUtils.js .
}}

I'm not sure if this is a SeaMonkey or Venkman bug ?

Comment 1

[Robert Kaiser]

It's a venkman bug. contentAreaUtils should be used from toolkit, i.e. chrome://global and not from an app-specific resource (which is Firefox-specific in this case).

It would help if you'd find the specific place where this is referenced.

Comment 2

[Serge Gautherie (:sgautherie)]

<http://mxr.mozilla.org/seamonkey/source/extensions/venkman/resources/content/venkman-scripts.xul>
{{
  57     <script src="chrome://communicator/content/contentAreaUtils.js"/>
  58     <script src="chrome://communicator/content/contentAreaDD.js"/>
  59     <script src="chrome://communicator/content/findUtils.js"/>
  60     <script src="chrome://browser/content/contentAreaUtils.js"/>   // This error.
}}

All other scripts are either |//global/| or |//venkman/| :-)

Comment 3

[Robert Kaiser]

yup, sounds like lines 57 and 60 should be replaced by a single pointer to chrome://globalr/content/contentAreaUtils.js

Comment 4

[Serge Gautherie (:sgautherie)]

Exactly ! (s/globalr/global/ ;->)
Would |/global/| "still" work with older MAS/SM versions apps, as I think Venkman cares about (or used to) ?

What about lines 58 and 59 ?

Comment 5

[Robert Kaiser]

I can't tell about 58 and 59.

Older suite versions will probably not work with that, but I don't think venkman on trunk should care about those.

Comment 6

[James Ross]

This is required for certain versions of the suite and/or Firefox: WONTFIX.

Comment 7

[Serge Gautherie (:sgautherie)]

That's the answer I expected :-<

But couldn't this file be preprocessed ("on (SeaMonkey) Trunk, at least") ?
(Or can the same result be achieved at runtime ?)

Comment 8

[James Ross]

There is at least one option for doing this at run-time, but if it were to be implemented it would be general, for all the included scripts and take a lot of work to ensure it worked correctly. This bug as it stands isn't useful to that, since the line is needed for older versions and does not cause problems on trunk.

Comment 9

[Robert Kaiser]

Sounds to me like we should perhaps even rethink including those chunks of code that uselessly include obsolete code all over the place (venkman, chatzilla) in trunk and future SeaMonkey versions.
Cluttering the error console with bogus error messages and doing nothing about it by just setting to WONTFIX  is not the quality level we expect code included in SeaMonkey by default to have.
Trunk code is expected to work well and without errors with trunk, support for older versions should be done by older versions of the code or clean run- or compile-time switches but not with code that produces errors.

Comment 10

[James Ross]

Thanks for your non-constructive input. If it was easy to include-if-found, it would do that, but since that is not easy it will blindly load whatever is needed.

I'm right on the edge of just saying "fuck it" and leaving Venkman to die right now, as noone else seems to actually care about it in the slightest - especially you, it seems.

If you want to have an error-free output, put in the work to make it happen.

Comment 11

[Robert Kaiser]

the patch is easy. And yes, it might break compat with SeaMonkey 1.x and obsolete versions of Firefox and even more obsolete Mozilla suite versions. And I don't care a bit if any trunk code works with those. And I even expect trunk code to not care about that and work error-free with trunk apps instead.

Comment 12

[James Ross]

Alright, fine.

I am no longer interested in working on anything that involved you.

So long and thanks for all the fucking flames.

Comment 13

[Robert Kaiser]

IMHO, the bug is still valid. No intent to flame, just wanting our software to live up to the quality expected from it.

Comment 14

[Serge Gautherie (:sgautherie)]

James,
Would not preprocessing be a good solution ?

Here is how I understand/see it:
1) SeaMonkey v2 trunk would build with new |/global/|.
2) Firefox v3 trunk (could too, but) would not build/care, as it does not package Venkman. (no change)
3) You could build with the old/compatible code, in order to make Venkman available as an (all apps, all versions) add-on. (as you already do)

That would probably require adding a build flag/option to switch from case 1 to case 3.
(Or maybe you could use a (Venkman) branch to support case 3 ? Just an idea.)
((Actually, any solution ... as long as it would at least be one :-|))

Comment 15

[James Ross]

I don't think that really helps overall - it is just sidestepping the issue (e.g. install new Venkman version, and you get the incorrect 'error' again). The solution I mentioned in comment 8 is the only one I know of which would have been acceptable, but it's a moot point now. I will do what I want with Venkman away from mozilla.org.

Comment 16

[Robert Kaiser]

OK, let's get back to being constructive here.

From what I see, changing to global/content/contentAreaUtils.js may work for Firefox/Thunderbird 1.5 and later as well as SeaMonkey 2, but breaks SeaMonkey 1.x, Mozilla suite and maybe FF/TB 1.0 - the question is which of those venkman wants to support right now, and which can be dropped when.

If the conclusion is that venkman can't drop this right now and there's no really intelligent solution to use different files in different versions, it's probably a good idea to keep this bug around and target is to the Future, picking it up when requirements are at a point where the compat for older versions can be dropped.

Comment 17

[Thomas Koeppen]

this issue still exists with FF3, Venkman version 0.9.87.4

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.3) Gecko/2008092510 Ubuntu/8.04 (hardy) Firefox/3.0.3

No chrome package registered for chrome://communicator/content/contentAreaUtils.js
No chrome package registered for chrome://communicator/content/contentAreaDD.js
No chrome package registered for chrome://communicator/content/findUtils.js

dev user expect a clean error console, so it would be cool, if this bug will have to be fixed.

-
The web development goes on, and the question his, does venkman (current trunk) really need to support quite old version of FF/TB/SeaMonkey etc.

If you really want to be user-friendly:
It could be quite easy for the owner of 
http://www.hacksrus.com/~ginda/venkman/usage-daily.txt
to add to these stats a user-agent and venkman version field, because you have both information in your access log and then version-compatibility decision is quite easy.

But i suggest to let venkman be compatible for example to FF2.x or FF3.x and other 'current' version of software (TB, Seamonkey etc.). If anybody really need to develop against deprecated versions of browsers, he can use an older version of Venkman, that support it.

Comment 18

[:Gijs (he/him)]

(In reply to comment #17)
> this issue still exists with FF3, Venkman version 0.9.87.4
This bug is open, there was no need for you to confirm that...

> The web development goes on, and the question his, does venkman (current trunk)
> really need to support quite old version of FF/TB/SeaMonkey etc.
<snip>
> But i suggest to let venkman be compatible for example to FF2.x or FF3.x and
> other 'current' version of software (TB, Seamonkey etc.). If anybody really
> need to develop against deprecated versions of browsers, he can use an older
> version of Venkman, that support it.

SeaMonkey 1.1.x wasn't deprecated the last time I checked.

Comment 19

[Serge Gautherie (:sgautherie)]

Given bug 475012 comment 6, can this bug be worked on now, or not yet ?

Comment 20

[:Gijs (he/him)]

(In reply to comment #19)
> Given bug 475012 comment 6, can this bug be worked on now, or not yet ?

Are you asking us to ignore the latest stable version of SeaMonkey? Because, you know, we could do that, but I'm fairly sure some people would be upset.

Comment 21

[Robert Kaiser]

As long as venkman wants to support SeaMonkey 1.x, we can't do anything there. Note that this is worse on the side of non-SeaMonkey host applications, as there are more communicator than browser files included here ;-)
In any case, even if this "pollutes" the Error Console, it doesn't create any malfunctions, so it is tolerable, despite the ugly comments I made eons ago in here.

Comment 22

[Serge Gautherie (:sgautherie)]

Ftr, we will want to undo bug 418543 comment 21 too, to fix
{
Warning: Error in parsing value for 'white-space'.  Declaration dropped.
Source File: chrome://venkman/content/venkman-output-base.css
Line: 58
}

Comment 23

[Serge Gautherie (:sgautherie)]

SeaMonkey 1.1.x was EndOfLife'd, so we should now be able to work on this.

Comment 24

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Load contentAreaUtils.js from Toolkit, Document SeaMonkey contentAreaDD.js [Checked in: Comment 26]

Comment 25

[:Gijs (he/him)]

Comment on attachment 513005 [details] [diff] [review]
(Av1) Load contentAreaUtils.js from Toolkit, Document SeaMonkey contentAreaDD.js
[Checked in: Comment 26]

r=me

Comment 26

[Serge Gautherie (:sgautherie)]

Comment on attachment 513005 [details] [diff] [review]
(Av1) Load contentAreaUtils.js from Toolkit, Document SeaMonkey contentAreaDD.js
[Checked in: Comment 26]

http://hg.mozilla.org/venkman/rev/9d0c8d226429

Comment 27

[Serge Gautherie (:sgautherie)]

(In reply to comment #8)
> There is at least one option for doing this at run-time

I filed bug 634885.


(In reply to comment #22)
> Ftr, we will want to undo bug 418543 comment 21 too

I filed bug 634887 and bug 634888.