93002 - (dial-on-demand) [distribution]Conn: Auto-dial for NT-based Windows

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[susie wyshak]

BuildID:    2001072703 / all

Situation: ISPs need to have Dial-up Networking launched when their customers 
click the browser (rather than sending users separately to open Dial Up 
Networking). This is a critical requirement by browser distributors.

Currently when an offline user clicks the Netscape 6.x icon to execute the 
application after setup by the ISP, the Dial-up Connection window to connect to 
internet does not come up. 

Reproducible: Always
Steps to Reproduce:
>1. Install on XP image  (or NT)
>2. Setup an ISP account using Dial-up Networking.  
>3. Close the connection (go offline)
>3. Now click the Netscape 6 icon.

Actual Results:  You will see the Alert massage saying:
"The connection was refused when attempting up connect."

However, when you manually connect to Dial-up Connection it execute Netscape 6 
application.   

Expected Results:  Dial-up Networking is launched if user is offline when the 
browser is launched.

Comment 1

[susie wyshak]

added cc's and made P1.

Comment 2

[timeless]

this is either networking or xpapps. it's also strange.

windows is supposed to normally prompt on demand. so if you try to open a 
network connection (any app) it should bring up the dialer window.

This request also contradicts the behavior of offline mode and perhaps the way 
european users want to use the web.

Comment 3

[benc]

Do we have a bug that describes the general offline/online & connectivity
behavior (probably not).

I think you have to implement calling the dialing services in Windows, b/c I see
it as a feature in most apps I've used (outlook, IE, and pointcast(?)).

Maybe we should have a bug for the general behavor on allplats? In MacOS, open
transport does this transparently.

Comment 4

[benc]

NEW: I'll take it under networking for investigation.
+ nsenterprise, clarified summary for Windows-only.

Comment 5

[Jussi-Pekka Mantere]

Removing nsenterprise nomination; adding nsBranch.

Comment 6

[Jaime Rodriguez, Jr.]

Neeti/Gagan - No one has commented on this one in a while. Is this a stop ship?
If not, please mark as nsbranch-.

Comment 7

[neeti]

--> to gagan for reassigning it to the correct owner of this bug

Comment 8

[selmer (gone)]

-->msanz for reassignment

Comment 9

[msanz]

it's clearly a minus now (and a mistake). This has to be part of a future
release and as such picked up by the right group. I'll follow up in email before
starting to bounce this bug back and forth, while we find the right owner.

Comment 10

[msanz]

marking minus now, again

Comment 11

[benc]

It isn't clear to me how this would be implemented anyhow. 

If someone is wanting this for a release, I think some idea of how to do this
(or that at least an engineer has established this is feasible in their head)
should be in the bug before it is milestoned.

Comment 12

[timeless]

it was never clear to me how this could happen.

on all systems where i have the internet control panel configured to dial the 
internet as needed all apps that use remote ips generally trigger DUN. can 
someone provide very detailed steps? preferably w2k compat.

Comment 13

[Alec Flett]

as an occasional dialup user, here are my two cents:
mozilla should have the capability to monitor 1 or more internet connections,
and initiate a connection if none of them are currently connected.
On my laptop, I have an ethernet connection and a dialup connection. I have
disabled auto-dialup, because I don't want dialup to kick off when my ethernet
is connected. 

Also, I would like mozilla's offline status to be in sync with the actual
offline status. Meaning that if I start mozilla when there's no connection, then
mozilla should start in offline mode... and when I say, in mozilla, "Go offline"
it should optionally disconnect the dialup connection as well.

the AOL client also offers a neat feature where it disconnects after all
downloads have completed - this would be another nice feature to have built in.
(Yes, I know there are a number of shareware products that do this, but only a
select group of people actually know to go and get these products - it would be
nice to provide this small feature to all our users)

Comment 14

[msanz]

clearly not happening in 0.9.5

Comment 15

[Peter Schäfer]

as an always dialup user, i can only second alecf.

This is exactly like IE and Outlook behave, especially
the "keep-on/offline-status-in-sync" feature is something
i REALLY want to have.

Starting mozilla while not being online and wanting to
write a new mail leads to:

1) Seeing "connection refused while contacting <homepage>" error
   messagebox, click "OK".
2) Change to Mail&News - again a error messagebox pops up
   "Failed to connect to server".
3) Ok - finally switch on "File->Work Offline".
4) Write your mail.
5) Go to dial-up network and tell windows to dial the desired
   internet provider.
6) Wait till dialing is finished.
7) Tell mozilla "Go Online".
8) Say "Send unsent messages".
9) Well, you're finally done. Yay.

This is way to cumbersome for my grandma :)

Comment 16

[msanz]

setting milestone, hope to get to it before then

Comment 17

[tao]

taking it over from msanz (unless someone objects)

Comment 18

[tao]

Hi, 

Would anyone being able to reproduce the problem please let me know which
internet dialup app. you are using (and where to get it)? 

I am not seeing this problem; the dialer does pop up automatically when N6 starts
to load a remote page. It might have to do with whether the dialer detects monitor
network request.

Comment 19

[Peter Schäfer]

What OS do you using? I'm using Windows 2000 Prof. and there's nothing
like a "dialer", i think. I've just setup a dial-up connection. 
IE and Outlook have a pref which connection they should dial if
you're start them.

NS should have a similar pref also.

