1105578 - Firefox does not always stop loading images after a certain image has been singled out

Status: RESOLVED INCOMPLETE

(Core :: Networking: HTTP, defect)

Description

[Stefan]

User Agent: 

Steps to reproduce:

1. Ensure that your Internet-Connection is sufficiently slow (1 Mbps is a good value). 
2. Use a HTTP proxy which allows you to monitor the connections.
3. Open the testcase http://imgur.com/gallery/aeLG2
4. Wait until at least the first three images become visible.
5. Right click at the second image and "view image".
6. wait a second click right click "back"
7. Right click at the second image again and "view image".


Actual results:

7. There are connection open/active which do not belong to any object in the DOM.


Expected results:

7. Only keep connections open to those objects which are in the DOM.

Comment 1

[:Gijs (away/busy until Mar 10)]

What exactly do you mean by:

7. There are connection open/active which do not belong to any object in the DOM.

?

In particular, what are you using to check for such connections, and are we just talking keepalive'd TCP things or are you seeing actual HTTP traffic for things which should no longer be requested at all? Are new ones initiated, or are we just talking about existing ones completing?

Also, are you actually using Firefox 28, which is old and has known security vulnerabilities? And if so, can you reproduce with a more recent build?

Comment 2

[Stefan]

[BTW: Can someone put "Courier New" *after* "monospace" and increase the font contrast from rgb (64, 64, 64) which is a bit much!]

(In reply to :Gijs Kruitbosch from comment #1)
> In particular, what are you using to check for such connections,

I am using an HTTP proxy to monitor the connections.

> and are we just talking keepalive'd TCP things or are you seeing actual HTTP traffic
> for things which should no longer be requested at all?

I see actual HTTP traffic passing through those connections.

> Are new ones initiated, or are we just talking about existing ones completing?

We are talking about the existing ones "completing" (in step 7, in step 5 there are none as expected). But what if they do not complete, e.g. if the server is sending data until the connection is terminated on the client side?

> Also, are you actually using Firefox 28, which is old and has known security
> vulnerabilities?

Yes.

> And if so, can you reproduce with a more recent build?

I have no more recent build at hand.

Comment 3

[Patrick McManus [:mcmanus]]

does it never get canceled, or does it just not happen as quickly as you would like?

(i.e. if it is an infinitely large file - does it get canceled).

If its a matter of responsiveness then I suspect the issue is high delay making that slow.. potentially queueing induced delay with your shaper.

if its a matter of never getting canceled then this should be a DOM bug. but I suspect its really not a bug at all.

h2 will be much more responsive to this kind of thing.

Comment 4

[Stefan]

(In reply to Patrick McManus [:mcmanus] from comment #3)
> does it never get canceled, or does it just not happen as quickly as you
> would like?

The transfers obviously finish when all data is transmitted.

> (i.e. if it is an infinitely large file - does it get canceled).

All the GIFs are of finite size and I have no access to imgur so I cannot install a script which generates an endless stream of data. I also could not prepare a testcase on my server.

> If its a matter of responsiveness then I suspect the issue is high delay
> making that slow.. potentially queueing induced delay with your shaper.

What shaper do you mean? I have no shaper in place.

> if its a matter of never getting canceled then this should be a DOM bug. 

One cannot empirically confirm that some process will never terminate. You are asking for the impossible.
In my view transfers of objects which dropped from the DOM shall be terminated immediately.

> h2 will be much more responsive to this kind of thing.

Who/What is h2?

Comment 5

[Patrick McManus [:mcmanus]]

(In reply to Stefan from comment #4)

> 
> All the GIFs are of finite size and I have no access to imgur so I cannot
> install a script which generates an endless stream of data. I also could not
> prepare a testcase on my server.

it would be helpful to be less literal :)

> 
> > If its a matter of responsiveness then I suspect the issue is high delay
> > making that slow.. potentially queueing induced delay with your shaper.
> 
> What shaper do you mean? I have no shaper in place.
> 

By shaper I mean choke point.. most people would need a shaper to test the 1mb/s link.

> > if its a matter of never getting canceled then this should be a DOM bug. 
> 
> One cannot empirically confirm that some process will never terminate. You
> are asking for the impossible.
> In my view transfers of objects which dropped from the DOM shall be
> terminated immediately.
> 

immediately cannot happen. it takes an rtt for a channel's cancelation semantics to take effect.. rtt can get severely bloated in some environments due to buffering and packet queueing.

so I was trying to figure out if what you were seeing was just due to a bufferbloat induced high rtt, or if it was caused because the DOM wasn't generating a cancellation event (or for that matter if the networking layer wasn't acting on the cancellation event). Understanding whether the image is ever aborted before natural completion is key to that - but you need to understand that the laws of physics and http/1 don't let it happen immediately.

> > h2 will be much more responsive to this kind of thing.
> 
> Who/What is h2?

h2 is http/2.. as it uses fewer tcp connections it is less impacted by buffer bloat, and because it can both cancel channels and create new ones on the same connection it can be more responsive than h1 as well.