488772 - Functional tests for Private Browsing mode not possible due to connection drop

Status: VERIFIED FIXED

(Firefox :: Private Browsing, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

+++ This bug was initially created as a clone of Bug #488752 +++

This bug is a spun-off from bug 488752. I talked with Clint and Mikeal on IRC and this seems to be a serious blocker for us. Running any Mozmill test from the command line or from buildbot (in the future) will fail. So no Private Browsing test automation would be possible.

Do we really have to shutdown all connections? Can't we have an exclusion list of protocols here? Something which is similar to network.security.ports.banned.override?

Here Clint's comment:

If you have any state listeners using sockets, those sockets are destroyed upon entry into PB mode. We use a socket mechanism to allow jsbridge to remote control a mozmill test running in "automatic" mode.  That's how we originally found this bug, in fact, the mozmill test stopped working.  I don't think this would affect a mochitest run.

Comment 1

[(no longer active)]

Boris, is there any way to only kill SSL sockets and not the other types of sockets?  For some context, this was done in bug 463256...

Comment 2

[Boris Zbarsky [:bzbarsky]]

I have no idea.  You know at least as much about our socket code as I do...

Comment 3

[cmtalbert]

Mikeal, can you detail the type of local socket connection that jsbridge uses to connect to the mozmill instance inside the browser?  I could try to describe it, but I think you can do a better job.

Comment 4

[(no longer active)]

(In reply to comment #2)
> I have no idea.  You know at least as much about our socket code as I do...

Do you know anyone whom we should ask about this?  :-)

Comment 5

[(no longer active)]

(In reply to comment #3)
> Mikeal, can you detail the type of local socket connection that jsbridge uses
> to connect to the mozmill instance inside the browser?  I could try to describe
> it, but I think you can do a better job.

It doesn't really matter, as currently the private browsing service turns offline mode on and off successively which should disconnect any type of socket connection AFAIK.

Comment 6

[Mikeal Rogers [:mikeal] (mrogers@)]

    this.serv = Cc['@mozilla.org/network/server-socket;1']
        .createInstance(Ci.nsIServerSocket);
    this.serv.init(this.port, true, -1);
    this.serv.asyncListen(this);

http://www.xulplanet.com/references/xpcomref/ifaces/nsIServerSocket.html

Comment 7

[Mikeal Rogers [:mikeal] (mrogers@)]

> It doesn't really matter, as currently the private browsing service turns
> offline mode on and off successively which should disconnect any type of socket
> connection AFAIK.

Is there a reason "offline" mode needs to disconnect from localhost connections? I can see a good use case for offline mode still connecting to localhost, like if I'm on a plane and I still want to develop against a local server.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Do you know anyone whom we should ask about this?  :-)

Darin or biesi, maybe?

Comment 9

[(no longer active)]

(In reply to comment #7)
> > It doesn't really matter, as currently the private browsing service turns
> > offline mode on and off successively which should disconnect any type of socket
> > connection AFAIK.
> 
> Is there a reason "offline" mode needs to disconnect from localhost
> connections? I can see a good use case for offline mode still connecting to
> localhost, like if I'm on a plane and I still want to develop against a local
> server.

The current services that the platform offers do not provide this level of granularity (i.e., we are either in offline state for everything or we're not).

However for the case of bug 463256, I'd argue that even if the platform did provide such a service, we'd still want to set everything to offline mode, to prevent the original problem in that bug to manifest itself for local SSL servers.

At the worst case, we could introduce a hidden pref which disables manipulation of the offline mode for MozMill tests, but I'd rather have mconnor's approval before writing a patch (which should be a trivial patch anyway).

Comment 10

[(no longer active)]

(In reply to comment #8)
> > Do you know anyone whom we should ask about this?  :-)
> 
> Darin or biesi, maybe?

biesi: please see comment 1.

I'm not sure about Darin's bugzilla ID though...

Comment 11

[Boris Zbarsky [:bzbarsky]]

Neither of them really reads bugmail nowadays, so you'd have to mail them directly...

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ehsan, have you ever got an answer from Darin or Biesi to your email?

Comment 13

[(no longer active)]

(In reply to comment #12)
> Ehsan, have you ever got an answer from Darin or Biesi to your email?

No, unfortunately not.  I'm not sure how to proceed here...

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Since I know Biesi I have contacted him too. Let's hope for an answer in the near future.

Comment 15

[(no longer active)]

Once bug 496335 is fixed, this will be a non-issue.

Comment 16

[Tomas]

496335 is fixed.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks fantastic. Mozmill tests for the Private Browsing mode are executed completely now! I hope we can get it into 1.9.1.

Verified fixed with the fresh debug build Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090711 Minefield/3.6a1pre ID:20090711205434

Comment 18

[(no longer active)]

Henrik, this should now work on 1.9.1 as well.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

That works fantastic with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090831 Shiretoko/3.5.4pre ID:20090831030742