I cannot attach a english screenshot of the IE pref (i'm using german W2K)
but fire up IE and go to "Extras->Internet options->Connections (Tab)"
and you'll see it.

There are also options to "dial never", "dial always", 
"dial only if no connection already exists".

Additionally the IE can configured to only use a LAN connection.

Hope i have translated the german OS texts correctly...

Comment 20

[Alec Flett]

this is a feature, not a bug. The feature is to kick off a specific dialup
connection when mozilla launches. This includes being able to enumerate the
available dialup connections and select one of them as the dialup connection
that you want to use.

Comment 21

[Peter Schäfer]

One additional comment:

Not just at startup, please... This feature includes to monitor the
dialup-connection as well.

The online/offline status of NS/Moz. should stay in sync to avoid
error messages - for example - from biff mail checking, if the dialup-
connection was teared down between the checking interval (W2K allows
to set an "idle time" after which the dialup connection automatically
hang up). Maybe TAPI or some RasXXX functions are you're friend...

Comment 22

[tao]

> What OS do you using? I'm using Windows 2000 Prof. 

NT4.0.

> and there's nothing like a "dialer", i think.
I was referring to the dialer program provided by your ISP to establish the 
dial-up connection.

In general, this bug calls for building a set of features to bridge the Browser
client and internet dialer.

Comment 23

[Peter Schäfer]

Hm. I don't think that's right... In NT4 and W2K you don't need
an "dialer".  PPP capabilities are all built-in into the stock 
remote-access services of the OS. In Win95/98/ME this is the 
"dial-up network"; in WinNT/2K the "Remote-Access-Service (RAS)".

I never used any software from my provider, in fact they stopped
releasing own software because "all OS since W95 have this built-in".
All you need is your PPP username/password; just like using Linux.

Comment 24

[tao]

>Hm. I don't think that's right... In NT4 and W2K you don't need
>an "dialer".  PPP capabilities are all built-in into the stock 
>remote-access services of the OS.

I think it's matter of how you define "dialer". IMO, any Windows software that
establishes a computer's network connection via modem is called an internet 
dialer". This software could be a VB script, exe, or whatever. It could be third
party app or bundled with the OS.

> In Win95/98/ME this is the 
>"dial-up network"; in WinNT/2K the "Remote-Access-Service (RAS)".
>
The DUN (you refer to here) is a Windows application helps end users to 
configure dial-up connection via the underlying RAS. It's sort of "internet
connection wizard" built on top of low level syste, service.
 
>I never used any software from my provider, in fact they stopped
>releasing own software because "all OS since W95 have this built-in".
>All you need is your PPP username/password; just like using Linux.
Most of large ISPs do provide their own internet connection wizards (app) to
provide better user experience (w/o configurating protocols). They don't
prevent you from establishing connections as long as you are a good subscriber :-)

Comment 25

[timeless]

tao: Excluding AOL [which is evil]. afaik most major isps use ICW (MCM?) which
allows branding and is a wrapper around DUN.  I've seen this in both AT&T and
Gateway (whatever isp that was ...). [useless url#1
http://www.microsoft.com/ntserver/techresources/commnet/RRAS/ICS_FAQ.asp ]

Modems on windows are controlled by TAPI.  Networking is/should be controlled by
either DUN or RRAS both of which should be using TAPI.

DUN itself has a nice API which i ran across elsewhere which would allow for the
queries we need to do.

here's an article that seems rather appropriate
http://msdn.microsoft.com/library/en-us/dncdev99/html/vc99i10.asp
note that it mentions ie5, which is of course not a part of w95osr0 (nor is ie4
but ...)

more later

Comment 26

[msanz]

>Hm. I don't think that's right... In NT4 and W2K you don't need
>an "dialer".  PPP capabilities are all built-in into the stock 
>remote-access services of the OS. In Win95/98/ME this is the 
>"dial-up network"; in WinNT/2K the "Remote-Access-Service (RAS)".

This is true and it's the way it should work. Unfortunately, this depends on the
OS. It works fine with NT SP5, but I don't think it does with SP6 and I know it
doesn't at all with WinXP. Even if you enable RAS to Automatic, dialer won't
come up when N6 requests a connection.

Comment 27

[timeless]

if that's the case, it should be in microsoft's relnotes

Comment 28

[tao]

reassign to new owner ->dbragg

Comment 29

[dbragg]

I believe this will be post 0.9.8 feature freeze.  Setting ETA out beyond Moz 1.0.

Comment 30

[David G King]

To add my 2c, although I'm no longer on dialup, so I can't test anything...

However, I understand there are two sides to this under Windows 9x. The Internet
app (whatever it may be) makes a call to WINSOCK. DUN is configured via a
Windows Control Panel to connect on demand.

I'm assuming that Netscape, in Online mode, isn't making a call to WINSOCK on
startup.

If anyone from Netscape/Mozilla would like a contact person on doing this, eMail
me and I'll send you their eMail address. (hint: It's the developer of Pegasus
eMail [another shareware app]).

Comment 31

[Jaime Rodriguez, Jr.]

IS this something that will be need for MachV?

Comment 32

[dbragg]

I don't believe so.

Comment 33

[tao]

this affects lots of dial-up users -> nsbeta1.

Comment 34

[Gagan]

Does anyone know what's needed to trigger the DUN dialog box? Rick? Dan? That
will help in making sure that this bug gets to the right owner. 

Comment 35

[dbragg]

Good point Gagan.  I would think this would belong to someone in Necko (but
that's just a guess).

Comment 36

[Gagan]

I don't necessarily agree that this belongs to the Necko team. In fact the more
I think about it the more I am inclined to say it should reside in the docshell
or the webshell which could selectively (hopefully based on a preference) decide
to bring up the DUN autoconnect dialog. But first we need to find out who might
have a solution for it-- anyone remember from the 4.x days? cc'ing selmer here.

Comment 37

[selmer (gone)]

We used to do quite a bit of work to ensure that dialing worked properly.  We
dropped all that stuff when we moved to the new code base.  In addition, MS
changed the rules by introducing new registry keys for no apparent reason (other
than to cause us pain I suppose.)  Serge might remember what the new registry
magic was, I believe he was part of the group that tracked that down.  Anyway,
if the registry is set properly then DUN should autolaunch when the network is
tickled and the app doesn't have to do anything explicit.  (Assuming DUN has
been properly configured and the correct dialer is set up as the default.)

A full implementation sufficient for distributors is beyond our reach for this
release.  The best we can hope for is to find the info on the registry keys and
add some code to zap them so DUN will autolaunch again.

(Please don't get the false impression from the length of this answer that I
actually know anything about this stuff ;-)

Comment 38

[benc]

are we keeping this bug focused on Windows? (I think in Mac OS, Open Transport
will bring up the dialer interactively...)

Comment 39

[Rob Jaworski]

Currently, and for this particular bug, I'm interested in windows.  I'll take a
look at MacOS seperately.

Comment 40

[bobj]

Searched MSDN and found these pages:

Remote Access Service (RAS) Overview
http://msdn.microsoft.com/library/en-us/rras/ras4over_4e5o.asp

RAS AutoDial
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rras/ras4over_71k5.asp
  (Not supported on 95 or NT3.51) When an attempt to connect to a network
  address fails because the host cannot be reached, the AutoDial feature can
  automatically start a dial-up connection operation.

