Closed Bug 93002 (dial-on-demand) Opened 21 years ago Closed 20 years ago

[distribution]Conn: Auto-dial for NT-based Windows


(Core :: Networking, defect, P2)

Windows NT





(Reporter: susiewak, Assigned: smeredith)



(Whiteboard: [adt2 RTM] [ETA 06/24] correctness)


(8 files, 9 obsolete files)

49.90 KB, patch
: review+
Details | Diff | Splinter Review
13.43 KB, patch
: review+
Details | Diff | Splinter Review
607 bytes, patch
: review+
: superreview+
Details | Diff | Splinter Review
309 bytes, patch
: review+
: superreview+
Details | Diff | Splinter Review
55.95 KB, patch
Details | Diff | Splinter Review
69.23 KB, image/jpeg
45.00 KB, image/jpeg
32.87 KB, image/jpeg
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 

Expected Results:  Dial-up Networking is launched if user is offline when the 
browser is launched.
added cc's and made P1.
Severity: critical → normal
Keywords: nsbeta1
Priority: -- → P1
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.
Assignee: asa → neeti
Component: Browser-General → Networking
QA Contact: doronr → 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.
NEW: I'll take it under networking for investigation.
+ nsenterprise, clarified summary for Windows-only.
Ever confirmed: true
Keywords: nsenterprise
Summary: Dialer set up by ISP should launch when offline user launches N6.x → Conn: Use dialup networking (.DUN) when launching mozilla.
Target Milestone: --- → mozilla0.9.5
Removing nsenterprise nomination; adding nsBranch.
Keywords: nsenterprisensBranch
Blocks: 99142
Neeti/Gagan - No one has commented on this one in a while. Is this a stop ship?
If not, please mark as nsbranch-.
--> to gagan for reassigning it to the correct owner of this bug
Assignee: neeti → gagan
-->msanz for reassignment
Assignee: gagan → 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.
marking minus now, again
Keywords: nsbranchnsbranch-
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.
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.
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)

clearly not happening in 0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 104166
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 :)
Blocks: 107067
Keywords: nsbranch-
setting milestone, hope to get to it before then
Target Milestone: mozilla0.9.6 → mozilla1.0
taking it over from msanz (unless someone objects)
Assignee: msanz → tao

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.
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...
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.
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...
> What OS do you using? I'm using Windows 2000 Prof. 


> 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.

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.
>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 :-)
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 ]

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
note that it mentions ie5, which is of course not a part of w95osr0 (nor is ie4
but ...)

more later
Blocks: 108123
>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.

if that's the case, it should be in microsoft's relnotes
Depends on: 76111
reassign to new owner ->dbragg
Assignee: tao → dbragg
Priority: P1 → P2
Target Milestone: mozilla1.0 → mozilla1.0.1
I believe this will be post 0.9.8 feature freeze.  Setting ETA out beyond Moz 1.0.
Whiteboard: ETA: 4/22/01
Whiteboard: ETA: 4/22/01 → ETA: 4/22/02
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

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]).
IS this something that will be need for MachV?
No longer blocks: 107067
Whiteboard: ETA: 4/22/02
I don't believe so.
Blocks: 124418
this affects lots of dial-up users -> nsbeta1.
Keywords: nsbeta1
Whiteboard: correctness
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. 
Good point Gagan.  I would think this would belong to someone in Necko (but
that's just a guess).
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.
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 ;-)
are we keeping this bug focused on Windows? (I think in Mac OS, Open Transport
will bring up the dialer interactively...)
Currently, and for this particular bug, I'm interested in windows.  I'll take a
look at MacOS seperately.
Summary: Conn: Use dialup networking (.DUN) when launching mozilla. → [distribution]Conn: Use dialup networking (.DUN) when launching mozilla.
Searched MSDN and found these pages:

Remote Access Service (RAS) Overview

