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.

added cc's and made 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.

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.

Removing nsenterprise nomination; adding nsBranch.

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

-->msanz for reassignment

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

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

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

setting milestone, hope to get to it before then

taking it over from msanz (unless someone objects)

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.

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

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

>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

reassign to new owner ->dbragg

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

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

IS this something that will be need for MachV?

I don't believe so.

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

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.

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.

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

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

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

Home users are more likely to hit this problem. (from newsgroup feedbacks) Subject: Browser-General : No Connection From: histre@hotmail.com Date: Sun, 2 Jun 2002 22:13:03 -0700 (PDT) To: mcom.beta.feedback.browser-bdp@netscape.com CC: histre@hotmail.com Browser Distribution Program Feedback Report Email Address: histre@hotmail.com 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:

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.

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

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.

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.

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 network.enable-autodial-helper.

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?

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.

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 on attachment 89198 [details] [diff] [review] Change to all.js to include the new pref. r=tao

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 network.autodial-helper.windows.enabled?

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?

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.

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?

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. sr=rpotts@netscape.com. looks good to me.

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

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.

seeking approval from adt and drivers.

Comment on attachment 89598 [details] [diff] [review] Same changes diffed against today's trunck. inherit r/sr from previous patch.

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

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.

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 on attachment 89854 [details] [diff] [review] Version of the patch which doesn't leave the transport thread. sr=rpotts@netscape.com

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!

- && (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

Comment on attachment 89871 [details] [diff] [review] same patch but should merge better. inherit r=dougt from previous patch

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 smeredith@netscape.com. 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.

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.

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.

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 http://bugzilla.mozilla.org/show_bug.cgi?id=155243. thx!

Comment on attachment 90516 [details] [diff] [review] Left out a minor detail. how about something like this

this removes an unrequired test on !tryAgain.

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

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 on attachment 90634 [details] [diff] [review] details details... sr=rpotts@netscape.com

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 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 on attachment 90650 [details] [diff] [review] Turn on the feature in the trunk using pref in all.js. sr=rpotts@netscape.com

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

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.

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

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

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.

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.

VERIFIED/trunk: 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?)

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