Closed Bug 253603 Opened 20 years ago Closed 20 years ago

help window fails to appear in trunk (Windows)

Categories

(SeaMonkey :: Help Viewer, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 245810

People

(Reporter: bugzilla, Assigned: bugs)

Details

found using 2004072912-trunk on linux fedora core 1. couldn't find an existing bug on this, but pls dup or reassign as needed. to test, try to open the Help Contents window: either select Help > Help Contents from the menu, or hit F1. expected: Help Contents window opens. actual results: get error dialog, "XML Parsing Error: xml processing instruction not at start of external entity. Location: chrom://help/content/help.xul. Line Number 1, Column 1" note: this is *not* a problem on the branch (as tested with 2004072908/10-0.9, linux or mac). nor can I repro this with a mac trunk build...then again, bug 244479 is preventing the Help Contents (among other things) from appearing in the menu. could bug 251165 be related here?
this also occurs on Windows XP; tested with 2004072908-trunk. the only difference, though, is that the yellow error dialog is empty.
OS: Linux → All
Summary: help window fails to appear in linux trunk → help window fails to appear in trunk
Trunk help is obsolete and not currently being developed. Help on the aviary branch will land on the trunk after Firefox 1.0.
Status: NEW → ASSIGNED
(In reply to comment #2) > Trunk help is obsolete and not currently being developed. Help on the aviary > branch will land on the trunk after Firefox 1.0. RJ, I'm wondering why you didn't just tell me that a week ago when I reported the same issue in bug 252166. You resolved this as a WFM then. Now suddenly the code is rotted(?)
(In reply to comment #3) > (In reply to comment #2) > > Trunk help is obsolete and not currently being developed. Help on the aviary > > branch will land on the trunk after Firefox 1.0. > > RJ, I'm wondering why you didn't just tell me that a week ago when I reported > the same issue in bug 252166. You resolved this as a WFM then. Now suddenly > the code is rotted(?) I didn't realize your problem was on the trunk. I thought you were talking about the aviary branch. Sorry.
This should be fixed now.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Still broken in the 2004081708 trunk build.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Bill, what platform/OS are you on? this now w4m using 2004081712-trunk on linux. I'm in the office, so will check on WinXP and Mac.
(In reply to comment #7) > Bill, what platform/OS are you on? this now w4m using 2004081712-trunk on linux. > > I'm in the office, so will check on WinXP and Mac. Win2000.
I can repro this on WinXP. but not a problem on Linux or Mac OS X. interesting...
Summary: help window fails to appear in trunk → help window fails to appear in trunk (Windows)
Moving to new Firefox Help owner.
Assignee: rlk → jwalden+fxhelp
Status: REOPENED → NEW
As seen on Windows XP FF trunk build 2004-09-23-09-trunk, this is still happening. no Help window.....instead: "XML Parsing Error: xml processing instruction not at start of external entity. Location: chrom://help/content/help.xul. Line Number 1, Column 1" (In reply to comment #2) > Trunk help is obsolete and not currently being developed. Help on the aviary > branch will land on the trunk after Firefox 1.0. The help window should open, even if the content there is not correct/up to date.
(In reply to comment #11) > As seen on Windows XP FF trunk build 2004-09-23-09-trunk, this is still > happening. > no Help window.....instead: > > "XML Parsing Error: xml processing instruction > not at start of external entity. Location: chrom://help/content/help.xul. Line > Number 1, Column 1" I'd mostly forgotten about this. Interestingly enough, I believe Help is fully up-to-date on the trunk (everything -- I decided it would be easier to keep up if all changes were made to both branch and trunk instead of just branch), so I don't know what the problem is. I'll take a look at it over the weekend.
Status: NEW → ASSIGNED
I looked at this a little more. It doesn't seem to be just a problem with invalid XUL. The nightly directory on ftp.mozilla.org doesn't go back nearly far enough to test nightlies from the relevant time frame. Given that I can't build Firefox on Windows because I don't have a good compiler for it, I can't find out when this went wrong and look at bonsai for a list of possible guilty checkins. For now, trunk is stuck. I can't find out when the regression occurred, so I can't find out what caused it. The people who can are all busy with the branch because 1.0 is on the way, so there's no way they'll get to it until after 1.0 is out. I can't fix this. In the absence of someone who can, it won't be fixed anytime soon. Reassigning, changing severity (no dataloss, crash, or mlk, but definite major loss of function), and pushing to After 1.0...
Assignee: jwalden+fxhelp → bugs
Severity: critical → major
Status: ASSIGNED → NEW
OS: All → Windows XP
Target Milestone: --- → After Firefox 1.0
Jeff, old nightlies are available on archive.mozilla.org. I did a bunch of testing with them and came up with this timeline for you: 2004061609 - Help Contents works. 20040617 - no Windows build 2004061809 - Help Contents is missing from the Help menu. F1 does not trigger it. Coincidentally or not, this is the first build where the profile directory was moved from Application Data/Firefox to Application Data/Mozilla/Firefox 2004070709 - Help Contents is back on the Help menu, but is broken as this bug describes. All these builds refer to installer builds. As far as I saw in testing, Help has never broken on zipped builds.
(In reply to comment #14) > Jeff, old nightlies are available on archive.mozilla.org. Hmm, didn't know that. If they haven't, they should mention that in the README in ftp.m.o. Maybe I'll check that out sometime and file a bug if necessary. > 2004061609 - Help Contents works. > 20040617 - no Windows build > 2004061809 - Help Contents is missing from the Help menu. F1 does not trigger > it. Coincidentally or not, this is the first build where the profile > directory was moved from Application Data/Firefox to Application > Data/Mozilla/Firefox > 2004070709 - Help Contents is back on the Help menu, but is broken as this bug > describes. I think this was as a result of bug 244479. Help's still in those builds, but somehow chrome.rdf or somesuch was corrupted when packaged. You can test these builds by typing "chrome://help/content/help.xul" in the location bar and seeing what happens, I believe. (It'd really help if you could do so.) Thanks a bundle for the help, by the way -- time is a precious commodity for me these days (or at least until I get my schedule under control).
*** This bug has been marked as a duplicate of 245810 ***
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → DUPLICATE
V. dup. The fix in bug 245810 is good in the 20040927 build.
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
Target Milestone: Future → ---
Version: Trunk → unspecified
Product: Toolkit → Seamonkey
You need to log in before you can comment on or make changes to this bug.