Comment 41

[Steve Meredith (gone)]

The browser's "offline mode" should not be confused with the state of a dialup
connection, which can also be "offline" meaning "disconnected."

Autodial appears to be working properly for Mozilla on all versions of Windows.
You have to configure autodial in the OS for it to work. How you do this is
different between 9x versions and NT-based versions.

For Windows 95, 98, and ME, you configure autodial using Control Panel |
Internet Options | Connections | Dialup Settings. This controls which
connections are dialed under what circumstances. These settings affect MS
programs (IE, Outlook Express,) and all other non-MS network clients. Mozilla
works fine with these settings, dialing up when necessary. IE is a little bit
integrated with the OS in this case, because the cancel button on the dialup
dialog is labeled "work offline" if the application that triggers it is IE, and
it causes IE to go into offline mode if you push it. If other applications
trigger the dialup dialog, this button is labeled "cancel" and it disables
autodial for the duration of the application session if you push it. Another
difference is that IE will give the option of hanging up when closing if it was
the application which triggered the autodial.

For Windows NT, 2000, and XP, you configure autodial for Microsoft apps (IE and
Outlook) the same way as described above. However, these settings have no effect
on non-MS applications. To configure autodial for non-MS applications, you have
to start the OS service "Remote Access Auto Connection Manager." Once this
services has been started, autodial works fine with Mozilla. However, it seems
that this service is configured to NOT start automatically by default, so it
will look like autodial is broken on Mozilla on these systems until the service
is started.

I tested the above assertions using Mozilla 1 rc 1 on Windows XP, 2000, and 98.

Here are some possibilities for improving the situation for Mozilla:

1) At install time, configure the required service as "automatic start" and then
start it. This could be done either a) only if explicitly configured in the
install (my favorite,) b) if no LAN connection is found at install time but a
modem is, or c) prompted for at install time.  This should satisfy the ISPs who
are distributing the browser.

2) Add some controls to the pref UI to start this service and control which
dialup connection is the default. This approach still uses the OS to keep track
of all the settings and make the required connection. Starting a service can
take a long time, so this is not something we'd like to do at startup. It would
be a fair amount of work, including a new Windows-only pref page and a bunch of
API calls, and probably shouldn't go in unless number 1) is not enough. Maybe a
"phase 2" type project.

3) Add a "go offline" button to the Mozilla error dialog which appears when a
network error occurs. Possibly in conjunction with number 4) below. This is the
browser's "offline mode" and doesn't do anything to control a modem. This is not
adding any new dialogs--just a button to the existing dialog. See also bug
113591 for a related discussion.

4) Add a "connect" (or "dial") button to the Mozilla error dialog which appears
when a network error occurs. Possibly in conjunction with number 3) above. This
would call into the OS to bring up a dialer dialog. It wouldn't require the
autodial service to be running.

5) Document how to configure the service to get autodial to work for Windows
NT-based systems.

Comment 42

[Peter Schäfer]

Sorry for the spam, but i'm on W2K SP2 and have
started the service mentioned in comment #41 and
it does NOT work (Mozilla 1.0 RC1). Mozilla
just tries to resolve the URL but does fail after
ages (nameserver timeout). Even if i bring up
the dial-up conn. manually Moz doesn't resolve
the URLs. I have to restart Moz several times
to get the nameserver thing right (but that's 
another bug, i think).

I'm on  a box with TWO (2) dial-up connections
and ONE (1) LAN connection, one dial-up conn. 
is set on "Default" and "Always dial the default 
connection" using the "Internet options" applet in 
the control panel.

Outlook 2000, Outlook Express, IE 6.0, Opera and
Getright do the right thing and pop-up the dial-dialog
wether the mentioned service is started or not. 

I think Mozilla should do this, too, or it just looks
plain broken to the common man :).

Otherwise the UI handling mentioned in #41 looks fine
to me.

Comment 43

[Steve Meredith (gone)]

I forgot to mention in comment #41 that in my experiments, I found that the
autoconnect service only works correctly if the ethernet device is disabled.
Unplugged doesn't seem to be good enough. An important detail.

Comment 44

[tao]

new owner->smeredith

Comment 45

[msanz]

We also found out when we were testing this last year that if the machine had a
network card, it didn't work, but it did if the machine didn't have a network
card. That is consistent with comment #43 from steve...

Comment 46

[Steve Meredith (gone)]

Given that the aforementioned service only works if you don't have a network
card or if it's disabled, do we want to do something else (more reliable) for
NT-based systems? We could look at the settings in the Internet Options
ourselves and bring up the dialer (RAS API or WinInet) when a network connection
error occurs. (Not at startup, because you might be opening your browser to look
at a local file, in which case you don't want a dialer to pop up.)

Comment 47

[tao]

> Given that the aforementioned service only works if you don't have a network
> card or if it's disabled, do we want to do something else (more reliable) for
> NT-based systems? We could look at the settings in the Internet Options
> ourselves and bring up the dialer (RAS API or WinInet) when a network connection
> error occurs. 
By all means. Let's do it incrementally: trivial workaround first and explore
more robust solution after that...

Comment 48

[Steve Meredith (gone)]

David Maynor wrote:
> IMO it might be better to dial on leaving the locally reachable zone 
> either by subnet, resloving a non-local name or leaving the local 
> computer.  If we can detect a net error quick enough then your 
> suggestion could work but DNS timeout's can sometimes take a while.

True, DNS timeout can take a long time.

The Internet Properties | Connections dialog in the control panel has three cases. 

1) Never dial a connection. Obvious.
2) Dial whenever a network connection is not present. How do we know? This is
where my dial on error suggestion comes from. Maybe there's an OS call to make
to determine this? If so, then we wouldn't have to wait for a network call to fail.
3) Always dial my default connection. Sounds like this is where you suggestion
of when to dial fit in. Always dial in those cases you list.

Comment 49

[Steve Meredith (gone)]

If we all agree that we should ignore the Internet Options in the control panel
because they are for Microsoft apps only, then we should have our own autodial
pref. If set, then we should call into the RAS APIs to initiate a dialup
connection. When? I don't think we want to check with RAS to see if we are still
connected before every network call. We would want to at least the first time a
connection outside the locally reachable zone is attempted, but then when after
that? On a network failure?

