Closed
Bug 78989
Opened 23 years ago
Closed 23 years ago
offline:clicking on Edit|preference|offline results in a xml parser error message
Categories
(SeaMonkey :: MailNews: Backend, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: grylchan, Assigned: mohanb)
References
Details
BuildID: 2001050404
If you click on Edit|preference|offline preference you
will see a XML parsing error window instead of the offline GUI
window.
Reproducible: Always
Steps to Reproduce:
1.Start the May 4th trunk build
2.Go to Edit|preferences|offline
3.
Actual Results: A yellow error message saying "XML parsing error: undefined
entity Line number 33, column 33: align="vertical" title=&window.title;"
-------------------------------^
Expected Results: You expect to see the Offline preferences window (with
Startup mode, When going offline, and when going online).
Happens in both the windows build: 2001-05-04-09-0.9/
and mac build:2001-05-04-09-trunk/
Did not try linux build.
Not sure who to 'assign to': Diane or Mohan.
correction in the windows 2001-05-04-06-trunk build, not in the .9 milestone
build. My mistake. sorry.
OK, change this bug to INVALID and close it now.
Diane
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Comment 3•23 years ago
|
||
why was this resolved as invalid? i see this on linux comm trunk bits
[2001.05.07.08]. reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Miscommunication between Diane and Myself. She thought my comments
about 'which folder' i used on 5/4 was the reason why it should
be invalid (ie I created bug based on the milestone build
2001-05-04-09-0.9 when in fact i was testing the proper build
but I 'typed' the wrong folder name in the comments).
Sorry for the confusion.
We have verified the pref-offline.dtd in the tree. The def is there, and it
is not happening with our own build. Let's see how tomorrow's trunk build
works.
Reassign to mohanb and see if it happens further.
Assignee: dianesun → mohanb
Status: REOPENED → NEW
Tested todays build 2001050804 on NT 4.0. Still see the bug.
Assignee | ||
Comment 9•23 years ago
|
||
We found that this is rather a packaging issue; When code is pulled "Debug &
Release builds" do not have this, but jar file containing "pref-offline.dtd" in
Daily Trunk builds is not updated properly. (time stamps are not matching)
I am not sure whom to assign this in Build & Packaging group.
Comment 10•23 years ago
|
||
granrose or leaf...?
Comment 11•23 years ago
|
||
what jar file? did the .dtd file change its source location any time recently?
Comment 12•23 years ago
|
||
regardless, we didn't change anything in the packaging. most likely someone
moved or renamed a file and didn't update either the packages-* or jar manifest
file. it's up to the engineer responsible for the code to make sure new and
changed files get packaged properly and show up in the release builds.
Comment 13•23 years ago
|
||
pref-offline.dtd was an old file. We should not do anything for Manifest and
Makefile because it was at both places. Also it was in
mozilla\xpfe\components\jar.mn.
Please point out which packge file is changed which is related to this problem.
Comment 14•23 years ago
|
||
wait, it "was an old file" as in "it's not supposed to be used anymore" or, "it
hasn't changed location"?
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.1
Assignee | ||
Updated•23 years ago
|
Priority: -- → P2
Assignee | ||
Comment 15•23 years ago
|
||
-- It has not changed its location. Updated file has to be part of "en-US.jar"
-- Are you assigning clobber_all builds as nightly builds? In that case I guess
we will not encounter this problem.
Comment 16•23 years ago
|
||
This is a commercial-only bug, right? If so it should be moved to Bugscape. The
reason I ask is that there are copies of pref-offline.dtd in both the mozilla
and netscape trees. The entities don't match -- the "Stupid Tax" strikes again.
The two instances of "Mozilla"/"Netscape" could be changed to "The program"
without seeming too odd, thus eliminating the need for two copies of this
file. The commercial one has not been updated in over a year, and the '+' in
ns/AIMGlue/resources/locale/en-US/jar.mn means the commercial copy will take
precedence.
Comment 17•23 years ago
|
||
However the original version had the somewhat generic "Communicator" and was
specifically changed to "Mozilla", which appears to have prompted the creation
of the Netscape copy. CC'ing Ben who appears to have been responsible for that
change to see if a compromise could be reached. I thought Branding text was
supposed to be collected at a common place? Dialogs like this will cause
problems for other distributors like Beonex, too.
Assignee | ||
Comment 18•23 years ago
|
||
This is happening in both Mozilla and NS nightly builds,
Assignee | ||
Comment 19•23 years ago
|
||
-- Yes, I just checked with mozilla nightly build : no problem, checked with NS6
nightly build, so it is commercial-only bug.
Comment 20•23 years ago
|
||
Setting target milestone to 0.9.2 (check it in anytime, even before, when the
tree is open for). Per PDT triage.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Assignee | ||
Comment 21•23 years ago
|
||
Closing this as resolved as this is specific to Commercial Tree;
Checked in changed pref-offline.dtd to commercial tree.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 22•23 years ago
|
||
adding lrg to Cc. Please verify for Gary.
Comment 23•23 years ago
|
||
Verified with 2001060411 builds in windows linux and macos.
vtrunk
Status: RESOLVED → VERIFIED
Comment 24•23 years ago
|
||
These are the actual builds. I used the trunk accidently, and retested using
branch builds
Verified in Windows with 2001060408 build
Verified in Linux with 2001060411 build
Verified in MacOS with 20010600408 build
Reporter | ||
Comment 25•23 years ago
|
||
Verified using commercial trunk builds
2001061504 -win nt 4.0
2001061508 -linux 2.2, red hat 7.0
2001061508 -mac os 9.0.4
Removing keyword vtrunk
Keywords: vtrunk
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•