[FIXr]trunk crash when going to specified URI [@ nsDocument::SetHeaderData]

VERIFIED FIXED in mozilla1.8beta2

Status

()

Core
Layout
P1
critical
VERIFIED FIXED
13 years ago
7 years ago

People

(Reporter: Tristor, Assigned: bz)

Tracking

({crash, hang, regression})

Trunk
mozilla1.8beta2
crash, hang, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(5 attachments)

(Reporter)

Description

13 years ago
Build IDs:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050409
Firefox/1.0+
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050409
Firefox/1.0.3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317
Firefox/1.0.2 StumbleUpon/1.9993
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319


As I said in my comments on Bug 63817, I am going to file a new one on the crash
when going to the URL http://spam.hixie.ch.  I am not sure what causes the
crash.  During our long discussion about this issue in #bs, we came up with
several ideas, which were relayed in comments on Bug 63817.  One of the
possibilities seems to be that there is a 404 for something on the page and the
404 is requesting a 301 causing the crash.  Nobody really has any idea.  At any
rate, I have successfully crashed this once on Trunk, where it previously didn't
crash, although I am not sure if the crash is going to be consistent on Trunk,
since now it seems to want to simply hang.  Previously, I was able to actually
see the page on Trunk as it was supposed to be, without issue.  On 1.7.5 and
1.7.6 Seamonkey, this crashes everytime.  Same deal on 1.0.2 Milestone and
1.0.3/Aviary Nightly.  In channel Aebrahim, Tom, and Chewie (Alexander) all
reproduced this, so I am going to go ahead and mark it as NEW from the get-go. 
Chewie proposed there may be something in the server configuration that is
causing the crash.  At any rate, I would love for Hixie to give this some attention.

Steps to Reproduce:

1. Make sure you don't have anything open you can't get back to.
2. Goto http://spam.hixie.ch
3. Crash and burn, baby

Actual Results:

Firefox/Seamonkey both crash.

Expected Results:

Render the page appropriately.


Note:

I wasn't sure where to file this, but put it where told:

<jesus_X> umm, try http
<jesus_X> it seems to be a header issue I think
<Tristor> hmmz, okay
<jesus_X> it core networking

I am attaching the stacktraces and other information from the Talkback IDs I got
from crashing it, which are:
TB4973854Q (Trunk), TB4973989Z (Aviary), TB4974002E (Aviary), TB4974032X
(Aviary), TB4975251H (Milestone), TB4975132M (1.7.6 Seamonkey)

Any more information I can offer, I will be more than willing to share, but I
can't think of much of anything else to add.

Adding the crash, hang, and clean-report keywords, and helpwanted and qawanted
for help testcasing/implementing this
(Reporter)

Updated

13 years ago
Whiteboard: testcase-needed
(Reporter)

Comment 1

13 years ago
Created attachment 180247 [details]
TB4973854Q (Trunk)
(Reporter)

Comment 2

13 years ago
Created attachment 180248 [details]
TB4973989Z (Aviary)
(Reporter)

Comment 3

13 years ago
Created attachment 180249 [details]
TB4975251H (Milestone)

Comment 4

13 years ago
Hang in Aviary:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050403
Firefox/1.0.3

It hangs because I disabled error reporting.

Symptoms: Switching tabs is delayed.  The browser area immediately repaints, but
the tab takes 2 secs or so to become 'active'.  The address bar is frozen (stays
spam.hixie.ch).  Exiting firefox doesn't kill the executable (have to kill it in
taskman).
(Reporter)

Comment 5

13 years ago
Created attachment 180250 [details]
TB4975132M (Seamonkey)

Apparently, the Talkback ID for Trunk is related to a crash from something
else, because it's stack isn't similar to the ones from all other crashes. 
This is the last one folks, sorry about all the bugspam.  Can anybody on
something other than Windows confirm this?
(Reporter)

Comment 6

13 years ago
(In reply to comment #4)
>  
> Symptoms: Switching tabs is delayed.  The browser area immediately repaints, but
> the tab takes 2 secs or so to become 'active'.  The address bar is frozen (stays
> spam.hixie.ch).  Exiting firefox doesn't kill the executable (have to kill it in
> taskman).