Comment 50

[tao]

Jud: does your team care about this? what's your personal taking on this? thx!

Comment 51

[Judson Valeski]

I don't recall doing anything explicit to get this to work in the 4.x tree.
IIRC, it "just worked." When we would open a socket, that would spark up the DUN
UI to establish a connection.

IMO, we should do what 4.x does in this case.

Comment 52

[Steve Meredith (gone)]

I recall from my testing (not 100% sure) that 4.x behaves the same way as
Mozilla. That is, it "just works" on 95 and 98, and only works under those
conditions described in comment #41 on the newer OSs (service must be running,
no network card.) 

Comment 53

[Matthias Versen [:Matti]]

*** Bug 146335 has been marked as a duplicate of this bug. ***

Comment 54

[tao]

Home users are more likely to hit this problem.

(from newsgroup feedbacks)

Subject:
Browser-General : No Connection
From:
[e-mail]
Date:
Sun, 2 Jun 2002 22:13:03 -0700 (PDT)
To:
[e-mail]
CC:
[e-mail]

	Browser Distribution Program Feedback Report
 
             
Email Address: 	[e-mail]
Version: 		6.2

Product: 		Browser-General
Language: 		English

Operating System: 	NotSelected  
RAM: 		>128

Severity/Importance: 		normal  
Issue Summary: 		No Connection

Detail: 
If I'm just on my desktop and then I click on my netscape 7 browser, the browser
opens up but it doesn not automatically dial my connection.  My connection
window doesn't even pop up.  I tried 6.2 and it did the same thing so I took it
off and tried 7 and now it is doing the same thing.  No connection.
I had 4.2 or something on my old computer with windows 98SE and it worked fine.
 I have a new computer with Windows XP. 

I hope you guys can help me fix this problem, I really want to use my netscape
browser instead of explorer.

Also please tell me exactly the proper place to go to give you feedback on
netscape 7.

Thanks

URL: 		

Reproductibility: 		Always
Steps to Reproduce: 
1. Double Click on Netscape browser icon from the desktop

Expected Results: 
The window opens, but I am not connected to the internet.

Additional Information: 

Comment 55

[Steve Meredith (gone)]

There was some question on what Windows Me does. I tested the autodial behavior
on Windows ME and it is the same as 98. That is, autodial works as expected.

Comment 56

[Steve Meredith (gone)]

Windows 2000 and XP(and probably NT) saves the values from Control Panel |
Internet Options | Connections | Dialup Settings in the registry as follows:

HKCU/software/microsoft/windows/currentversion/internet settings/enableautodial
to turn on autodial, and 

HKCU/software/microsoft/windows/currentversion/internet settings/NoNetAutodial
to indicate that it should dial only when there is no connection vs always autodial.

I think most users will expect these settings to be used by the client instead
of having our own pref and pref ui for it.

Comment 57

[tao]

Upgrading impact to ADT1. We need to fix this problem for dail up users.

Comment 58

[Steve Meredith (gone)]

Attachment: A patch to enable autodialing on Windows NT-based systems.

This patch adds autodial helper capabilities to Mozilla running on NT-based
systems. 

First, it tries to use the Windows RAS Autodial Service if it is running. To
get around the problem of that service not working if a network card is
installed, this patch adds the network address in question to the RAS autodial
database to force the service to dial when that address is unreachable. So if
an normal network connection fails, autodial will kick in. Or if a new machine
is shipped with both a network card and a modem, but the network card isn't
connected to anything, autodial will kick in.

If that service is not running, then it looks at the Control Panel | Internet
Options settings. If the autodial setting is set to "always" or "when a network
is not present", it uses the RAS API to dial the default connection on network
errors.

This patch should only affect Windows NT 4, 2000, and XP, and should not break
Windows 9x. Also, it shouldn't break the builds on Mac and Linux or interfere
with proper network operation on these systems. So far I have only been able to
test on Windows 2000 and XP Pro.

The code should autodial for all apps (browser, mail, aim, chatzilla, etc,)
whenever a network address is ureachable. It's going to require significant
scrutiny and testing as this is a high visibility area and the patch is almost
1200 lines.

All the code in nsAutodialWin.* is mine. Darin has graciously provided the
hooks into necko in the patch.

Comment 59

[Steve Meredith (gone)]

Do we need a way to disable this behavior for embedding?

Comment 60

[tao]

IMO, using a pref to disable it cleanly will give us a way out if we encounter
too many issues down the road.

Comment 61

[Steve Meredith (gone)]

The code needs a little work. I am adding a pref to turn it all off, I have a
fix for proxies, and there are a few problems integrating into necko. 

Comment 62

[Steve Meredith (gone)]

Attachment: A simpler but less powerful patch.

This version of the patch relies on the Autodial service, but is simpler. The
first patch causes mozilla to block until we finish dialing, and it has a few
problems. The worst case failure in this second patch is that it just won't
cause a dial. Also, it can be disabled by a pref.

The way this patch works is that it adds failed network addresses to the
autodial database when a network address can't be reached. This causes the
autodial service to dial when it can't reach that address.

The fix is not ideal in that you may get network error messaage the very first
time you use this feature instead of causing a dialup connection. Once at least
one address is in the autodial database, it should work reliably after that.

Comment 63

[Steve Meredith (gone)]

Attachment: Revised patch with pref to disable, disabled by default.

ADT would like to see the first version of the patch checked in. This patch is
the same as the first, but adds a pref to disable and fixes a couple problems. 


ADT wants the feature turned on in the trunk and off in the branch. The pref is
network.enable-autodial-helper.

Comment 64

[tao]

Comment on attachment 89092 [details] [diff] [review]
Revised patch with pref to disable, disabled by default.

Might I suggest that we change the pref name to
"network.autodial_helper.enabled"?
So the pref name is more consistent to the rest of the prefs used in Mozilla?

Comment 65

[Daniel Veditz [:dveditz]]

And also so there is a decent place to hang future auto-dial prefs if any should
come up (e.g. if we wanted to save Internet Config-like prefs independently from
the general windows values someday).

Comment 66

[Steve Meredith (gone)]

Attachment: Changed the name pref to network.autodial-helper.enabled