RAS AutoDial
  (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.

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.
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.
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.
new owner->smeredith
Assignee: dbragg → smeredith
Blocks: 144547
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...
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.)
> 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...
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.
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?
Jud: does your team care about this? what's your personal taking on this? thx!
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.
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.) 
Blocks: 143047
Keywords: nsbeta1nsbeta1+
Whiteboard: correctness → [adt2 RTM] [ETA 06/08] correctness
*** Bug 146335 has been marked as a duplicate of this bug. ***
Home users are more likely to hit this problem.

(from newsgroup feedbacks)

Browser-General : No Connection
Sun, 2 Jun 2002 22:13:03 -0700 (PDT)

	Browser Distribution Program Feedback Report
Email Address:
Version: 		6.2

Product: 		Browser-General
Language: 		English

Operating System: 	NotSelected  
RAM: 		>128

Severity/Importance: 		normal  
Issue Summary: 		No Connection

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.



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: 

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.
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.
Whiteboard: [adt2 RTM] [ETA 06/08] correctness → [adt2 RTM] [ETA 06/24] correctness
Upgrading impact to ADT1. We need to fix this problem for dail up users.
Whiteboard: [adt2 RTM] [ETA 06/24] correctness → [adt1 RTM] [ETA 06/24] correctness
This patch adds autodial helper capabilities to Mozilla running on NT-based

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

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.
Do we need a way to disable this behavior for embedding?
IMO, using a pref to disable it cleanly will give us a way out if we encounter
too many issues down the road.
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. 
Keywords: mozilla1.0.1
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.
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
Attachment #88383 - Attachment is obsolete: true
Attachment #88902 - Attachment is obsolete: true
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
So the pref name is more consistent to the rest of the prefs used in Mozilla?
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).
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.
Attachment #89092 - Attachment is obsolete: true
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.
Attachment #89195 - Attachment is obsolete: true
Comment on attachment 89198 [details] [diff] [review]
Change to all.js to include the new pref.

Attachment #89198 - Flags: review+
since darin is out, I will be the sr= for this.
nevermind... rpotts should be. 
Comment on attachment 89198 [details] [diff] [review]
Change to all.js to include the new pref.

how about
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.


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.	

	rename mAutodialHelperEnabled to mAutodialEnabled

	Rename autodialHelperEnabled to autodialEnabled

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

	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 &&
+	     mStatus = NS_OK;


I have no idea what these changes are for.  can you please explain them?
Attachment #89457 - Flags: needs-work+
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.
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.
Attachment #89457 - Attachment is obsolete: true
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

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?
Attachment #89503 - Flags: review+
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.)
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 on attachment 89503 [details] [diff] [review]
Same patch with variable name improvments.

looks good to me.
Attachment #89503 - Flags: superreview+
Benc, can you verify this when it lands on the trunk.  thx.
Attachment #89503 - Attachment is obsolete: true
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

> 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.

Checked in trunk for smeredith.
Closed: 20 years ago
Resolution: --- → FIXED
seeking approval from adt and drivers.
Keywords: adt1.0.1+, approval
Comment on attachment 89598 [details] [diff] [review]
Same changes diffed against today's trunck.

inherit r/sr from previous patch.
Attachment #89598 - Flags: superreview+
Attachment #89598 - Flags: review+
smeredith found a problem with this patch. I am disabling the feature via pref
and reopening the bug.
Resolution: FIXED → ---
Please describe the problem with the patch...
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.
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? 

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.
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.
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.
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. 
Lowering this to adt2 rtm.  
Whiteboard: [adt1 RTM] [ETA 06/24] correctness → [adt2 RTM] [ETA 06/24] correctness
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.
Attachment #89598 - Attachment is obsolete: true
Comment on attachment 89854 [details] [diff] [review]
Version of the patch which doesn't leave the transport thread.
Attachment #89854 - Flags: superreview+
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!
Attachment #89854 - Flags: superreview+ → review+
-     && (mOSVerInfo.dwMajorVersion >= 3))
+     && (mOSVerInfo.dwMajorVersion >= 4))

