567124 - Firefox 3.6.3 has far worse Flash performance than 3.5.9

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Vadim Rapp]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9

I uploaded youtube video (see the URL) that shows how performance of Flash 10.0.45.2 significantly drops with the upgrade from Firefox 3.5.9 to 3.6.3 . The testing was made at website en.dinoparc.com, which is flash game. You can see how after the upgrade from 3.5.9 to 3.6.3 rendering of every page takes several times more time.

Reproducible: Always

Steps to Reproduce:
1. sign up and play the game at en.dinoparc.com in FF 3.5.9 / flash 10.0.45.2
2. upgrade FF to 3.6.3
3. see how performance drops.

Comment 1

[Matthias Versen [:Matti]]

Please retest with the 3.6.4 beta or a nightly trunk build.

Comment 2

[Vadim Rapp]

Tried in 3.6.4 and in nightly build - no change from 3.6.3.

In 3.5.9 and in IE8, the first navigation to the page with animation takes longer time, but all subsequent are instant; in FF 3.5.9 this effect survives browser restart. In 3.6.3 and later, each navigation takes the same time as the first in 3.5.9 - so it looks like some caching isn't working.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Vadim, would you mind attaching HTTP logs of both 3.5.9 and 3.6.3 doing whatever task it is that shows slowness in 3.6.3 but not 3.5.9?  See https://developer.mozilla.org/en/HTTP_Logging for the directions on getting those.

Comment 4

[Vadim Rapp]

Attachment: log file collected by 3.5.9

Comment 5

[Vadim Rapp]

Attachment: log file collected by 3.6.3

Comment 6

[Vadim Rapp]

Done. Wondering why the log created by 3.6.3 is ~five times larger.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Wondering why the log created by 3.6.3 is ~five times larger.

Well, each data packet received tends to get logged, so if you're hitting the network more....

Here's one obvious difference between the logs.  3.5.9:

0[826140]: uri=http://en.dinoparc.com/swf/dino.swf?$version=1
....
0[826140]: nsHttpResponseHead::MustValidate ??
0[826140]: no mandatory validation requirement
0[826140]: Not validating based on expiration time
0[826140]: CheckCache [this=54cfd50 doValidation=0]

3.6.3:

0[826140]: uri=http://en.dinoparc.com/swf/dino.swf?$version=1
....
0[826140]: nsHttpResponseHead::MustValidate ??
0[826140]: no mandatory validation requirement
0[826140]: Validating based on RFC 2616 section 13.9 (query-url w/o explicit expiration-time)
0[826140]: nsHTTPChannel::CheckCache exit [this=1754870 doValidation=1]

This was a change made in bug 468594.  The comment explaining what's going on with that change is:

  +    // RFC 2616, section 13.9 states that GET-requests with a query-url
  +    // MUST NOT be treated as fresh unless the server explicitly provides
  +    // an expiration-time in the response.

Now in this case the GET does have a query part, and the HTTP response looks like this:

1732[8263c0]: http response [
1732[8263c0]:   HTTP/1.1 200 OK
1732[8263c0]:   Via: 1.1 VPSISPS
1732[8263c0]:   Connection: Keep-Alive
1732[8263c0]:   Proxy-Connection: Keep-Alive
1732[8263c0]:   Content-Length: 816156
1732[8263c0]:   Date: Fri, 21 May 2010 21:18:29 GMT
1732[8263c0]:   Content-Type: application/x-shockwave-flash
1732[8263c0]:   Etag: "48407d-c741c-43b70d70"
1732[8263c0]:   Server: Apache/1.3.41 (Unix) PHP/5.0.4 mod_deflate/1.0.21
1732[8263c0]:   X-Real-Server: gimme1.motion-twin.com
1732[8263c0]:   Last-Modified: Sat, 31 Dec 2005 23:00:00 GMT
1732[8263c0]:   Accept-Ranges: bytes
1732[8263c0]:   Keep-Alive: timeout=1, max=95
1732[8263c0]: ]

There is no Expires or Max-Age header, so the response can't be assumed to be fresh per the above RFC.  Firefox 3.5.9 got this wrong and basically assumed that the response is fresh no matter what.

Now if the response isn't fresh, we have to do a GET to the server.  So we do:

0[826140]: http request [
0[826140]:   GET http://en.dinoparc.com/swf/dino.swf?$version=1 HTTP/1.1
0[826140]:   Host: en.dinoparc.com
0[826140]:   User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
0[826140]:   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
0[826140]:   Accept-Language: en-us,en;q=0.5
0[826140]:   Accept-Encoding: gzip,deflate
0[826140]:   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
0[826140]:   Keep-Alive: 115
0[826140]:   Proxy-Connection: keep-alive
0[826140]:   Cookie: block_dinozListBlock=inline; sid=KYDUHQSQb4CnBiXlLMcDmMQSAkdBgZNe
0[826140]:   If-Modified-Since: Sat, 31 Dec 2005 23:00:00 GMT
0[826140]:   If-None-Match: "48407d-c741c-43b70d70"
0[826140]: ]

The server can now either respond with "nope, hasn't changed from the version you have cached; use the cached version" (HTTP 206 response) or send back the data all over again (HTTP 200 response).  This server does the latter.

So we end up redownloading this 816KB swf file over and over again, because the server keeps claiming it has changed.  Similar for the 500KB http://en.dinoparc.com/swf/map.swf?$version=1

Unfortunately, this looks like a bug in the site (not sending HTTP 206 when it really should).  A bug in Firefox 3.5.9 which caused it to not check with the server at all in situations where it's required papered over this problem, but that bug was fixed in Firefox 3.6.

Comment 8

[Vadim Rapp]

Attachment: HTTP log of IE8 requesting this page

Boris, thanks for your thorough explanation, I forwarded it to the developers of this site.

If you don't mind, still, - I'm curious why this effect does not show up in IE8. I have attached HTTP log (obtained using Proxomitron) of IE8 subsequent request, when the animation already shows up instantly. As you can see, the response to the initial request , +++RESP 523+++ , has 

Cache-Control: no-cache, must-revalidate .

which, if I understand correctly, means that the browser has to revalidate all objects on the page, including two swf's - which is what FF does. But IE8 does not request the .swf's. Why?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> But IE8 does not request the .swf's. Why?

I don't know...  As far as I know, IE generally makes a conditional requests for such requests (and in fact doesn't even store no-cache stuff in its cache at all; see http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx ).

Comment 10

[Wayne Mery (:wsmwk)]

reporter do you still see this problem when using newer version of flash, and current version of firefox?

Comment 11

[Vadim Rapp]

Hard to tell compared to Firefox 3.5.9, but I just compared it to IE8 and to Chrome. Unlike them, FF refreshes the whole page, while they refresh only the changing part of it, and yes, because of that it's somewhat slower.

Comment 12

[Phoenix]

Resolved per whiteboard