I found a bug in the way the autodial code is integrated into the network code.
In some cases, the network error message is displayed before the autodial
proceedure begins (it shouldn't). Darin wrote that part, and he's on vacation
for a month. I haven't been able to figure out a fix yet, so that bug exists in
this patch. 

I'm looking for help here. The way I see the problem is as follows:

In nsSocketTransport::OnStopLookup() (called from the DNS thread) mStatus gets
set to aStatus just before OnConnectionFailed() is called. In
OnConnectionFailed(), the mMonitor is released. At that point the transport
thread starts running again, continuing in doResolveHost(), where execution
went to the DNS thread. It sees that mStatus is not NS_OK, and returns the
mStatus error code. The state then changes to "Error" as
nsSocketTransport::Process() continues.

Comment 67

[Steve Meredith (gone)]

Attachment: Change to all.js to include the new pref.

Comment 68

[Steve Meredith (gone)]

Attachment: Patch with some threading issues fixed.

This version of the patch moves the pref upstream of some of the trickier parts
of the code to make it safer when disabled. 

For those reviewing the code: 

1) the basic thing that is happening is that on a network error, the transport
sends an event to the main thread and waits for it to complete. The event
causes the autodial system to dial. If a connection is made, the transport
retries the error. Otherwise, it processes the error normally. The result is
that mozilla will not be responsive until dialing is complete (or canceled by
the user pressing cancel.) This was determined to be OK for now, with the hope
of implementing an ansyncronous version later. 

2) the changes to dnsservice were made to remove the hostname from the hash
table on error before calling the transport's listener instead of after, since
the transport posts a retry from the listener and sometimes requests another
lookup of the hostname before it was removed from the hashtable. 

3) the pref is to disable the feature altogether. Even with the pref turned on,
you still need to configure the system for autodial via the Control Panel |
Internet Options | Connections

4) the code will not try to dial itself if the autodial service is running. It
will hint to the service that it should dial by adding the hostname to the
autodial database.

Comment 69

[tao]

Comment on attachment 89198 [details] [diff] [review]
Change to all.js to include the new pref.

r=tao

Comment 70

[Doug Turner (:dougt)]

since darin is out, I will be the sr= for this.

Comment 71

[Doug Turner (:dougt)]

nevermind... rpotts should be. 

Comment 72

[Doug Turner (:dougt)]

Comment on attachment 89198 [details] [diff] [review]
Change to all.js to include the new pref.

how about network.autodial-helper.windows.enabled?

Comment 73

[Doug Turner (:dougt)]

Comment on attachment 89457 [details] [diff] [review]
Patch with some threading issues fixed.

I am okay with most of this patch.  There are a couple of nits.  The only
biggie that I want changed is that I want this autodialer decoupled from necko.
 I don't know why we are not abstracting this OnConnectionFailed through some
interface.  Why not make an interface nsIConnectionHelper which can be called
when there is a connection failure?  In this way, other clients could register
for the same kind of event and do stuff.  I believe that this same problem came
up on another bug where at least one solution was to notify a client when a
connection failed.  Furthermore, if we did build they say, as an extension, we
could disable it by merely remove the dll.

Nits:

dont use hungarian notation.  This is completely unreadable: 
mlpfnRasGetAutodialAddress.  Please fix up all places where you use more than
one char to prefix a var name.	

nsSocketTransportService.h:
nsSocketTransportService.cpp:
	rename mAutodialHelperEnabled to mAutodialEnabled

nsISocketTransportService.idl:
	Rename autodialHelperEnabled to autodialEnabled

nsNativeConnectionHelper
	Make this a class.  Darin probably wrote this, but we agree to disagree
about class vs. struct:
		+struct nsNativeConnectionHelper

nsSocketTransport.cpp
	rename 'PRBool bTryNextAddress' to 'PRBool tryNextAddress'.  

	Please add a comment why you have to pass PR_FALSE in this case:

+	 // Retry? OnConnectionFailed() may exit and re-enter the monitor.
+	 if (aStatus != NS_BASE_STREAM_WOULD_BLOCK &&
OnConnectionFailed(PR_FALSE))
+	     mStatus = NS_OK;

nsDnsService.cpp

I have no idea what these changes are for.  can you please explain them?

Comment 74

[Steve Meredith (gone)]

I originally had "windows" as part of the pref name, and Darin preferred that I
take it out. What should I do?

The changes to the dnsservice are to address the following problem: 

DNS calls the transport listener when the lookup completes. At this point, the
DNS service still has hash table entries for the hostname it just looked up but
couldn't find. It removes them from the hash table when the listener returns.
But before the listener returns, the transport make another lookup call with the
same hostname because of the new retry code. DNS looks in the hashtable and
finds the entry, and returns an error right away. The change is to remove the
failed hostname entry from the DNS hashtable before the call to the listener
instead of after.

Comment 75

[Doug Turner (:dougt)]

leave the pref name the same.  I really don't care so much.  Just make a note in
the file that this is only supported on windows.

Comment 76

[Steve Meredith (gone)]

Attachment: Same patch with variable name improvments.

Comment 77

[Doug Turner (:dougt)]

Comment on attachment 89503 [details] [diff] [review]
Same patch with variable name improvments.

we can (may) punt for now on the autodial abstraction.	I think that the key
benefit for the near term would be that we could remove the entire feature by
removing a dll.  However, since the pref wraps the functionality, we could just
poke all.js if there were any problems discovered late(r) in the game.	

Lets get much wider testing on this before landing on the branch.  Contact asa
and hofmann and see if we can pull in as much QA as possible to back the heck
out of this.	
I believe that this is quite a risky change.  It makes xp changes to the socket
transport and especially the dns.  It would be nice to have a matrix of windows
platforms and dialer setups to verify against.	Maybe some of the old dialup qa
team can help.

I am also quite consider about how this intersects with embedders.  We should
let valeski know about this before landing on the branch.  Current embedders
may have to make sure that they disable this dialog if they have special RAS's
installed.

rpotts, double check me here.  shouldn't this be out of necko.	i mean, there
isn't any other place that could through a native UI in necko, yet this does. 
Furthermore, embedders may not want this at all.  Is disabling via a pref okay
for them?

Comment 78

[tao]

Copying smeredith's comments about QA coverage on a private email thread:

===== suggestion for QA coverage =======
The first thing we need to test is that we haven't broken the existing autodial
on Windows 95, 98, and ME, which already work with Mozilla.

