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

RESOLVED FIXED

Status

Other Applications
Venkman JS Debugger
RESOLVED FIXED
11 years ago
7 years ago

People

(Reporter: sgautherie, Assigned: sgautherie)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Assignee)

Description

11 years ago
[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

11 years ago
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.
Assignee: general → rginda
Component: General → JavaScript Debugger
Product: Mozilla Application Suite → Other Applications
QA Contact: general → venkman
(Assignee)

Comment 2

11 years ago
<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

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

Comment 4

11 years ago
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

11 years ago
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

11 years ago
This is required for certain versions of the suite and/or Firefox: WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 7

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
IMHO, the bug is still valid. No intent to flame, just wanting our software to live up to the quality expected from it.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 14

11 years ago
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

11 years ago
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

11 years ago
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

10 years ago
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

10 years ago
(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.
(Assignee)

Comment 19

9 years ago
Given bug 475012 comment 6, can this bug be worked on now, or not yet ?
Status: REOPENED → NEW

Comment 20

9 years ago
(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

9 years ago
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.
(Assignee)

Updated

9 years ago
Whiteboard: [Waiting for SeaMonkey 1.1.x EndOfLife]
Target Milestone: --- → Future
(Assignee)

Comment 22

9 years ago
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
}
(Assignee)

Comment 23

7 years ago
SeaMonkey 1.1.x was EndOfLife'd, so we should now be able to work on this.
Whiteboard: [Waiting for SeaMonkey 1.1.x EndOfLife]
Target Milestone: Future → ---
(Assignee)

Comment 24

7 years ago
Created attachment 513005 [details] [diff] [review]
(Av1) Load contentAreaUtils.js from Toolkit, Document SeaMonkey contentAreaDD.js
[Checked in: Comment 26]
Assignee: rginda → sgautherie.bz
Status: NEW → ASSIGNED
Attachment #513005 - Flags: review?(gijskruitbosch+bugs)
(Assignee)

Updated

7 years ago
Severity: minor → normal
OS: Windows 2000 → All
Hardware: x86 → All

Comment 25

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

r=me
Attachment #513005 - Flags: review?(gijskruitbosch+bugs) → review+
(Assignee)

Comment 26

7 years ago
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
Attachment #513005 - Attachment description: (Av1) Load contentAreaUtils.js from Toolkit, Document SeaMonkey contentAreaDD.js → (Av1) Load contentAreaUtils.js from Toolkit, Document SeaMonkey contentAreaDD.js [Checked in: Comment 26]
(Assignee)

Comment 27

7 years ago
(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.
Blocks: 634885
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.