Closed
Bug 63817
Opened 24 years ago
Closed 17 years ago
www.hixie.ch fires html assertion
Categories
(Core :: XBL, defect)
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
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
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 .
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616
No problems with this site
Comment 5•20 years ago
|
||
Comment 6•20 years ago
|
||
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)
Comment 8•20 years ago
|
||
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.
Comment 10•20 years ago
|
||
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)
Comment 11•20 years ago
|
||
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-
Comment 12•20 years ago
|
||
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.
Comment 13•20 years ago
|
||
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).
Comment 14•20 years ago
|
||
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]
Comment 15•20 years ago
|
||
I'm not seeing any assertion with my recent debug build.
Comment 16•20 years ago
|
||
(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.)
Comment 17•20 years ago
|
||
(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 ;-)
Comment 18•17 years ago
|
||
WFM on Mac. I tried loading a bunch of the URLs in this bug and didn't see any assertions.
Updated•16 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•