This is the behavior during hangs in Trunk as well.  Error reporting /is/
enabled in my copy of Trunk, however.

Comment 7

13 years ago
(In reply to comment #6)
> (In reply to comment #4)
> This is the behavior during hangs in Trunk as well.  Error reporting /is/
> enabled in my copy of Trunk, however.

Excuse me.  I mean Windows XP error reporting, that thing that makes the window
state (Not responding) and the 'you crashed' thing popup, as well as talkback.

Meaning: Firefox hangs and doesn't exit properly, but I don't get talkback
because the "Send Error Report to Microsoft" window doesn't pop up.
(Reporter)

Comment 8

13 years ago
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #4)
> > This is the behavior during hangs in Trunk as well.  Error reporting /is/
> > enabled in my copy of Trunk, however.
> 
> Excuse me.  I mean Windows XP error reporting, that thing that makes the window
> state (Not responding) and the 'you crashed' thing popup, as well as talkback.
> 
> Meaning: Firefox hangs and doesn't exit properly, but I don't get talkback
> because the "Send Error Report to Microsoft" window doesn't pop up.


Run dumprep before reproducing?

Comment 9

13 years ago
(In reply to comment #8)
> Run dumprep before reproducing?

Turned on error reporting, got dumprep and talkback to come up.  Did talkback,
got ID:
TB4975510G

Comment 10

13 years ago
I am also suffering the same bug issues on both Mac and Linux. The following
specs  are the details

Incident Number: TB4976032Q
OS:Mac OSX 10.3.8
Build: Firefox 1.0.2 Mozilla/5.0 (Macintosh: U; PPC Mac OSX Mach-O; en-US; rv
1.7.6) Gecko/20050317 Firefox/1.0.2
RAM:384 MB
Processor: 500 MHz PowerPC G3

Incident Number:  TB4976161H
OS: Ubuntu Linux 5.04 "Hoary"
Kernel: 2.6.10
Window Manager: GNOME
RAM: 1GB
Build:Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050405 Firefox/1.0+

Incident Number:  TB4975951X
OS: Ubuntu Linux 5.04 "Hoary"
Kernel: 2.6.10
Window Manager: GNOME
RAM: 1GB
Build:Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050405 Firefox/1.0+

Incident Number:  TB4975895W
OS: Ubuntu Linux 5.04 "Hoary"
Kernel: 2.6.10
Window Manager: GNOME
RAM: 1GB
Build:Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050405 Firefox/1.0+

Incident Number:  TB4975820M
OS: Ubuntu Linux 5.04 "Hoary"
Kernel: 2.6.10
Window Manager: GNOME
RAM: 1GB
Build:Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050405 Firefox/1.0+
(Reporter)

Comment 11

13 years ago
Making this OS/Hardware all
OS: Windows XP → All
Hardware: PC → All

Comment 12

13 years ago
I am receiving the following output when running gdb in conjunction with
crashing epiphany (another gecko based browser) using the same method as listed
with this bug

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7c4847b in __write_nocancel () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7318fff in XUnlockDisplay () from /usr/X11R6/lib/libX11.so.6
#3  0xb7319cf5 in _X11TransWrite () from /usr/X11R6/lib/libX11.so.6
#4  0xb72fa4b5 in _XFlush () from /usr/X11R6/lib/libX11.so.6
#5  0xb72fb9d4 in _XReply () from /usr/X11R6/lib/libX11.so.6
#6  0xb72f8880 in XTranslateCoordinates () from /usr/X11R6/lib/libX11.so.6
#7  0xb78bc529 in gdk_window_get_origin () from /usr/lib/libgdk-x11-2.0.so.0
#8  0xb7a9f703 in gtk_tooltips_set_tip () from /usr/lib/libgtk-x11-2.0.so.0
#9  0xb7a9f8da in gtk_tooltips_set_tip () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb75c6200 in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0
#11 0xb75c3d0f in g_main_depth () from /usr/lib/libglib-2.0.so.0
#12 0xb75c4cb5 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#13 0xb75c4fd7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#14 0xb75c551e in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#15 0xb79fc10f in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#16 0x0806ef68 in main ()

Comment 13

13 years ago
Possible that the CSS contains unicode as mentioned in bug 242327?

Comment 14

13 years ago
recursion in CSS?

view-source:http://spam.hixie.ch

  <link rel="stylesheet" href="/resources/style/spaced.css" type="text/css"
media="all" title="Spaced">

http://spam.hixie.ch/resources/style/spaced.css

@import url(/site.css);

view-source:http://spam.hixie.ch/resources/style/site.css
  <link rel="stylesheet" href="/resources/style/spaced.css" type="text/css"
media="all" title="Spaced">


So the 404 page is calling the stylesheet generating the 404

Comment 15

13 years ago
working, sort of: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050329
crashing: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050409

BuildId 2005032905 shortly shows a page with white background, then background
is maroon, with unreadable black font. Opera displays fine.

Files loaded, as seen in LiveHTTPHeaders:
http://spam.hixie.ch/
http://spam.hixie.ch/resources/style/spaced.css
http://spam.hixie.ch/site.css
http://spam.hixie.ch/resources/style/debug.css


Keywords: regression

Comment 16

13 years ago
working : Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050404
crashing: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050504

Checkins in that timeframe:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-04+00%3A00&maxdate=2005-04-05+05%3A00&cvsroot=%2Fcvsroot

Comment 17

13 years ago
maybe regression from 
Bug 288921 [FIX]Media (and XUL) documents have no content-disposition

2005-04-04 20:28	bzbarsky%mit.edu 	mozilla/ docshell/ base/ nsDocShell.h 
1.178 	2/0  	Move processing of various headers from the content sink into the
document so it'll happen for all of our document types. Bug 288921, r+sr=jst

see talkback 4978925
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=4978925
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/content/base/src/nsDocument.cpp&mark=4429&rev=#4429

Stack Trace  	
nsDocument::SetHeaderData 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocument.cpp,
line 1224]
nsDocument::RetrieveRelevantHeaders 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocument.cpp,
line 4429]
nsDocument::StartDocumentLoad 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocument.cpp,
line 953]
nsHTMLDocument::StartDocumentLoad 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/html/document/src/nsHTMLDocument.cpp,
line 703]
nsContentDLF::CreateDocument 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/build/nsContentDLF.cpp,
line 435]
nsContentDLF::CreateInstance 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/build/nsContentDLF.cpp,
line 227]
nsDocShell::NewContentViewerObj 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp,
line 4853]
nsDocShell::CreateContentViewer 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp,
line 4718]
nsDSURIContentListener::DoContent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/docshell/base/nsDSURIContentListener.cpp,
line 131]
nsDocumentOpenInfo::TryContentListener 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/uriloader/base/nsURILoader.cpp,
line 739]
nsDocumentOpenInfo::DispatchContent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/uriloader/base/nsURILoader.cpp,
line 468]
nsDocumentOpenInfo::OnStartRequest 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/uriloader/base/nsURILoader.cpp,
line 328]
nsHttpChannel::CallOnStartRequest 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,
line 694]
nsHttpChannel::ProcessNormal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,
line 856]
nsHttpChannel::ProcessResponse 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,
line 779]
nsHttpChannel::AddRef
0xdad4e930
those stacks do not indicate a networking bug at all. -> layout?
Assignee: darin → nobody
Component: Networking: HTTP → Layout
QA Contact: networking.http → layout
Isn't this the same as bug 231776?
That it is. See debug.css linked from spam.hixie.ch.