I made a mistake the first time. Only Windows NT 4 and greater are supported.
smeridith: I'm looking for screen snapshots that show the changes the expected
behavior will have on the existing UI.
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.
last patch does not apply cleanly to the trunk.  Steve, Tao, can you resolve this
resubmit the patch
Attachment #89854 - Attachment is obsolete: true
Comment on attachment 89871 [details] [diff] [review]
same patch but should merge better.

inherit r=dougt from previous patch
Attachment #89871 - Flags: review+
bash-2.05a$ cvs commit -m"Making autodial block occur on the socket transport
thread - no thread proxying.  r=me, sr=rpotts, patch by
 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
Checking in nsNativeConnectionHelper.cpp;
/cvsroot/mozilla/netwerk/base/src/nsNativeConnectionHelper.cpp,v  <-- 
new revision: 1.2; previous revision: 1.1
Checking in nsNativeConnectionHelper.h;
/cvsroot/mozilla/netwerk/base/src/nsNativeConnectionHelper.h,v  <-- 
new revision: 1.2; previous revision: 1.1
Checking in nsSocketTransport.cpp;
/cvsroot/mozilla/netwerk/base/src/nsSocketTransport.cpp,v  <-- 
new revision: 1.244; previous revision: 1.243
Checking in nsSocketTransportService.cpp;
/cvsroot/mozilla/netwerk/base/src/nsSocketTransportService.cpp,v  <-- 
new revision: 1.68; previous revision: 1.67

Marking fixed.  we need this verified asap.  
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
To comment #78 (things to test,) I would add:

click on browser buttons while the dialer is dialing. 
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.
Attachment #89854 - Attachment is obsolete: false
Attachment #89871 - Attachment is obsolete: true
Attachment #89598 - Attachment is obsolete: false
Attached patch Left out a minor detail. (obsolete) — Splinter Review
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
How close are you to being able to land this on the branch with the pref turned off?
For the branch, I will make and attach a patch combining patch 89198, patch
89598, patch 89854, and patch 90516. Working on that now.
Hi, Steve: when this is in the branch, please add release note to thx!
Comment on attachment 90516 [details] [diff] [review]
Left out a minor detail.

how about something like this
Attachment #90516 - Flags: needs-work+
this removes an unrequired test on !tryAgain.
Attachment #90516 - Attachment is obsolete: true
Yes, yes, fine, fine... how bout that r=?
Attachment #90634 - Flags: review+

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 on attachment 90634 [details] [diff] [review]
details details...
Attachment #90634 - Flags: superreview+
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.
Attachment #89198 - Attachment is obsolete: true
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!
Attachment #90650 - Flags: review+
Comment on attachment 90650 [details] [diff] [review]
Turn on the feature in the trunk using pref in all.js.
Attachment #90650 - Flags: superreview+
Comment on attachment 90634 [details] [diff] [review]
details details...

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

into the trunk
can this pref please be moved to winpref.js instead of all.js since it's 
windows only?
The rolls up all the appropriate patches into one for application against the
branch. The pref is set to disable the feature.
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 
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. ..." (in directory 
Checking in;
/cvsroot/mozilla/netwerk/base/src/,v  <--
new revision:; previous revision:
Checking in;
/cvsroot/mozilla/netwerk/base/src/,v  <--
new revision:; previous revision:

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

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

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

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

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

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

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

cvs commit -m "93002: [distribution]Conn: Use dialup networking (.DUN) when 
launching\nmozilla. ..." all.js (in directory 
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
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
This is a screenshot of how you set up the control panel to turn on autodial if
you aren't using the service.
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
tao/steve:was this patch checked into the branch? if yes, pls replace
"mozilla1.0.1+" with the "fixed1.0.1" keyword.
*** Bug 161899 has been marked as a duplicate of this bug. ***
Alias: dial-on-demand
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

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.
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.
Mozilla 1.1, Win2k.

Several followup bugs have been filed. New problems should go to new bugs from
this point on.
(Time to get rid of 76111 as a dependency?)
Summary: [distribution]Conn: Use dialup networking (.DUN) when launching mozilla. → [distribution]Conn: Auto-dial for NT-based Windows
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).
You need to log in before you can comment on or make changes to this bug.