Closed Bug 63817 Opened 24 years ago Closed 17 years ago

www.hixie.ch fires html assertion

Categories

(Core :: XBL, defect)

x86
Windows 98
defect
Not set
trivial

Tracking

()

VERIFIED WORKSFORME
Future

People

(Reporter: bernd_mozilla, Assigned: hyatt)

References

()

Details

(Keywords: assertion)

NS_ASSERTION((kNameSpaceID_HTML == aNameSpaceID) || (kNameSpaceID_None == aNameSpaceID) || (kNameSpaceID_Unknown == aNameSpaceID), "html content only holds HTML attributes"); KERNEL32! bff768a0() nsDebug::Assertion(const char * 0x023c2de0, const char * 0x023c2d68, const char * 0x023c2d18, int 1233) line 254 + 13 bytes nsGenericHTMLElement::SetAttribute(nsGenericHTMLElement * const 0x033f52b0, int 1, nsIAtom * 0x01855e30, const basic_nsAReadableString<unsigned short> & {...}, int 0) line 1233 + 44 bytes nsXBLBinding::GenerateAnonymousContent(nsXBLBinding * const 0x03442be0, nsIContent * 0x033f52b0) line 524 nsXBLService::LoadBindings(nsXBLService * const 0x026db910, nsIContent * 0x033f52b0, const basic_nsAReadableString<unsigned short> & {...}, int 0, nsIXBLBinding * * 0x007bea04, int * 0x007be9ec) line 713 nsCSSFrameConstructor::ConstructFrameInternal(nsIPresShell * 0x033e8d60, nsIPresContext * 0x033d6ef0, nsFrameConstructorState & {...}, nsIContent * 0x033f52b0, nsIFrame * 0x02b06e68, nsIAtom * 0x01847f90, int 3, nsIStyleContext * 0x034388c0, nsFrameItems & {...}, int 0) line 7543 + 73 bytes nsCSSFrameConstructor::ConstructFrame(nsIPresShell * 0x033e8d60, nsIPresContext * 0x033d6ef0, nsFrameConstructorState & {...}, nsIContent * 0x033f52b0, nsIFrame * 0x02b06e68, nsFrameItems & {...}) line 7500 + 56 bytes nsCSSFrameConstructor::ContentInserted(nsCSSFrameConstructor * const 0x033e85f0, nsIPresContext * 0x033d6ef0, nsIContent * 0x03444580, nsIContent * 0x033f52b0, int 2, nsILayoutHistoryState * 0x00000000) line 8983 + 46 bytes StyleSetImpl::ContentInserted(StyleSetImpl * const 0x033e86b0, nsIPresContext * 0x033d6ef0, nsIContent * 0x03444580, nsIContent * 0x033f52b0, int 2) line 1178 PresShell::ContentInserted(PresShell * const 0x033e8d68, nsIDocument * 0x03443850, nsIContent * 0x03444580, nsIContent * 0x033f52b0, int 2) line 4297 + 50 bytes nsXBLBindingRequest::DocumentLoaded(nsIDocument * 0x0342d950) line 175 nsXBLStreamListener::Load(nsIDOMEvent * 0x0343b9a4) line 398 nsEventListenerManager::HandleEvent(nsIPresContext * 0x00000000, nsEvent * 0x007bf3dc, nsIDOMEvent * * 0x007bf3ac, nsIDOMEventTarget * 0x0342d97c, unsigned int 7, nsEventStatus * 0x007bf420) line 1379 + 23 bytes nsDocument::HandleDOMEvent(nsDocument * const 0x0342d950, nsIPresContext * 0x00000000, nsEvent * 0x007bf3dc, nsIDOMEvent * * 0x007bf3ac, unsigned int 1, nsEventStatus * 0x007bf420) line 3106 nsXMLDocument::EndLoad(nsXMLDocument * const 0x0342d950) line 678 nsXMLContentSink::DidBuildModel(nsXMLContentSink * const 0x03419950, int 1) line 291 CWellFormedDTD::DidBuildModel(CWellFormedDTD * const 0x033f9dd0, unsigned int 0, int 1, nsIParser * 0x0341be00, nsIContentSink * 0x03419950) line 293 + 20 bytes nsParser::DidBuildModel(unsigned int 0) line 1418 + 60 bytes nsParser::ResumeParse(int 1, int 0) line 1937 nsParser::EnableParser(int 1) line 1524 + 15 bytes CSSLoaderImpl::Cleanup(URLKey & {...}, SheetLoadData * 0x0343e480) line 718 CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x00000000, SheetLoadData * 0x0343e480) line 841 CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x03431b50, SheetLoadData * 0x0343e480, int & 1, nsICSSStyleSheet * & 0x034336d0) line 876 CSSLoaderImpl::DidLoadStyle(nsIStreamLoader * 0x0343e620, nsString * 0x034309c0, SheetLoadData * 0x0343e480, unsigned int 0) line 911 + 24 bytes SheetLoadData::OnStreamComplete(SheetLoadData * const 0x0343e480, nsIStreamLoader * 0x0343e620, nsISupports * 0x00000000, unsigned int 0, unsigned int 310, const char * 0x033f8780) line 652 nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x0343e624, nsIChannel * 0x0343df10, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100ad018 gCommonEmptyBuffer) line 121 + 78 bytes nsHTTPFinalListener::OnStopRequest(nsHTTPFinalListener * const 0x0343dd10, nsIChannel * 0x0343df10, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100ad018 gCommonEmptyBuffer) line 1167 + 42 bytes InterceptStreamListener::OnStopRequest(InterceptStreamListener * const 0x033f4230, nsIChannel * 0x0343df10, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100ad018 gCommonEmptyBuffer) line 1212 nsHTTPChunkConv::OnStopRequest(nsHTTPChunkConv * const 0x02b90c78, nsIChannel * 0x0343df10, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x100ad018 gCommonEmptyBuffer) line 109 nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x02b90c78, unsigned int 0, const unsigned short * 0x100ad018 gCommonEmptyBuffer) line 1923 + 42 bytes nsHTTPServerListener::OnStopRequest(nsHTTPServerListener * const 0x03442230, nsIChannel * 0x0343fcc4, nsISupports * 0x0343df10, unsigned int 0, const unsigned short * 0x100ad018 gCommonEmptyBuffer) line 730 nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x033fd360) line 300 + 46 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x033fd370) line 92 + 12 bytes PL_HandleEvent(PLEvent * 0x033fd370) line 576 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00b9eba0) line 509 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00000314, unsigned int 55435, unsigned int 0, long 12184480) line 1054 + 9 bytes KERNEL32! bff7363b() KERNEL32! bff94407() 007b8a22() Win98 CVS 20001225
Yay, someone finally filed this bug. ;-) Hyatt: This is your baby. It's the old one about namespace attributes and HTML elements and XBL and assertions and stuff. Tell me if you need a testcase. IIRC the assertion is actually harmless.
Assignee: ian → hyatt
Severity: normal → trivial
Status: UNCONFIRMED → NEW
Component: HTML Element → XBL
Ever confirmed: true
QA Contact: lorca → jrgm
The last few nightlies are crashing whenever http://hixie.ch/ is loaded - probably should be a different bug - just thought I'll mention it here. Tested on WINNT SP6 with builds 2000122020, 2000122120, 2000122620 and 2000122720. Might be related to bug 63874 .
works find, but asserts, yeah -> Future
Target Milestone: --- → Future
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 No problems with this site
is the spam.hixie.ch related with this bug? if yes, it should have the crash flag, as it crash all the time using firefox 1.0rc2 shall this crash be fixed for firefox 1.0 or its too late already?
spam.hyxie crashes for me too. at home on XP at work on 2K (both Mozilla 1.8a4)
We've got a crash bug on our hands that has caused a long discussion in IRC. Previously I didn't file a bug on this (and it seems to be related to this) because it supposedly worked in Firefox Trunk, but now it doesn't. Testcase: http://spam.hixie.ch/asdf (CRASHER) Here's some clips. [22:37:52] <Tristor> file a bug, I will attach all the talkback IDs [22:38:03] <Tristor> from Trunk, 1.7.5, Aviary, and Milestone [22:39:09] <%Vardyr> Tom: it's not the CSS afaik [22:39:17] <%Vardyr> Tom: it's with any 404 error that site gives out [22:39:24] <Chewie[]> Tom: i have no idea. it *MAY* be the 404 page requesting a 301, but i'm not sure. [22:42:11] <%aebrahim> its possible we may be making assertions fatal. i know that's planned, but not sure for when [22:45:59] <Tristor> and firefox refuses to redraw when opening a new tab [22:47:00] <%Vardyr> I don't know, but anything that creates a 404 on that site crashes firefox
Flags: blocking-aviary1.1?
I'm not sure the crashes related to http://spam.hixie.ch have anything to do with this bug. We discussed at length in #bs, and we aren't sure what it is, but it is definitely causing crashes on Aviary, Trunk, Milestone, and even Seamonkey 1.7.5. I am hoping that I can catch Hixie tomorrow and ask him about the crashes and see if I can't figure out what causes them. If I can do that, I will probably file another bug on it. I don't believe it is related.
Hixie, do you know what could be causing this? It should be noted that both the 404 document and the main http://spam.hixie.ch/ page exibit this behavior equally well. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319 Firefox/1.0.1 StumbleUpon/1.9993 (Debian package 1.0.1-2)
No one on the web except Hixie actually uses XBL :-) so the chances of many users ever hitting this crash are pretty slim. Not gonna block unless someone can show that the crash is widespread.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
The assertion has nothing to do with the crash. the crash was theoretically fixed recently, make sure you're using the most recent nightlies and please discuss that in another bug. The assertion is some very minor XBL thing.
A notice then: Please take all discussion from comment 8 to 13 to bug 289765 . We apologize for the confusion (i blame aebrahim i think... or was it aconbere? for mentioning assertions randomly during our chat).
have a look at the style sheet, at the end of the file is a comment without the comment delimiters, seen as parse error by the validator: http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fwww.hixie.ch%2Fresources%2Fstyle%2Forange%2F&warning=1&profile=css2&usermedium=all Errors URI : http://www.hixie.ch/resources/style/orange/ * Line: 17 Context : a[rel~=bookmark] Invalid number : display inline-block is not a display value : inline-block * Line: 23 Context : white background think subtle border under header Parse Error - [empty string]
I'm not seeing any assertion with my recent debug build.
(Note that it doesn't matter if the stylesheet is valid or not; the point of assertions is checking that conditions that should never be able to happen (whatever the input) don't happen.)
(In reply to comment #16) > (Note that it doesn't matter if the stylesheet is valid or not; the point of > assertions is checking that conditions that should never be able to happen > (whatever the input) don't happen.) I assume that an invalid stylesheet shouldn´t crash a browser, and an assertion is a message to the programmer to do some more for processing something never expected. But when a bug exists, and there is a crasher bug, looking for bugs I'm reasoning the other way round, if there are assertions, there may be bad code following instead of graceful degradation or safe fallback. BTW, I like your cat ;-)
WFM on Mac. I tried loading a bunch of the URLs in this bug and didn't see any assertions.
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: assertion
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.