Marking as such, reopen if issue.

*** This bug has been marked as a duplicate of 231776 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE

Comment 21

13 years ago
(In reply to comment #19)
> Isn't this the same as bug 231776?

This bug is a recent regression, see comment 16, comment 17.
Bug 231776 is older, so it can´t be the same, reopening.

Status: RESOLVED → REOPENED
Depends on: 231776
Resolution: DUPLICATE → ---

Comment 22

13 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050410

No crash seen on testcase of Bug 231776
https://bugzilla.mozilla.org/attachment.cgi?id=147856

I made a local copy saved as HTML only and added   <base
href="http://spam.hixie.ch">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html lang="en">
 <head>
  <base href="http://spam.hixie.ch">
  <!-- page dynamically created -->
  <link rel="stylesheet" href="/resources/style/spaced.css" type="text/css"
media="all" title="Spaced">
  <link rel="alternate stylesheet" href="/resources/style/orange/"
type="text/css" title="Orange" media="all">
  <link rel="alternate stylesheet" href="/resources/style/debug.css"
type="text/css" title="Debugging" media="all">
  <link rev="made" title="Ian Hickson" href="mailto:website@hixie.ch">
  <meta name="copyright" content="&copy; copyright 2003 by Ian Hickson">

  <title>spam.hixie.ch</title>
 </head>

The local copy starts showing the default stylesheet "spaced.css" specified in
the file, but doesn´t crash when switched to other stylesheets.
The crash happens, when the original website is loaded, which specifies orange
as alternate stylesheet in the file, but as default style in the http header.
rel="alternate stylesheet" href="/resources/style/orange/"

TB4983459G, TB4982304E identical to TB4978925 shown in comment 17

HTTP header:

HTTP/1.x 200 OK
Date: Sun, 10 Apr 2005 15:44:24 GMT
Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_gzip/1.3.26.1a PHP/4.3.10
mod_ssl/2.8.19 OpenSSL/0.9.6c
X-Pingback: http://tracking.damowmow.com/
Content-Langauge: en-GB-Hixie
default-style: Orange
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 614
(Reporter)

Comment 23

13 years ago
(In reply to comment #22)
>
>
So the crash is happening because the stylesheet defined in the headers as the
default is different than the one defined as the default in the document?  Or
rather as mentioned in comment #14, it is because of recursively calling
stylesheets?
Man... Talk about confused bugs....  I'm going to assume that all the random
aviary/branch/milestone noise is either noise or a dup of bug 231776 and focus
on the regression reported in comment 15 and later.  But in general, please
please file one bug per issue.

Hermann, good catch on the bug that regressed this crash.
Blocks: 288921
Keywords: helpwanted, qawanted
Priority: -- → P1
Summary: Hang in Trunk, crash in Milestone and Aviary, crash in Seamonkey when going to specified URI. → [FIX]trunk crash when going to specified URI [@ nsDocument::SetHeaderData]
Whiteboard: testcase-needed
Target Milestone: --- → mozilla1.8beta2
Created attachment 180307 [details] [diff] [review]
FIx

jst, sorry to dump this on you too, but peterv's still out of town...  Comments
in the patch say it all.
Attachment #180307 - Flags: superreview?(jst)
Attachment #180307 - Flags: review?(jst)
(Reporter)

Comment 26

13 years ago
(In reply to comment #24)
> Man... Talk about confused bugs....  I'm going to assume that all the random
> aviary/branch/milestone noise is either noise or a dup of bug 231776 and focus
> on the regression reported in comment 15 and later.  But in general, please
> please file one bug per issue.
>
My apologies, I thought it was important to know that the same thing happens on
every build.  


Just a note, it now crashes every time in Trunk 20050410, when I could only get
it to hang most of the time in 20050409.  Although I am sure they are the same
stacks as the previous talkback IDs, the ones from 20050410 are:  TB4988513E and 
TB4988523Z.
> the same thing happens on every build.  

But it doesn't.  The stacks are totally different, some of the builds are
hanging while others crash (per original summary), etc....

Comment 28

13 years ago
(In reply to comment #24)
> Man... Talk about confused bugs....  I'm going to assume that all the random
> aviary/branch/milestone noise is either noise or a dup of bug 231776 and focus
> on the regression reported in comment 15 and later.  But in general, please
> please file one bug per issue.

Are the obervations from comment 14 also irrelevant? That´s been my first step
into this bug, and I assumed the recursion to be the cause of the crash.
Then, after that, I decided I had to crash too, and when BuildID 20005032905
wasn´t crashing, I had to go for the regression.

> Hermann, good catch on the bug that regressed this crash.

This one was fairly easy. It´s always nice to have a one day timeframe, but
looking at the check-ins I had no clue, resp. the wrong one ;-)
But clicking on the right side of the talkback stack trace loads annotated
source, hovering over the names gives the date, and comments, including
bugnumber, so it was a fairly reasonable assumption that your check-in could
have caused that. 
Looking at your patch I assume the reason for the crash was that default
stylesheet specified in the file and default style specified from HTTP-Header
are different, but I still don´t have a clue. 
Thanks for the quick reaction.
> Are the obervations from comment 14 also irrelevant?

Unfortunately, yes.

> I assumed the recursion to be the cause of the crash.

There's no recursion involved.  You incorrectly resolved the relative URI
"/site.css" when testing.  Even if that were what was being returned, that's
HTML, not CSS, so would just fail to parse.  Finally, we do have recursion
protection in the CSSLoader....

The reason for the crash is that the HTTP headers specify a default stylesheet
at all.  We tried to tell the CSSLoader about this default sheet before we'd
created the CSSLoader, which crashed.


Comment 30

13 years ago
> The reason for the crash is that the HTTP headers specify a default stylesheet
> at all.

Is this finally the proof we needed to show Hixie is evil, and should be brought
before the W3C Security Committee?

Comment 31

13 years ago
(In reply to comment #30)
 
> Is this finally the proof we needed to show Hixie is evil, and should be 
> brought before the W3C Security Committee?

You can´t do this to his cat! 
Every dog has a master, and every cat has a human, you´ve got to ask her/him
(the cat) first about how to proceed with their human


Boris, thanks for the clarification:

> > Are the obervations from comment 14 also irrelevant?
> There's no recursion involved.  You incorrectly resolved the relative URI
> "/site.css" when testing.  Even if that were what was being returned, that's
> HTML, not CSS, so would just fail to parse.  Finally, we do have recursion
> protection in the CSSLoader....

I don´t take anything as granted, if I´m looking at bugs, I know the one´s I
produce myself ;-)
I also had doubts when I further went into that bug, and didn´t see the 404 I
saw earlier, but I don´t like working with current nightlies because of Bug 288406	

> The reason for the crash is that the HTTP headers specify a default 
> stylesheet at all.  We tried to tell the CSSLoader about this default sheet 
> before we'd created the CSSLoader, which crashed.

Thanks again.
If I understand the patch correctly, the old code assumed the cssloader existed,
the new code first try to create it, then checks if it exists, an then uses it,
and the second file gets only an additional comment to prevent future
regressions ;-)

Comment 32

13 years ago
(In reply to comment #31)
> You can´t

I don´t know what is wrong with my keyboard, maybe there is some artificial
intelligence working for marketing?
http://en.wikipedia.org/wiki/Heavy_metal_umlaut
> If I understand the patch correctly,

You do, based on your comment.
Comment on attachment 180307 [details] [diff] [review]
FIx

+    // We lazily create our CSSLoader.
+    // XXXbz why?  Wouldn't it make more sense to just create it at
+    // document creation and not do all these null-checks all over?

Hmm, yeah... unless we more than occationally create documents that have no CSS
loader (like for documents loaded as data?), it would make a lot of sense to
create it ahead of time... Maybe file a new bug on that?

sr=jst
Attachment #180307 - Flags: superreview?(jst)
Attachment #180307 - Flags: superreview+
Attachment #180307 - Flags: review?(jst)
Attachment #180307 - Flags: review+
Comment on attachment 180307 [details] [diff] [review]
FIx

Requesting approval for this simple crash fix.	Very very safe.
Attachment #180307 - Flags: approval1.8b2?
Summary: [FIX]trunk crash when going to specified URI [@ nsDocument::SetHeaderData] → [FIXr]trunk crash when going to specified URI [@ nsDocument::SetHeaderData]

Comment 36

13 years ago
Comment on attachment 180307 [details] [diff] [review]
FIx

a=asa
Attachment #180307 - Flags: approval1.8b2? → approval1.8b2+
Filed bug 290068, and checked in.
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → FIXED
(Reporter)

Comment 38

13 years ago
Verified Fixed in 20050417, thanks bzbarsky
Status: RESOLVED → VERIFIED
Part of the confusion in this bug is that bug 231776 has the same url testcase,
but already seems to be fixed somehow. Wouldn't it be better if that bug became
resolve->worksforme?
> but already seems to be fixed somehow

It's "fixed" by disabling absolute positioning on such pages altogether.  The
underlying bug is still there and still needs to be fixed.
Crash Signature: [@ nsDocument::SetHeaderData]

Updated

7 years ago
Assignee: nobody → bzbarsky
You need to log in before you can comment on or make changes to this bug.