972127 - EventSource can block new HTTP requests without clear indication

Status: NEW

(Core :: Networking, defect, P5)

Description

[Stephan Sokolow]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140112081156

Steps to reproduce:

1. Go to FiMFiction.net and log in. (to enable real-time notifications)
2. Middle-click many interesting-looking stories. (possibly as few as six)
3. Wait a few hours (possibly overnight)
2. Try to navigate one of the tabs from the story page to Chapter 1.




Actual results:

Because Firefox hasn't implemented SharedWorkers, the site falls back to a fragile localStorage-based form of inter-tab synchronization in an attempt to open only one EventSource for real-time notifications.

(See http://www.fimfiction.net/blog/191727/realtime-notifications)

Given time, this mechanism fails, causing the open tabs to open up their own EventSource connections.

This quickly exhausts the connection limit, forcing the next attempt at navigation to be forever stuck on the first (waiting for connection) phase of the spinner while it waits for one of the long-lived connections to act like HTTP connections and complete or time out.

(Which makes it seem like some kind of bug or resource leak in Firefox because restarting the browser and restoring from a saved session fixes the problem temporarily and the UI gives no indication that this is a pathological example of intended behaviour or the fault of fragile code on the site.)


Expected results:

I propose at least one (ideally both) of the following:

1. Long-lived connections like EventSource and WebSockets should be capped independently from HTTP connections so that a short-lived HTTP connection can only be starved by the hard-to identify cases like HTTP long polling.

2. There should be some kind of visual indication when the top-level request for a navigation event is blocked by a connection limit. (Perhaps a third state to the spinner which indicates "blocking on a Necko resource cap" separately from "waiting for the TCP connection to be established".)

While not ideal since it's transient and easy to miss, Chrome already does something similar to #2 with status bar messages.

Comment 1

[Jason Duell]

Note that solution #1 from comment 0 has been expressly ruled out by both Chrome and Mozilla's necko module owner.  I personally feel that purity of HTTP semantics (almost an oxymoron anyway :) shouldn't override usability here, but it's not my call.  See bug 906896.

Also, we don't currently have any way IIRC for client code of necko to know when we've hit the connection limit--we just queue and forget, forever. But we could implement some way to query it to support #2.

> the site falls back to a fragile localStorage-based form of inter-tab synchronization 

Is it fragile because it's written badly, or is this something that's hard to do right?  Is it the same solution linked to in bug 906896 comment 21?

Comment 2

[Stephan Sokolow]

(In reply to Jason Duell (:jduell) from comment #1)
> > the site falls back to a fragile localStorage-based form of inter-tab synchronization 
> 
> Is it fragile because it's written badly, or is this something that's hard
> to do right?  Is it the same solution linked to in bug 906896 comment 21?

I honestly don't know. I don't currently have enough free time to justify debugging someone else's code without any guarantee that my suggestions would be listened to.

All I know is that it's supposed to provide functionality equivalent to a single EventSource managed by a SharedWorked but, if the tabs are left open too long, the inter-tab synchronization breaks down and each tab tries to open its own EventSource, which snarls things up if there are enough tabs open for it to hit the connection limit.

Comment 3

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258