329681 - multipart/x-mixed-replace with 1ms intervals hangs Firefox

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[Lars Schöning]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

When loading a multipart/x-mixed-replace server method with quick refresh firefox stops responding.

Reproducible: Always

Steps to Reproduce:
1. Have firefox connect to a server with output similar to:
[HTTP HEADER]
Content-type: multipart/x-mixed-replace;boundary=438e635eab93d28d03183b7e8368da01

--438e635eab93d28d03183b7e8368da01
Content-type: text/plain

1 [WAIT 1 MS]

--438e635eab93d28d03183b7e8368da01
Content-type: text/plain 

2 [WAIT 1 MS]

--438e635eab93d28d03183b7e8368da01
Content-type: text/plain

3 [WAIT 1 MS]

...

Actual Results:  
Firefox does not respond properly and even after pressing the cancel button does not come back to normal state.

Expected Results:  
Firefox would respond again.

Php code to reproduce:
<?php

$random = md5 ( rand () . microtime () );


header( 'Content-type: multipart/x-mixed-replace;boundary=' . $random );

echo "\n--$random\n";

$i = 1;



while ( $i ++ ){
     usleep(1);
     echo "Content-type: text/plain\n\n";
     echo "$i";
     echo "--$random\n";
     do_output ();
  }

//  echo "Content-type: text/plain\n\n";
//  echo "The end\n";
//  echo "--$random--\n";


function do_output ()
{
	flush();
	ob_flush();
}

?>

Comment 1

[Martijn Wargers (dead)]

Testcase from reporter available at: http://wargers.org/mozilla/329681_multi_replaced.php
Indeed, the testcase freezes Mozilla, this isn't the case with IE6.

Comment 2

[Darin Fisher]

Martijn, keep in mind that IE6 does not understand the multipart/x-mixed-replace mime type! ;)

-> me

Comment 3

[Darin Fisher]

I can reproduce this using FF 1.5.0.1 under Windows XP.  Investigating...

Comment 4

[Darin Fisher]

I think the problem here is really just that the browser keeps rendering each document in the multipart payloads.  It never stops to "breathe" (to give the UI a chance to refresh).  I suspect that this happens in large part because of the DocShell's code that suppresses UI event prioritization during page load:
http://lxr.mozilla.org/mozilla/search?string=PL_FavorPerformanceHint

As a result, UI events starve.  My work on the Thread Manager should solve this class of bugs and others like it.

Comment 5

[Martijn Wargers (dead)]

I still get a freeze with the testcase, with the 2006-05-11 build (after the fix from bug 326273).

Comment 6

[u88484]

(In reply to comment #5)
> I still get a freeze with the testcase, with the 2006-05-11 build (after the
> fix from bug 326273).
> 

Confirmed

Comment 7

[Lars Schöning]

After testing with v2RC2 the problem has changed. Now the functionality (Count up) is actually given, although numbers are obviously omitted in the test case.

It is still impossible to cancel the loading process, with the browser rendered unresponsive to any user interaction.

Comment 8

[Darin Fisher]

-> reassign to default owner

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 10

[Andrei Purice]

Following the reporter's steps I am able to confirm that the issues doesn't happen anymore on Windows 10 on any of the current versions of Firefox Nightly 87.0a1 (2021-02-16), beta 86.0 and release 85.0.2. The example url test case doesn't crash Firefox anymore.

Closing this issue as Resolved > Worksforme.
Feel free to re-open or file a new bug if this issue reoccurs again.