Then we need to test that network error messages still work on Mac and Linux.
To test the actual feature, we need to test on NT4, Windows 2000, and Windows XP
Home and Pro.

We need to test machines with modems that can actually make ISP connections,
with and without network cards (since network cards affects the autodial service.)

We need to test that the correct connection is dialed and that the page loads
after the connection is made.

We need to test cancel of the dialup connection while it is dialing.

We need to test cancel the dialup then an immediate click on another link. No
redail should be initiated for 5 seconds after a user cancels. (This prevents a
whole sequence of dialup dialog when a connection is lost in the middle of a
page download.)

Start a big page download and disconnect the modem. The dialup dialog should
appear. If you let it connect, it should finish downloading the page. If you
cancel, it should not offer to redial again for that page.

We need to dial, browse a bit, hang up. The next network access should trigger a
dialup again.

We need to test when the Remote Access Auto Connection Manager, aka RasAuto, is
running and when it's not, as we won't try to bring up our own dialogs if the
service is running (to avoid a double set of dialogs.)

We need to test the pref to disable this feature.

We need to test when there are no RAS connections configured, when there is only
1 configured, when there is more than 1 configured and one is set as the
default, and when there is more than 1 configured and none are set as the default.
On Windows XP, we need to test when the default is configured for the current
user vs when it it configured for all users.

We need to test that dialup happens with all applications when the network is
accessed: browser, mail, composer, chat, etc.

We need to test that dialup doesn't happen when local data is loaded (local vs a
network access.)

Comment 79

[Steve Meredith (gone)]

The autodial code I wrote is all in one class, which doesn't care where it
lives. I've been relying on help from people with Mozilla expertise to figure
out where it best fits in with the existing code. If it's not in the right place
now, then we should get it there. However, I don't have enough experience with
the Mozilla code base to know where that place is. 

Comment 80

[rpotts (gone)]

Comment on attachment 89503 [details] [diff] [review]
Same patch with variable name improvments.

sr=[e-mail].

looks good to me.

Comment 81

[Paul Wyskoczka]

Benc, can you verify this when it lands on the trunk.  thx.

Comment 82

[Steve Meredith (gone)]

Attachment: Same changes diffed against today's trunck.

Comment 83

[rpotts (gone)]

hey doug,

you're right, this code should be abstracted so that it can be completely 
removed from necko (by embeddors).  It is very possible that an embeddor will 
NOT want this functionality -- and they shouldn't have to pay the code costs 
(even if the functionality can be disabled via a pref)...

do we want to open a new bug for the abstraction?  or stick with this bug?

-- rick

Comment 84

[Doug Turner (:dougt)]

> do we want to open a new bug for the abstraction?  or stick with this bug?

The answer to that is conditional.  Do we land it without this modularity now
and gain the benefit of testing while we work on breaking it out of necko? Or do
we not land it based on how it is hooked into necko?  

I think the answer to either of these questions is conditional on drivers and
(*dt).  If this isn't going to make the branch, there is no need to slam it into
the trunk.  

I told smeredith that I can do the work to abstract this, but I don't think it
is going to happen until monday.

Comment 85

[tao]

Checked in trunk for smeredith.

Comment 86

[tao]

seeking approval from adt and drivers.

Comment 87

[tao]

Comment on attachment 89598 [details] [diff] [review]
Same changes diffed against today's trunck.

inherit r/sr from previous patch.

Comment 88

[tao]

smeredith found a problem with this patch. I am disabling the feature via pref
and reopening the bug.

Comment 89

[selmer (gone)]

Please describe the problem with the patch...

Comment 90

[Steve Meredith (gone)]

As soon as it was checked in, I found another threading problem. If you press
the stop button before a DNS lookup completes, you get a hang. The network layer
calls out to the UI thread to do the autodial stuff, and it never used to do
that before. I have discovered a few problems like this. I fixed the ones I knew
about before checking in, but now I feel like there are other undiscovered cases
where this is going to be a problem. This doesn't feel like the best approach to
integrating the autodial stuff into Mozilla.

Comment 91

[Doug Turner (:dougt)]

A way to resolve these deadlocks is to make the autodialer threadsafe and only
call it from the socket transport thread.  Can the autodialer be threadsafe so
that it can be called from any thread?  Or, why shouldn't this autodial stuff
block the socket transport thread? 

Comment 92

[benc]

This sounds like it has a lot of risk. Why don't we make a special trunk build
available for Win32 users first?

Tao: I'm seeing that you did an all.js check-in to disable...

Steve: #58
Can you provide a screen snap shot on how the UI looks before and after you
create this suprious network address when none exists? I'm concerned about how
this will work in the future, when the user does decide to configure this interface.

Comment 93

[tao]

Doug is kind enough to offer himself to resolve the problem Steve is seeing. The
plan is to have the patch in tomorrow morning's trunk build with the autodial 
feature turned off by default. If all goes well, we will turn the feature on in the
trunk to get more QA coverage.

Comment 94

[Doug Turner (:dougt)]

just to be clear, I am going to advise, review, checkin, and cheer.  Steve is
going to do the real work: writing the code and testing.

Comment 95

[Steve Meredith (gone)]

Ben, I'm not sure what you are asking for a screen shot of. There will be no new
UI in Mozilla. The user can control autodial from the control panel | Internet
Options | Connections. Also, he configures dialup connections in Network
Connections. And the Autodial Service, officially the Remote Access Auto
Connection Manager, is configured via the control panel too. 

Comment 96

[scottputterman]

Lowering this to adt2 rtm.  

Comment 97

[Steve Meredith (gone)]

Attachment: Version of the patch which doesn't leave the transport thread.

This patch eliminates a set of current and potential bugs caused by switching
to the main thread to do the autodial stuff. It also includes a change to delay
loading the autodial DLLs until the last moment so they don't get loaded if
they aren't going to be used.

Comment 98

[rpotts (gone)]

Comment on attachment 89854 [details] [diff] [review]
Version of the patch which doesn't leave the transport thread.

sr=[e-mail]

Comment 99

[Doug Turner (:dougt)]

Comment on attachment 89854 [details] [diff] [review]
Version of the patch which doesn't leave the transport thread.

I am not sure about this change:

