191992 - modern.jar is packaged in zip builds

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

There are a series of problems here, and it's all rather complicated:

1, primarily: packages are being built (venkman, chatzilla and inspector in the
developer builds + embed-sample in the release builds) that supply contents.rdf
files that have assertions referencing "modern" - this causes the Themes panel
to check the name arc on whichever of them it finds first. 

One (or more, or all) of these packages is wrongly providing a "Name" arc when
it identifies itself as supporting the modern theme, as a rule extensions should
not provide names of existing themes because when the extension contents.rdf
file is aggregated into the chrome registry datasource the order of assertion
retrieval is undefined in the interface of nsIRDFDataSource (it may not be in
implementation, but we can't rely on that). Only the 'global' package should
have the Name arc. If these packages did not provide a displayName arc, the
content builder would never find a value to put in the tree cell and
theoretically a row would not be built. (If this does not happen then the
preferences themes panel should be modified to use the new template syntax to
make the presence of a "displayName" arc required via a condition).

2 - as a corollary, release builds are getting embedding-sample built. This is
not something that means anything to release builds, and it should be ifdef'ed
out somehow. ifndef MOZ_PHOENIX in mozilla/embedding/browser/Makefile.in seems
one option (although it doesn't fix it for Mozilla)

Issue (1) needs to be fixed.

Comment 1

[Ben Goodger (use ben at mozilla dot org for email)]

(2) couldn't hurt, it's just an observation I made whilst tracking down this bug. 

As an additional item, Phoenix shouldn't be distributing any modern.jar - it's
unnecessary disk bloat. extensions/cookie currently indiscriminately creates
modern.jar. We could either make an installer script that doesn't bundle the
file (easy enough in the short term, and the best blanket fix for rogue
modern.jar creations) and (eventually) replace the cookie FE module (yay!) with
something built into mozilla/browser.

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

Let me clarify what I've said earlier, since I realize I've made some mistakes:

Modern should not show up in the list if a displayName arc is not present.
Inspector includes an appropriate contents.rdf file that does not duplicate
arcs, and so the presence of Inspector should not cause Modern to show up (the
only thing I can think of is the old-style template rule may not support
conditions? and thus show a blank row... I don't know the specifics of the old
style template implementation enough to say). That would be fixed by shifting to
a new style template. 

It is the packages that supply a displayName redundantly that are causing the
problem. Cleaning up the mozilla repository would serve as a good example to
others, but I doubt we can get everyone to change. As such, it might also be an
idea to adapt the ChromeReg to only return in the theme list themes that have
supplied core package data - e.g. global is supplied. 

Comment 3

[Sébastien Delahaye]

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

Comment 4

[noririty]

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

Comment 5

[Mike Connor [:mconnor]]

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

Comment 6

[Hal Canary]

Attachment: Screenshot of options menu

On a related topic, the image associated with the default Firebird theme is
incorrect.

Comment 7

[Tom Sommer]

Comment 6: Try a nightly build, the screenshot of the default theme has been
changed there.

Comment 8

[Mike Connor [:mconnor]]

taking QA contact, sorry about the bugspam

Comment 9

[Simon Paquet [:sipaq]]

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

Comment 10

[Simon Paquet [:sipaq]]

Ben, when experimenting with my own builds, I found a workaround for this problem:
 
1. Go to the chrome folder in the firebird application directory.
2. Delete chrome.rdf
3. Open installed-chrome.txt
4. Remove all three lines containing "embed".
5. Start Firebird.

Comment 11

[Simon Paquet [:sipaq]]

Adjusting OS and Hardware.

Comment 12

[Mike]

Is it possible to create a patch deleting the lines mentioned in comment 10?

Comment 13

[alanjstr]

Please see Comment 2.  

Comment 14

[James F. Cerra]

I can confirm that Sipaq's workaround in comment 10 removes the item, "Modern",
from the list of themes in my browser.  I'm using the 0.7 RC branch of Mozilla
Firbird (build 20031007) on Windows XP.

Comment 15

[Asa Dotzler [:asa]]

This is fixed, isn't it? 

Comment 16

[alanjstr]

modern.jar is still packaged, afaik, and I have Modern listed in my build.  I
haven't noticed a checkin that changes this.  I will verify with a newer build.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031114
Firebird/0.7+

Comment 17

[alanjstr]

Confirmed still there in 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031125
Firebird/0.7+

Make sure you try the zip build and not the installer build, because Ben was
more selective there.

Comment 18

[Casey Weston]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031218
Firebird/0.7+

WFM no Modern in the themes list, but I used the installer, if we are going to
installer only with no zip shouldnt we invalidate this if its not longer the
case with the installer?

Comment 19

[alanjstr]

This bug won't be Fixed until the root cause is corrected and modern.jar is not
built and does not show up for any build.

Comment 20

[Mike Connor [:mconnor]]

this isn't a showstopper

Comment 21

[Karl Guertin]

This is not longer present in the Firefox 0.8 release and modern.jar doesn't
show up in chrome, is this bug fixed?

Comment 22

[José Jeria]

No, it is still present in zip builds.
Seing it with build 20040214.

Comment 23

[Jeff Walden [:Waldo]]

Fixed now?  It's WFM using 20040318 Win32 nightly.

Comment 24

[alanjstr]

Jeff-
Did you use the installer?  It's still there in

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040318
Firefox/0.8.0+

Comment 25

[Jeff Walden [:Waldo]]

(In reply to comment #24)
> Did you use the installer?

Oops, dummy me.  I remembered the issue being fixed with Firefox 0.8, but I'd
forgotten that was only because of the installer (and that it had nothing to do
with the release of 0.8, only the entrance of the installer).  I needed this
cleared up because of a small bit of text in the built-in Firefox Help for 0.9,
so I wanted to be sure of what's included.

I'm setting blocking0.9? because it's an issue that would require a small bit of
information in Help that would be useful for only a small segment of the user
base (those who use the ZIPs) but might easily confuse the vast majority of
those uneducated end users who don't.

(Sorry for the three bits of bugspam my erroneous inquiry caused...)

Comment 26

[Mike Connor [:mconnor]]

if you think there should be a Help update to address this for 0.9, feel free to
file a bug for that, preferably at bugzilla.mozdev.org since that's where the
Firebird Help project is managed.  That isn't enough to block the release.  Too
many people are using the blocking flags as a "please fix this bug" flag instead
of what it really should be, namely a "we should not release with this bug"
nomination.  We've shipped releases for a year with this in place, one more
pre-beta release won't hurt. 

This should certainly be fixed for 1.0, provisionally targeting this bug for
1.0beta, since it does still factor in for other platforms (i.e. Linux).  Ben,
if you disagree, just point me at the right point in the code and reassign to me.

Comment 27

[Ben Goodger (use ben at mozilla dot org for email)]

-ing... only in zip builds. 

Comment 28

[José Jeria]

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

Comment 29

[riscky]

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

Comment 30

[Hussam Al-Tayeb]

(In reply to comment #10)
I tried this workaround, it didn't work.

Comment 31

[Az]

Ben, is this not the kind of polish we want to see in FF 1.0 ?

Comment 32

[Robert Parenton]

(In reply to comment #31)
> Ben, is this not the kind of polish we want to see in FF 1.0 ?

See comment #27

Comment 33

[Steffen Wilberg]

"Modern" doesn't show up in the new themes manager, neither zip nor installer
builds. I don't know whether Ben wants to fix the underlying problem(s), so I'm
leaving this open.

Comment 34

[Ariel Burone]

This does NOT show on the new theme manager (20040913 Firefox/0.10).
Someone should close this bug

Comment 35

[alanjstr]

Please see comment 19

Comment 36

[PikeUK]

We seem to be getting a lot of junk (including the contents of modern.jar) from:

http://lxr.mozilla.org/aviarybranch/source/extensions/cookie/jar.mn#16

Couldn't a lot of that stuff be ifndef-ed out for Firefox? At least the images
that appear in modern.jar, and probably those that appear in classic.jar. The
only place I can find that the images are referenced in Firefox is in
p3pDialog.xul but since we're not even packaging the locale file for that, I
assume we don't use it?

Comment 37

[Mike Connor [:mconnor]]

extensions-cookie blows, we're in the process of deciding how to slaughter and
divide its remains.

Comment 38

[Simon Paquet [:sipaq]]

This was fixed in the wake of the bug 277097 fix

Comment 39

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change