40080 - XUL page does not load (previously crashed)

Status: VERIFIED WORKSFORME

(Core :: XML, defect, P3)

Description

[Mathieu Fenniak]

Ever since finding out how to add things to my sidebar, I've been doing just

that. The given URL is a new XML page I've been creating with the hopes of

making it a search tool similar to the included Mozilla search panel, but for a

specific web site, moo.ca. The page is viewable now in M15, and it's very little

currently to look at, but the 2000/05/21 daily crashes on it consistantly. This

is the only output that's related on the console:



nsXMLContentSink::AddDocTypeDecl

.//run-mozilla.sh: line 29: 21390 Segmentation fault      $prog ${1+"$@"}

Comment 1

[Ronald Tilby]

Build 2000-05-19-08 Win Talkback running on Windows 98 crashes when attempting 
to display the above URL. (Talkback sent 21 May 22:00 pacific time.)
Build 2000-05-11-08 Win talkback running on Windows 98 does NOT crash when 
displaying the above URL.
Suggest STATUS: NEW, PLATFORM: ALL, KEYWORD: CRASH, REGRESSION

Comment 2

[leger]

Adding crash keyword

Comment 3

[Andreas Franke (gone)]

Attachment: stack trace, PC/Linux, built from 5/21 sources

Comment 4

[Andreas Franke (gone)]

This seems to be an endless loop in nsXULElement::GetContainingNameSpace:

#0     nsIStyledContent::GetIID ()               from librdf.so
#1     nsQueryInterface::operator() ()           from libxpcom.so
#2     nsCOMPtr_base::assign_from_helper ()      from libxpcom.so
#3     nsXULElement::GetContainingNameSpace ()   from librdf.so
[...]
#32536 nsXULElement::GetContainingNameSpace ()   from librdf.so
#32537 nsXULElement::GetNameSpacePrefixFromId () from librdf.so
#32538 nsXULElement::SetAttribute ()             from librdf.so
#32539 nsXMLContentSink::AddAttributes ()        from libraptorhtml.so
#32540 nsXMLContentSink::OpenContainer ()        from libraptorhtml.so
#32541 CWellFormedDTD::HandleStartToken ()       from libraptorhtmlpars.so
#32542 CWellFormedDTD::HandleToken ()            from libraptorhtmlpars.so
#32543 CWellFormedDTD::BuildModel ()             from libraptorhtmlpars.so
#32544 nsParser::BuildModel ()                   from libraptorhtmlpars.so

Confirming bug, OS=All, severity=critical, regression kw.
The 5/27 build crashes, too.

Comment 5

[Nisheeth Ranjan]

I tried this today using yesterday's NT debug build.  The crash no longer 
happens, but, the page does not display at all.  Removing crash keyword and 
updating summary.

Comment 6

[Nisheeth Ranjan]

When I go to this url using Mozilla, I get the following message in the content 
area of the browser: "Redirection error: Infinite loop detected".

The Necko guys need to investigate this further.  Re-assigning to Gagan...

Comment 7

[Eric Pollmann]

I also see this error message when going to: http://javascript.com

Then clicking on: Popup Window Maker

Or any of the main article links that point to: http://redir.internet.com/*

Possibly related to bug 42353

Comment 8

[Doron Rosenberg (IBM)]

*** Bug 43234 has been marked as a duplicate of this bug. ***

Comment 9

[Asa Dotzler [:asa]]

*** Bug 43447 has been marked as a duplicate of this bug. ***

Comment 10

[Jason Chambers]

I have the same problem going to http://www.distributed.net and clicking on 
their .plans link. (actual address 
http://n0cgi.distributed.net/cgi/dnet-finger.cgi) My new URL address in my 
address bar is 
file:///C:/ZIPTEMP/MOZILLA/BIN/chrome/packages/core/necko/content/redirect_loop.
xul after clicking in

I'm running build 2000062308 on win98

Comment 11

[Blake Ross]

*** Bug 43636 has been marked as a duplicate of this bug. ***

Comment 12

[Blake Ross]

*** Bug 42353 has been marked as a duplicate of this bug. ***

Comment 13

[Jason Chambers]

I cannot seem to reproduce the bug in todays build (id: 2000062408.) Mark bug as
resolved or leave as new?

Comment 14

[Mathieu Fenniak]

No. Original bug still exists. The redirection error is gone, but the page still
does not load for me with today's build (2000062408).

Comment 15

[Jason Chambers]

Yeah, but thats a totally different bug than the one stated here. I don't know
how bugzilla works (brand new at this) but when we close this bug, wouldn't that
close the duplicates? Because the problem with the page loading up has nothing
to do with what is stated in the summary. So your current problem with loading
the URL could be overlooked when they do a test. Makes sense doesn't it?

Comment 16

[Mathieu Fenniak]

Nisheeth Ranjan renamed this bug on June 16th when another bug (which has now
been fixed) made the page impossible to get to. Now the bug that I originally
reported still exists, the page does not load.

Comment 17

[Blake Ross]

*** Bug 43783 has been marked as a duplicate of this bug. ***

Comment 18

[Blake Ross]

Add crash keyword to open crashers.

Comment 19

[Gagan]

ruslan: these seem to be some edge cases of your check for redirect-loops. 

Comment 20

[ruslan]

No. The redirect is fixed. All pages in this bug except for the sidebar would 
load. Sending back.

Comment 21

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 22

[Jason Chambers]

uhmm, wth.... did I do something to get assigned to this bug? =c( (i must be dense)

Comment 23

[Jason Chambers]

Gagan, can I assign this to you? I must have done something stupid to have it
assigned to me.

Comment 24

[Jason Chambers]

I still don't know how this happened but I'm reassigning but to owner of
selected component. My limits in C++ are defining classes and recursion. Heck, I
never used a pointer before!!!!!! I hope I didn't mess anything up.

Comment 25

[Nisheeth Ranjan]

Re-assigning to Gagan because the original "page does not load" problem is back.  

Comment 26

[Tom Mraz]

It seems to me it's WORKSFORME now. (Linux nightly 20000926 from trunk)

Comment 27

[Luis Villa]

This is definitely not working yet. In fact, I've seen it twice today (first
times in a long time.) To duplicate it: go to
http://www.dulug.duke.edu/~mark/getting-started-links.html
click on the third link on the page:
http://www.debian.org/~bortz/SGML-HOWTO/potato/howto.html
You should get this in your URL bar:
file:///home/louie/package/chrome/packages/core/redirect_loop.xul
So, please don't mark WFM.

Comment 28

[Tom Mraz]

Hmmm I don't understand how it's connected to original error. This is completely
different bug. Mozilla doesn't issue a message that the file doesn't exist. And
there is another bug that the file redirect_loop.xul is in a different directory
(chrome/comm/content/necko/redirect_loop.xul). If you put that path into the URL
bar mozilla loads the file fine.

Comment 29

[Luis Villa]

I think that this bug may have disappeared- I can't duplicate it on any of the
test cases linked to from here, nor can I dup it from similar testcases in a
couple of related bugs. I think we should mark as WFM- any objections?

Comment 30

[Darin Fisher]

Marking WORKSFORME.

Comment 31

[Tom Mraz]

VERIFIED WFM linux 2001062021