302215 - red XUL errors: menu_HelpPopup_reportertoolmenu and menu_inspector

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Jens Hatlak (:InvisibleSmiley)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050726 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050726 SeaMonkey/1.0a

After building a current SeaMonkey nightly with --extensions=all, I got the
following XUL error strings at the lower end of the browser window (presented
here is the equivalent output of the JavaScript console):

Error: undefined entity
Source File: chrome://reporter/content/reporterOverlay.xul
Line: 50, Column: 5
Source Code:
    <menuitem id="menu_HelpPopup_reportertoolmenu" 

Error: undefined entity
Source File: chrome://inspector/content/tasksOverlay.xul
Line: 20, Column: 5
Source Code:
    <menuitem id="menu_inspector" label="&inspectorTaskCmd.label;" 

This appeared only recently (i.e. within the last one or two weeks) and can be
reproduced by me with custom Linux and Windows builds.

Reproducible: Always

Steps to Reproduce:
1. Build SeaMonkey from CVS, with --enable-extensions=all
2. Open a browser window; using a fresh profile, if you like

Actual Results:  
XUL errors shown in red letters within chrome

Expected Results:  
No errors should be displayed

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Is your tree current as of today?

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

See bug 301565 and bug 298675.

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #1)
> Is your tree current as of today?

Of course. Both bugs you linked are marked fixed but at least the first one has
a comment from someone also seeing both error messages. Well, I guess I will
just wait until everything is fixed and then mark this one fixed as well since I
currently don't know which bug I should mark this one a duplicate of.

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

Must be Linux-only, then.  

Comment 5

[Andrew Schultz]

this worksforme with linux seamonkey trunk CVS from today as well as today's
nightly.

Did you only get the error after enabling all extensions?

Comment 6

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #5)
> this worksforme with linux seamonkey trunk CVS from today as well as today's
> nightly.

Just made a cvs update and rebuilt; problem still exists.

> Did you only get the error after enabling all extensions?

I'm always building with --enable-extensions=all, and given that reporter and
inspector seem to be broken, it's quite likely that the XUL errors do only
appear if these extensions are activated during configure.

Like I said, I suggest waiting for the other bugs like 301842 to get fixed and
then change the status of this bug.

Comment 7

[Andrew Schultz]

bug 301842 would only be relevant if you were using the install wizard.  Are you
doing that, running from dist/bin or running "make install"?

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #7)
> bug 301842 would only be relevant if you were using the install wizard.  Are you
> doing that, running from dist/bin or running "make install"?

OK, maybe I referred to the wrong bug. Next try:

Bug 301565, comment 22. http://www.triffids.de/pub/screenshot/rot2.png is
exactly what I see.

Comment 9

[yevg]

I confirm this bug exists, but without --enable-extensions=all. Just I build it
from latest CVS with --enable-svg, --enable-svg-renderer-cairo,
--enable-default-toolkit=gtk2, --disable-freetype2, --enable-xft

Comment 10

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #9)
> I confirm this bug exists, but without --enable-extensions=all. Just I build it
> from latest CVS with --enable-svg, --enable-svg-renderer-cairo,
> --enable-default-toolkit=gtk2, --disable-freetype2, --enable-xft

I have SVG enabled as well, but (until now) with the libart renderer. Using GTK2
and having Freetype disabled, too. Didn't explicitly enable XFT, though.

Comment 11

[Andrew Schultz]

*** Bug 306992 has been marked as a duplicate of this bug. ***

Comment 12

[Andrew Schultz]

based on bug 306992, the answer to comment 7 is "make install".  After doing
that, I can reproduce this bug.  Nuking chrome/overlays.rdf fixes the problem.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch?

can anyone test this patch and tell me whether it works?

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: possible patch (with typo fixed)

try this one, not the last one :)

Comment 15

[Andrew Schultz]

Comment on attachment 195329 [details] [diff] [review]
possible patch (with typo fixed)

the directory in reporter/ is locales (not locale).  With that, the patch fixes
the bug.

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

thanks for testing

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in extensions/inspector/resources/Makefile.in;
/cvsroot/mozilla/extensions/inspector/resources/Makefile.in,v  <--  Makefile.in
new revision: 1.14; previous revision: 1.13
done
Checking in extensions/reporter/Makefile.in;
/cvsroot/mozilla/extensions/reporter/Makefile.in,v  <--  Makefile.in
new revision: 1.9; previous revision: 1.8
done

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 195386 [details] [diff] [review]
patch

this patch makes "make install" do the right thing

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

fixed on MOZILLA_1_8_BRANCH for 1.8b5

Checking in extensions/inspector/resources/Makefile.in;
/cvsroot/mozilla/extensions/inspector/resources/Makefile.in,v  <--  Makefile.in
new revision: 1.12.2.2; previous revision: 1.12.2.1
done
Checking in extensions/reporter/Makefile.in;
/cvsroot/mozilla/extensions/reporter/Makefile.in,v  <--  Makefile.in
new revision: 1.7.2.2; previous revision: 1.7.2.1
done