That description about covers it. Clicking on the Liferay tabs to switch between portal pages does use a new URL and make a new page request so it does appear that the bridge instances are all being unloaded/loaded as required.

I did notice something of a pattern to the when the "Network Connection Interrupted" dialog appears. I have 3 portal pages: one with two chat instances (Chat), one with two ticking clocks (Clock), and one with two Comp Showcase portlets (Showcase). If I switch away from Chat or Clock before the heartbeat has started up (there is a brief window to do it) then the dialog does not appear. Once the heartbeat has started, if I switch away from either of those two, the the dialog is displayed briefly before the page disappears. I don't see it switching away in Showcase because the Showcase portlets have the connection component on the page. I do see it turn red before it disappears.

It looks like we should be flagging that we are shutting down so we don't communicate unnecessary information (like Network Connection Interrupted) but I'm not sure why it would be specific to Firefox.

Further investigation seems to indicate that this behaviour occurs outside of portlets as well. If I take a simple clock app (async with a 3 second interval) and load it into a page in Firefox, the Network Connection Interrupted dialog will appear briefly before navigating to a completely different page. I didn't see it using Auction Monitor on our main site (icefaces.org) but if I build and run Auction Monitor for the 1.7.1 branch, it does appear before going going to the next page.

Clear 'conection lost' listeners when navigating to a different page or reload the page to avoid bogus 'Network Connection Interrupted' messages.

Firefox returns HTTP status code with value 0 when a HTTP connection is severed right before the page is unloaded. Usually value 0 represents a communication error.

tested with latest 1.7 branch on Liferay JBoss, issue is resolved.

A customer is still seeing this issue. It appears to be fixed for regular web apps and some portlet situations but I am able to recreate it in Firefox only by:

1) Create a portal page
2) Add at least 3 instances of an async portlet to the page. The problem doesn't seem to occur with me when there is only 1 or 2 portlets on the page. Also the portlet cannot have a connection status component or the dialog does not appear (so use the chat example rather than component showcase for testing).
3) Once the portal page has finished loading, navigate away from the page (e.g. switch to a different Liferay tab or navigate to another site like www.google.ca).

The Network Interrupted dialog should appear.

Remove bad response handler on the blocking connection since there is no way to detect page unloads before the blocking response handler is invoked. Also, among browsers, only Firefox is returning error codes when connection is closed prematurely.