119399 - XHTML document as XML does not load when a <link>'d stylesheet present

Status: VERIFIED FIXED

(Core :: XML, defect, P1)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

Recent regression (in the last 2 days)

Currently using linux 2002011010:

Visiting an XHTML page served with an XML mime type that contains <link
rel="stylesheet" href="foo"/> will not load the page.

Simple testcase:

http://www.returnzero.com/xmlstyle.xhtml has no <link/> and works.
http://www.returnzero.com/xmlstyle2.xhtml does not work because it has a <link/>

Actual results: The browser goes to the page and loads the <title> in the window
title but does not load any content.  If the CSS file does not exist, the
browser hangs forever until the 'STOP' button is pressed.

Expected: page loaded with styles applied appropriately.  If the CSS file can't
be loaded, just load the raw content.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

bz sez parser -- moving.

<bz> caillon: the XML parser got whacked
<bz> caillon: a _lot_.  :)
<bz> caillon: just punt it to Harish
<bz> caillon: it was a major perf win on startup and other XUL stuff
<bz> caillon: since it sped up XML parsing.  :)

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This is still XML component, but your bet that it is harishd is pretty good.
We'll investigate.

Comment 3

[harishd]

Attachment: patch v1.1 [ blocking should only happen after processing an end tag ]

Comment 4

[harishd]

Since <foo/> == <foo></foo> the expat parser makes a couple of call backs, one
for <foo> and one for </foo>, to the expat driver. If we block the parser after
processing <foo> then the buffer position would never get updated correctly (
i.e. after <foo/> ) in the expat parser. In other words, the position would
still point to the begining of the start tag and hence would end up processing
the same tag indefinitely. The fix is to block the parser after processing the
end tag ( </foo> ) which would update the expat buffer position correctly.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 64538 [details] [diff] [review]
patch v1.1 [ blocking should only happen after processing an end tag ]

r=heikki

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 7

[harishd]

Comment on attachment 64538 [details] [diff] [review]
patch v1.1 [ blocking should only happen after processing an end tag ]

jst sez sr=

Comment 8

[harishd]

FIXED.

Comment 9

[Moied]

Verified fixed with build ID 20020124 on win2k.