-     && (mOSVerInfo.dwMajorVersion >= 3))
+     && (mOSVerInfo.dwMajorVersion >= 4))
     {
assuming that there is is a good reason: r=dougt

lets get this tested on the trunk!

Comment 100

[Steve Meredith (gone)]

-     && (mOSVerInfo.dwMajorVersion >= 3))
+     && (mOSVerInfo.dwMajorVersion >= 4))

I made a mistake the first time. Only Windows NT 4 and greater are supported.

Comment 101

[benc]

smeridith: I'm looking for screen snapshots that show the changes the expected
behavior will have on the existing UI.

Comment 102

[tao]

benc: the proposed fix to this bug will NOT introduce any UI changes in the
browser. It only introduces a hidden pref in all.js. There is no UI in the
browser to modify this pref. Does this answer your question? You can refer to
#78 for how to test this feature.

Comment 103

[Doug Turner (:dougt)]

last patch does not apply cleanly to the trunk.  Steve, Tao, can you resolve this

Comment 104

[tao]

Attachment: same patch but should merge better.

resubmit the patch

Comment 105

[tao]

Comment on attachment 89871 [details] [diff] [review]
same patch but should merge better.

inherit r=dougt from previous patch

Comment 106

[Doug Turner (:dougt)]

xx
bash-2.05a$ cvs commit -m"Making autodial block occur on the socket transport
thread - no thread proxying.  r=me, sr=rpotts, patch by [e-mail].
 bug 93002" nsAutodialWin.cpp nsNativeConnectionHelper.cpp
nsNativeConnectionHelper.h nsSocketTransport.cpp nsSocketTransportService.cpp
Checking in nsAutodialWin.cpp;
/cvsroot/mozilla/netwerk/base/src/nsAutodialWin.cpp,v  <--  nsAutodialWin.cpp
new revision: 1.2; previous revision: 1.1
done
Checking in nsNativeConnectionHelper.cpp;
/cvsroot/mozilla/netwerk/base/src/nsNativeConnectionHelper.cpp,v  <-- 
nsNativeConnectionHelper.cpp
new revision: 1.2; previous revision: 1.1
done
Checking in nsNativeConnectionHelper.h;
/cvsroot/mozilla/netwerk/base/src/nsNativeConnectionHelper.h,v  <-- 
nsNativeConnectionHelper.h
new revision: 1.2; previous revision: 1.1
done
Checking in nsSocketTransport.cpp;
/cvsroot/mozilla/netwerk/base/src/nsSocketTransport.cpp,v  <-- 
nsSocketTransport.cpp
new revision: 1.244; previous revision: 1.243
done
Checking in nsSocketTransportService.cpp;
/cvsroot/mozilla/netwerk/base/src/nsSocketTransportService.cpp,v  <-- 
nsSocketTransportService.cpp
new revision: 1.68; previous revision: 1.67
done

Marking fixed.  we need this verified asap.  

Comment 107

[Steve Meredith (gone)]

To comment #78 (things to test,) I would add:

click on browser buttons while the dialer is dialing. 

Comment 108

[Steve Meredith (gone)]

The pref is to disable the feature altogether. Even with the pref turned on,
you still need to configure the OS for autodial via the Control Panel |
Internet Options | Connections. Set the dial option to "Dial whenever a network
connection is not present". Select one of the dialup connections and press the
"Set Default" button.

If the "Remote Access Auto Connection Manager" service is running, then it takes
precedence and the control panel options have no effect.

Comment 109

[Steve Meredith (gone)]

Attachment: Left out a minor detail.

I left this minor detail out of the original changes. It doesn't cause any
known bugs and I don't see that it should by looking at the code. However,
putting this code back in will restore the code to its original behavior when
disabled by the pref in case this has some side effect that I don't see right
now.

Comment 110

[scottputterman]

How close are you to being able to land this on the branch with the pref turned off?

Comment 111

[Steve Meredith (gone)]

For the branch, I will make and attach a patch combining patch 89198, patch
89598, patch 89854, and patch 90516. Working on that now.

Comment 112

[tao]

Hi, Steve: when this is in the branch, please add release note to 
http://bugzilla.mozilla.org/show_bug.cgi?id=155243. thx!

Comment 113

[Doug Turner (:dougt)]

Comment on attachment 90516 [details] [diff] [review]
Left out a minor detail.

how about something like this

Comment 114

[Doug Turner (:dougt)]

Attachment: details details...

this removes an unrequired test on !tryAgain.

Comment 115

[Steve Meredith (gone)]

Yes, yes, fine, fine... how bout that r=?

Comment 116

[[e-mail] (away - not reading bugmail)]

Steve,

Tao asked me to help you with the MOZILLA_1_0_BRANCH checkin. How far did you 
get in regards of combining patches 89198, 89598, 89854, and 90516?

Comment 117

[rpotts (gone)]

Comment on attachment 90634 [details] [diff] [review]
details details...

sr=[e-mail]

Comment 118

[Steve Meredith (gone)]

Attachment: Turn on the feature in the trunk using pref in all.js.

This is to enable the feature in the trunk so we can get some testing exposure.
It only changes the pref from false to true.

Comment 119

[tao]

Comment on attachment 90650 [details] [diff] [review]
Turn on the feature in the trunk using pref in all.js.

r=tao. Would anyone kindly give the sr=? thx!

Comment 120

[rpotts (gone)]

Comment on attachment 90650 [details] [diff] [review]
Turn on the feature in the trunk using pref in all.js.

sr=[e-mail]

Comment 121

[tao]

Comment on attachment 90634 [details] [diff] [review]
details details...

into the trunk

Comment 122

[tao]

Comment on attachment 90650 [details] [diff] [review]
Turn on the feature in the trunk using pref in all.js.

into the trunk

Comment 123

[Stephen Walker]

can this pref please be moved to winpref.js instead of all.js since it's 
windows only?

Comment 124

[Steve Meredith (gone)]

Attachment: The complete patch for the branch, with the pref set to disable.

The rolls up all the appropriate patches into one for application against the
branch. The pref is set to disable the feature.

Comment 125

[[e-mail] (away - not reading bugmail)]

Steve, Tao, here is the MOZILLA_1_0_BRANCH checkin protocol:

