Closed
Bug 197520
Opened 21 years ago
Closed 21 years ago
XHTML entity parsing is broken
Categories
(SeaMonkey :: General, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.4alpha
People
(Reporter: fredbezies, Assigned: dougt)
References
()
Details
(Keywords: platform-parity, regression, smoketest)
Attachments
(1 file, 2 obsolete files)
2.11 KB,
patch
|
harishd
:
review+
hjtoi-bugzilla
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030315 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030315 Simple. About:mozilla is not working anymore. I got instead : "XML Parsing Error: undefined entity Location: jar:resource:///chrome/en-US.jar!/locale/en-US/global/about.xhtml Line Number 95, Column 15:<li>Copyright © 1998-2003 by <a href="about:credits">Contributors</a> to --------------^" See details for more info. This is not a duplicate of bug 197477 because I am using a trunk build, not a 1.3 branch build. And of course, I made a clean install of my newly homemade build. Reproducible: Always Steps to Reproduce: 1.Grab sources 2.apply patches with CVS 3.build mozilla and choose help/about after you installed your new lizard Actual Results: Error message ! Expected Results: Displaying infos :-) My about:buildconfig Build platform target i686-pc-cygwin Build tools Compiler Version Compiler flags cl 12.00.8804 for 80x86 -TC -nologo -W3 -nologo -Gy -Fd$(PDBFILE) cl 12.00.8804 for 80x86 -TP -nologo -W3 -nologo -Gy -Fd$(PDBFILE) Configure arguments --enable-extensions --enable-crypto --disable-debug --enable-optimize --enable-calendar --disable-pedantic --disable-installer --enable-strip --disable-tests If this bug related to bug 194240 big patch ?
Reporter | ||
Comment 1•21 years ago
|
||
Modifying URL. All others about: seems to work.
URL: about:mozilla → about:
Comment 2•21 years ago
|
||
This is using the English UI? Or the French localization?
Reporter | ||
Comment 3•21 years ago
|
||
As I am using homemade builds, I am using english UI only. No other xpi. I deleted chrome and cache from my profile. Build was installed using a clean install : deleting everything (keeping plugins directory).
Comment 4•21 years ago
|
||
Is this a problem with a non-homemade build? One from the mozilla.org ftp site?
Reporter | ||
Comment 5•21 years ago
|
||
I am not using official build. I think I have an "half checking" problem. I will grab all patches I don't grab, build it again and see if the problem is still alive.
Comment 6•21 years ago
|
||
Parsing entities seems to be broken for most (all?) xhtml files with the latest m.o trunk build. Add user_pref("browser.xul.error_pages.enabled", true); to your user.js or prefs.js and then load http://www.blahblahblah.com/.
Severity: normal → major
Summary: about:mozilla display is broken → XHTML entity parsing is broken
Reporter | ||
Comment 7•21 years ago
|
||
Thanks ! I was not mad so ! Is bug 194240 the big breaker, here ?
Assignee | ||
Comment 9•21 years ago
|
||
Using this morning's windows and linux builds, i find no problem loading about:mozilla. wfm.
Comment 10•21 years ago
|
||
dougt, use about: or the steps I listed in comment 6. about:mozilla doesn't use any entities (even though that's what Frederic listed in comment 0).
Assignee | ||
Comment 11•21 years ago
|
||
Okay - i can see the problem using that prefs.js setting. I landed the branch yesterday afternoon. I don't think that my landing could have caused this. cc'ing alec. he may have landed some jar changes which could have caused this?
Reporter | ||
Comment 12•21 years ago
|
||
For my comment 0 :-) I mean about:, not about:mozilla ;-] I should have said help/about mozilla :-)
Reporter | ||
Comment 13•21 years ago
|
||
Sorry for spamming, but bug is shown using build 2003031521.
Comment 14•21 years ago
|
||
*** Bug 197669 has been marked as a duplicate of this bug. ***
Comment 15•21 years ago
|
||
*** Bug 197665 has been marked as a duplicate of this bug. ***
Comment 16•21 years ago
|
||
*** Bug 197701 has been marked as a duplicate of this bug. ***
Comment 17•21 years ago
|
||
*** Bug 197712 has been marked as a duplicate of this bug. ***
Comment 18•21 years ago
|
||
*** Bug 197738 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
Do we have a regression date range here? Something like 1 day or less?
Comment 20•21 years ago
|
||
*** Bug 197757 has been marked as a duplicate of this bug. ***
Comment 21•21 years ago
|
||
I tried mozilla-win32-svg-GDI-mathml (Build ID: 2003031610) and encountered the same problem. 1.3 on Windows XP / MacOS X and Windows nightly build (ID: 2003031408) worked without problem. This error occurs when an XHTML document is served as application/xhtml+xml, application/xml or text/xml. When it's served as text/html, this error doesn't occur. Try the following tests: http://www.w3.org/People/mimasa/test/xhtml/entities/
Comment 22•21 years ago
|
||
Yes, yes. text/html is NOT XHTML. We know it's already broken by the 16th... I'm working on narrowing the date range, now that I have local builds again...
Comment 23•21 years ago
|
||
And if you're not on the list at http://www.mozilla.org/roadmap.html#project-management please do not set any "blocking a release" flags. Thank you.
Flags: blocking1.4a+
Comment 24•21 years ago
|
||
OK, I just tested this in the following builds: Linux .tar.gz: 2003-03-15-05, 2003-03-15-21, 2003-03-16-05 Linux installer: 2003-03-16-05 None of these shows the problem. Since all the duplicates are on Windows, I'm assuming it's a Win32-specific problem. So could someone who has Windows please determine the regression date range? Frederic, when did you pull the build that shows the problem? What was the time before that when you pulled?
Keywords: pp
Comment 25•21 years ago
|
||
w32 2003031504 not talkback, broken w32 2003031408 talkback, worked
Comment 26•21 years ago
|
||
The last build which WFM was 2003-03-14-08. The first build which shows the error is the 2003-03-15-04 using Windows nt4.0
Comment 27•21 years ago
|
||
Alright.... that's what timeless says too; he tested zip builds, so it's not an installer problem. to dougt, as the most likely culprit in that date range..... Specifically, we may have a place where we switched from nsFileSpec to nsIFile and the two parse some string differently on windows, with nsIFile not coming out with a useful filename and hence not loading a DTD. That's my current hypothesis on what's going on. I looked at the nsScanner changes and those look fine (not to mention that that particular constructor does not seem to be called). Heikki, where would one look to see the DTD-loading code?
Assignee: asa → dougt
Reporter | ||
Comment 28•21 years ago
|
||
In answer to comment #24 : Bug appears soon after minimo landing. I am living in Europe, so Mozilla.org time + 9 hours. Well, last working homemade build : 14 march, just before minimo landing. Should this be considered as a 1.4a potentially blocker ? (don't know if I can set "?" for 1.4a blocker).
Comment 29•21 years ago
|
||
*** Bug 197805 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 30•21 years ago
|
||
Hi. I landed on the 15th at around 4pm. If the regression was in the 15th's nightly build, then the regression wasn't caused by my landing, correct?
Assignee | ||
Comment 31•21 years ago
|
||
okay, Frederic confirms that it is my bustage. I will take a look.
Priority: -- → P1
Target Milestone: --- → mozilla1.4alpha
Comment 32•21 years ago
|
||
fwiw bug 175394 is about mac classic having this sort of problem
Severity: major → blocker
Comment 33•21 years ago
|
||
Doug, just for the record you landed on the _14th_ around 5pm. According to bonsai, at least.
Comment 35•21 years ago
|
||
confirming that I see this on win32, debug. I'll start debugging.
XHTML entity loading happens here: http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsExpatDriver.cpp#188 Those of you that have a recent enough build to see this, could you please take a look at what is going on?
Comment 37•21 years ago
|
||
heikki, I'll look at what's going on in nsExpatDriver.cpp here's a stack to the code that generates the error, might be useful. CreateErrorText(const unsigned short * 0x0012f904, const unsigned short * 0x03a08ce8, const int 95, const int 15, nsString & {...}) line 719 nsExpatDriver::HandleError(const char * 0x03a04bd0, unsigned int 7314, int 0) line 787 + 67 bytes nsExpatDriver::ParseBuffer(const char * 0x03a04bd0, unsigned int 7314, int 0) line 817 nsExpatDriver::ConsumeToken(nsExpatDriver * const 0x039fa65c, nsScanner & {...}, int & 0) line 918 + 32 bytes nsParser::Tokenize(int 0) line 2543 + 26 bytes nsParser::ResumeParse(int 1, int 0, int 1) line 1770 + 31 bytes nsParser::OnDataAvailable(nsParser * const 0x0368166c, nsIRequest * 0x039dd258, nsISupports * 0x00000000, nsIInputStream * 0x039dd894, unsigned int 0, unsigned int 3657) line 2405 + 21 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x039dce68, nsIRequest * 0x039dd258, nsISupports * 0x00000000, nsIInputStream * 0x039dd894, unsigned int 0, unsigned int 3657) line 243 + 46 bytes nsJARChannel::OnDataAvailable(nsJARChannel * const 0x039dd260, nsIRequest * 0x039dd788, nsISupports * 0x00000000, nsIInputStream * 0x039dd894, unsigned int 0, unsigned int 3657) line 677 + 57 bytes nsInputStreamPump::OnStateTransfer() line 406 + 65 bytes nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x039dd78c, nsIAsyncInputStream * 0x039dd894) line 321 + 11 bytes nsInputStreamReadyEvent::EventHandler(PLEvent * 0x0368f114) line 112 PL_HandleEvent(PLEvent * 0x0368f114) line 663 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00f47f08) line 593 + 9 bytes _md_TimerProc(HWND__ * 0x0009028a, unsigned int 275, unsigned int 0, unsigned long 2500515) line 963 + 9 bytes USER32! 77e3a290() USER32! 77e143da() USER32! 77e1a752() nsAppShellService::Run(nsAppShellService * const 0x00fca1c8) line 480 main1(int 1, char * * 0x00271ce0, nsISupports * 0x00f0ce90) line 1268 + 32 bytes main(int 1, char * * 0x00271ce0) line 1639 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e9ca90()
Comment 38•21 years ago
|
||
© is a special internal entity for the copyright symbol, right? I'm new to this code, but it isn't going to find it in an external dtd.
Assignee | ||
Comment 39•21 years ago
|
||
*** Bug 175394 has been marked as a duplicate of this bug. ***
Comment 40•21 years ago
|
||
© should be coming from xhtml11.dtd
Looking at the nsExpatDriver.cpp changes, lfile->AppendRelativeNativePath(PromiseFlatCString(nsDependentCString(kDTDDirectory) + fileName)); is appending a path with a forward-slash in it. Is that supposed to work on Windows?
Assignee | ||
Comment 42•21 years ago
|
||
found the bug. nsIFile::AppendRelative does not as documented. patch coming up.
Comment 43•21 years ago
|
||
Assignee | ||
Comment 44•21 years ago
|
||
Attachment #117494 -
Flags: superreview+
Comment 45•21 years ago
|
||
*** Bug 197870 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 46•21 years ago
|
||
Attachment #117494 -
Attachment is obsolete: true
Attachment #117497 -
Attachment is obsolete: true
Assignee | ||
Comment 47•21 years ago
|
||
Checking in nsExpatDriver.cpp; /cvsroot/mozilla/htmlparser/src/nsExpatDriver.cpp,v <-- nsExpatDriver.cpp new revision: 3.36; previous revision: 3.35 done This is fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Attachment #117501 -
Flags: superreview+
Comment 48•21 years ago
|
||
Comment on attachment 117501 [details] [diff] [review] final version >? gkparser.dll >? gkparser.exp >? gkparser.ilk >? gkparser.lib >? gkparser.pdb >? module.rc >? module.res >? x >? xx >Index: nsExpatDriver.cpp >=================================================================== >RCS file: /cvsroot/mozilla/htmlparser/src/nsExpatDriver.cpp,v >retrieving revision 3.35 >diff -u -1 -0 -r3.35 nsExpatDriver.cpp >--- nsExpatDriver.cpp 15 Mar 2003 01:02:47 -0000 3.35 >+++ nsExpatDriver.cpp 17 Mar 2003 20:09:42 -0000 >@@ -46,21 +46,20 @@ > #include "nsIURL.h" > #include "nsIUnicharInputStream.h" > #include "nsNetUtil.h" > #include "prprf.h" > #include "prmem.h" > #include "nsTextFormatter.h" > #include "nsDirectoryServiceDefs.h" > #include "nsCRT.h" > > static const char* kWhitespace = " \r\n\t"; // Optimized for typical cases >-static const char kDTDDirectory[] = "res/dtd/"; > > /***************************** EXPAT CALL BACKS *******************************/ > > // The callback handlers that get called from the expat parser > PR_STATIC_CALLBACK(int) > Driver_HandleStartElement(void *aUserData, > const XML_Char *aName, > const XML_Char **aAtts) > { > NS_ASSERTION(aUserData, "expat driver should exist"); >@@ -271,23 +270,26 @@ > > nsCOMPtr<nsIFile> dtdPath; > NS_GetSpecialDirectory(NS_OS_CURRENT_PROCESS_DIR, > getter_AddRefs(dtdPath)); > > if (!dtdPath) > return PR_FALSE; > > nsCOMPtr<nsILocalFile> lfile = do_QueryInterface(dtdPath); > >- nsCAutoString path; >- path = NS_LITERAL_CSTRING(kDTDDirectory) + fileName; >- lfile->AppendRelativeNativePath(path); >+ // append res/dtd/<fileName> >+ // can't do AppendRelativeNativePath("res/dtd/" + ) >+ // as that won't work on all platforms. >+ lfile->AppendNative(NS_LITERAL_CSTRING("res")); >+ lfile->AppendNative(NS_LITERAL_CSTRING("dtd")); >+ lfile->AppendNative(fileName); > > PRBool exists; > dtdPath->Exists(&exists); > > if (exists) { > // The DTD was found in the local DTD directory. > // Set aDTD to a file: url pointing to the local DT > nsCOMPtr<nsIURI> dtdURI; > NS_NewFileURI(getter_AddRefs(dtdURI), dtdPath); >
Attachment #117501 -
Flags: review+
Comment 49•21 years ago
|
||
Please ignore comment #48. That was an accident :-(
Reporter | ||
Comment 50•21 years ago
|
||
I can see about: back now. Thanks for fixing this bug.
Comment 52•21 years ago
|
||
*** Bug 197477 has been marked as a duplicate of this bug. ***
Comment 53•21 years ago
|
||
*** Bug 198074 has been marked as a duplicate of this bug. ***
Comment 54•21 years ago
|
||
*** Bug 182204 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking1.4a?
Comment 55•21 years ago
|
||
This appears to have regressed. In 2003091704 (Windows ME) the Help/About Mozilla page displays: XML Parsing Error: undefined entity Location: jar:resource:///chrome/en-US.jar!/locale/en-US/global/about.xhtml Line Number 95, Column 15: <li>Copyright © 1998-2003 by <a href="about:credits">Contributors</a> to --------------^ (end of page display)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 56•21 years ago
|
||
Jim: you are seeing bug 219355, not this bug.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Comment 57•21 years ago
|
||
verified Please don't reopen such old VERIFIED fixed bugs
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•