Closed Bug 191992 Opened 22 years ago Closed 19 years ago

modern.jar is packaged in zip builds

Categories

(Firefox :: Settings UI, defect)

Product:
Firefox
Component:
Settings UI
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: bugs, Assigned: bugs)

References

Details

(Keywords: polish)

Attachments

(1 file)

Screenshot of options menu
120.35 KB, image/png
Details 
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.
(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.
Status: NEW → ASSIGNED
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. 
*** Bug 196508 has been marked as a duplicate of this bug. ***
Blocks: 171082
*** Bug 172426 has been marked as a duplicate of this bug. ***
*** Bug 211282 has been marked as a duplicate of this bug. ***
On a related topic, the image associated with the default Firebird theme is
incorrect.
Comment 6: Try a nightly build, the screenshot of the default theme has been
changed there.
taking QA contact, sorry about the bugspam
QA Contact: asa → mconnor
*** Bug 216077 has been marked as a duplicate of this bug. ***
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.
Whiteboard: See comment 10 for a workaround
Adjusting OS and Hardware.
OS: Windows XP → All
Hardware: PC → All
Is it possible to create a patch deleting the lines mentioned in comment 10?
Please see Comment 2.  
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.
This is fixed, isn't it? 
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+
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.
Flags: blocking0.8?
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?
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.
this isn't a showstopper
Severity: normal → minor
Flags: blocking0.8? → blocking0.8-
This is not longer present in the Firefox 0.8 release and modern.jar doesn't
show up in chrome, is this bug fixed?
No, it is still present in zip builds.
Seing it with build 20040214.
Fixed now?  It's WFM using 20040318 Win32 nightly.
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+
(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...)
Flags: blocking0.9?
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.
Flags: blocking0.9? → blocking0.9-
Keywords: polish
Target Milestone: --- → Firefox1.0beta
Flags: blocking1.0?
-ing... only in zip builds.
Flags: blocking1.0? → blocking1.0-
*** Bug 242828 has been marked as a duplicate of this bug. ***
*** Bug 242847 has been marked as a duplicate of this bug. ***
(In reply to comment #10)
I tried this workaround, it didn't work.
Target Milestone: Firefox1.0beta → After Firefox 1.0
Ben, is this not the kind of polish we want to see in FF 1.0 ?
(In reply to comment #31)
> Ben, is this not the kind of polish we want to see in FF 1.0 ?

See comment #27
"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.
This does NOT show on the new theme manager (20040913 Firefox/0.10).
Someone should close this bug
Please see comment 19
Summary: "Modern" shows up in the Themes list → modern.jar is packaged in zip builds
Whiteboard: See comment 10 for a workaround
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?
extensions-cookie blows, we're in the process of deciding how to slaughter and
divide its remains.
This was fixed in the wake of the bug 277097 fix
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: