306767 - specifying an empty style sheet results in strange behavior

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Sean Coates]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

See the URL; here's the source:
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

<window
  id="foo"
  title="Foo"
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
>
  <?xml-stylesheet href="data:text/css,"?>
</window>

Yes, I realize it's invalid to have nothing after the ",", but it shouldn't
crash FF.

NOTE: I haven't let it ACTUALLY crash; it's more like an infinite loop (which
keeps allocating more and more memory).

Reproducible: Always

Steps to Reproduce:
1. Have FF render the XUL above.

Actual Results:  
infinite loop (which keeps allocating more and more memory)

Expected Results:  
Render empty window or complain about invalid XML

Comment 1

[timeless]

this doesn't sound like a crash. when i load that file using a trunk build from
8/25-05, i get a non painting window that bleeds through the previous content.

if you had crashed, you'd have gotten a dialog from the os and probably one from
talkback.

Comment 2

[Sean Coates]

Sure. I indicated this in the comments. I guess it's not officially a crash
(although, I suspect it would become one, if left unattended). Other browser
windows become unresponsive, and I need to use task manager to kill it.

It also keeps allocating more and more RAM while it's in "non-painting" state
(again, according to Windows' task manager).

Someone with more karma can feel free to change the topic without risking insult
to me, if removing the word "crash" would be more appropriate.

S

Comment 3

[timeless]

ok :). does this happen for you w/ ff1.5 candidates?

Comment 4

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050901
Firefox/1.0+ ID:2005090117

results in blank page that keeps loading forever
no crash
no lockup (memusage ~80%)
no mlk detectable

Comment 5

[Sean Coates]

Sorry for not getting back to you sooner.
I'm running ff1.5, now, and the behaviour is somewhat different:
- no locking (I'm able to close the tab)
- mem usage still increases incrementally over time (looks like 64k at a time -- I've seen it grow 20MB)
- page never finishes loading

S

Comment 6

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060117 Firefox/1.6a1 ID:2006011706

this seems fixed on trunk.
-No leaks detected in dbaron's leaktest
-page does not continue to try to load the non-existent css file

Comment 7

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20060117 Firefox/1.5 ID:2006011703

OK, this is still an issue on FF1.5.0 / FF2.0 branch.
Lemme try to figure out what fixed this on trunk

Comment 8

[Peter van der Woude [:Peter6]]

on trunk :

fails in 20051217 1141 pst build
works in 20051218 0328 pst build

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=20051217+1100&maxdate=20051218+0328&cvsroot=%2Fcvsroot

it looks like Bug 320498 (? 1.8.0.2) may have fixed this on trunk.

so if that patch is approved this should be fixed for Firefox 1.5.0.2

Comment 9

[Nickolay_Ponomarev]

WFM too, marking as such. The patch in bug 320498 has approval1.8.0.2? and approval1.8.1? flags, so if it gets approved (and this bug is fixed by that patch), it will get checked in. No point in keeping this bug open.