cvs tag -b MOZILLA_1_0_BRANCH nsAutodialWin.cpp nsAutodialWin.h 
nsNativeConnectionHelper.cpp nsNativeConnectionHelper.h (in directory 
D:\BUILD\mozilla.trunk\netwerk\base\src\)
T nsAutodialWin.cpp
T nsAutodialWin.h
T nsNativeConnectionHelper.cpp
T nsNativeConnectionHelper.h

cvs commit -m "93002: [distribution]Conn: Use dialup networking (.DUN) when 
launching\nmozilla. ..." Makefile.in makefile.win (in directory 
D:\BUILD\mozilla\netwerk\base\src\)
Checking in Makefile.in;
/cvsroot/mozilla/netwerk/base/src/Makefile.in,v  <--  Makefile.in
new revision: 1.66.10.3; previous revision: 1.66.10.2
done
Checking in makefile.win;
/cvsroot/mozilla/netwerk/base/src/makefile.win,v  <--  makefile.win
new revision: 1.63.10.2; previous revision: 1.63.10.1
done

cvs commit -m "93002: [distribution]Conn: Use dialup networking (.DUN) when 
launching\nmozilla. ..." nsISocketTransportService.idl (in directory 
D:\BUILD\mozilla\netwerk\base\public\)
Checking in nsISocketTransportService.idl;
/cvsroot/mozilla/netwerk/base/public/nsISocketTransportService.idl,v  <--  
nsISocketTransportService.idl
new revision: 1.23.36.2; previous revision: 1.23.36.1
done

cvs commit -m "93002: [distribution]Conn: Use dialup networking (.DUN) when 
launching\nmozilla. ..." nsIOService.cpp (in directory 
D:\BUILD\mozilla\netwerk\base\src\)
Checking in nsIOService.cpp;
/cvsroot/mozilla/netwerk/base/src/nsIOService.cpp,v  <--  nsIOService.cpp
new revision: 1.142.2.3; previous revision: 1.142.2.2
done

cvs commit -m "93002: [distribution]Conn: Use dialup networking (.DUN) when 
launching\nmozilla. ..." nsSocketTransport.cpp nsSocketTransport.h 
nsSocketTransportService.cpp nsSocketTransportService.h (in directory 
D:\BUILD\mozilla\netwerk\base\src\)
Checking in nsSocketTransport.cpp;
/cvsroot/mozilla/netwerk/base/src/nsSocketTransport.cpp,v  <--  
nsSocketTransport.cpp
new revision: 1.237.2.4; previous revision: 1.237.2.3
done

Checking in nsSocketTransport.h;
/cvsroot/mozilla/netwerk/base/src/nsSocketTransport.h,v  <--  
nsSocketTransport.h
new revision: 1.98.2.4; previous revision: 1.98.2.3
done

Checking in nsSocketTransportService.cpp;
/cvsroot/mozilla/netwerk/base/src/nsSocketTransportService.cpp,v  <--  
nsSocketTransportService.cpp
new revision: 1.63.16.3; previous revision: 1.63.16.2
done

Checking in nsSocketTransportService.h;
/cvsroot/mozilla/netwerk/base/src/nsSocketTransportService.h,v  <--  
nsSocketTransportService.h
new revision: 1.22.20.3; previous revision: 1.22.20.2
done

cvs commit -m "93002: [distribution]Conn: Use dialup networking (.DUN) when 
launching\nmozilla. ..." nsDnsService.cpp (in directory 
D:\BUILD\mozilla\netwerk\dns\src)
Checking in nsDnsService.cpp;
/cvsroot/mozilla/netwerk/dns/src/nsDnsService.cpp,v  <--  nsDnsService.cpp
new revision: 1.103.2.6; previous revision: 1.103.2.5
done

cvs commit -m "93002: [distribution]Conn: Use dialup networking (.DUN) when 
launching\nmozilla. ..." all.js (in directory 
D:\BUILD\mozilla\modules\libpref\src\init)
Checking in all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.367.2.25; previous revision: 3.367.2.24
done

Comment 126

[Steve Meredith (gone)]

Attachment: screenshot of the autodial service in the list of services

QA asked for some screenshots of UI and further description of how the feature
operates. It's going to vary somewhat between NT 4, 2000, and XP. But here is a
screenshot from XP of the autodial service mentioned throughout this bug
report.

Comment 127

[Steve Meredith (gone)]

Attachment: screenshot of the Control Panel | Internet Settings.

This is a screenshot of how you set up the control panel to turn on autodial if
you aren't using the service.

Comment 128

[Steve Meredith (gone)]

Attachment: screenshot of mozilla triggering an autodial

This is a screenshot of mozilla triggering an autodial. I just tried to open a
page and didn't have any network connection, and it started to make a
connection. The dialog will vary a little depending on your OS configuration.
For example, if you don't have any connection set as your default, you will be
prompted to choose from a list of your connections before it dials. Also, it
takes longer on NT4 from the time you click on a link before the OS figures out
it can't find the address so there is some delay before the autodial process
starts.

Comment 129

[Jaime Rodriguez, Jr.]

tao/steve:was this patch checked into the branch? if yes, pls replace
"mozilla1.0.1+" with the "fixed1.0.1" keyword.

Comment 130

[Kai Lahmann (is there, where MNG is)]

*** Bug 161899 has been marked as a duplicate of this bug. ***

Comment 131

[benc]

VERIFIED:
Commercial 2002-08-22-1.0, Win32.
I used a Windows XP system, and was able to configure it to dial on demand. I
also   confirmed that dial on demand does not fire when the LAN connection is
working.

I don't have the facilities to do the more extensive testing suggested by Steve,
but the general lack of bug reports in this area suggests that this works
sufficiently well, and does not break other operating systems.

I'll VERIFY trunk at some later date.

Comment 132

[idgreenwald]

When there is a lan connection you must distinguish between the SERVER and
CLIENTS.  If the sytem requesting dialup is the SERVER, dialup should be performed.

Comment 133

[benc]

VERIFIED/trunk:
Mozilla 1.1, Win2k.

Several followup bugs have been filed. New problems should go to new bugs from
this point on.

Comment 134

[benc]

(Time to get rid of 76111 as a dependency?)

Comment 135

[Sergey V. Udaltsov]

Not sure whether this is relevant or not - but I could not find any "dial - get
mail - send mail - hang up" single button solution. Modem users complain about
lacking this feature in Mozilla (they had it in Outlook).