connection refused does not give any graphical notification

RESOLVED WORKSFORME

Status

()

Core
Networking
P3
minor
RESOLVED WORKSFORME
18 years ago
16 years ago

People

(Reporter: namos, Assigned: neeti)

Tracking

({verifyme})

Trunk
Future
Sun
Solaris
verifyme
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS 5.8 sun4u; en-US; m17) Gecko/20000725
BuildID:

when the web server refuses connections, error message is only printed in the
command-line window that started mozilla, the browser sits there like nothing
happened

Reproducible: Always
Steps to Reproduce:
1.browse a host:port that refuses connections

Comment 1

18 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Using build from last week I do not see this kind of behaviour neither on NT or
Linux (tried http://bugzilla.mozilla.org with various ports). Is it only
happening with a Solaris build, or can you reproduce it with some other system?
Since I cannot reproduce this (i.e. I always get a dialog saying connection 
refused) I am marking this WORKSFORME. If you still see this with recent build, 
please update this bug report.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 4

17 years ago
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok

Comment 6

17 years ago
QA contact updated
QA Contact: gerardok → madhur

Comment 7

17 years ago
We've observed that this is not a problem on Linux, but it definitely occurs on
solaris.  Using truss, we found that if we attempt to connect to localhost, the
connect() system call returns ECONNREFUSED and the dialog box comes up.  However,
when we connect to a site over the network, connect() returns EINPROGRESS and
the behavior seen by the user is that the request is silently ignored.

Comment 8

17 years ago
Could be a Solaris bug, not event handling either way, though.  Not sure why 
this was originally assigned to me.  If this is reopened it should probably be 
on Networking.
Component: Event Handling → Networking
From Peter Fales:

The problem is still occurring with the 0.9.3.  (The build ID
is 2001080315, but I don't know how meaningful that is since I built
it myself).

I am reopening, and will assign to networking.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Sending to correct owners.
Assignee: joki → neeti
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: madhur → benc

Comment 11

17 years ago
+qawanted: I'm working on getting a Solaris workstation working. This can be
confirmed if someone else w/ Solaris sees it too.
Keywords: qawanted
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla0.9.7
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.9

Comment 12

16 years ago
if you want to reproduce this bug, don't use any proxy.
you may follow this way: use mozilla to visit a host that NOT running any webserver.
it seems nothing happened but ie will return an error page says "DNS error".
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.9 → Future

Comment 13

16 years ago
Strange! I lost the bug in mozilla 0.9.4!

I found there is already an error handler in docshell/base/nsWebShell.cpp.
If we enable the keyword server in [preferences]->[navigator]->[smart browsing]-
>[keyword], mozilla will redirect to keyword server after refused by current 
server. Otherwise, it'll prompt a dialog that says:"The connection to ... was 
refused.".

The only difference is some version of mozilla returns aStatus as 0x804B0005 
here(NS6 definitely returns this value), but actually it should be 0x804B000D. 
I don't know why.

As follows:
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsWebShell.cpp#838

nsresult nsWebShell::EndPageLoad(nsIWebProgress *aProgress,
                                 nsIChannel* channel,
                                 nsresult aStatus)
{
......
  //
  // If the page load failed, then deal with the error condition...
  // Errors are handled as follows:
  //   1. Send the URI to a keyword server (if enabled)
  //   2. If the error was DNS failure, then add www and .com to the URI
  //      (if appropriate).
  //   3. Throw an error dialog box...
  //
......
    //
    // First try sending the request to a keyword server (if enabled)...
    //
    if(aStatus == NS_ERROR_UNKNOWN_HOST ||
       aStatus == NS_ERROR_CONNECTION_REFUSED ||
       aStatus == NS_ERROR_NET_TIMEOUT)
    {
      PRBool keywordsEnabled = PR_FALSE;

      if(mPrefs) {
        rv = mPrefs->GetBoolPref("keyword.enabled", &keywordsEnabled);
        if (NS_FAILED(rv)) return rv;
      }
......
    //
    // Doc failed to load because we couldn't connect to the server.
    // throw a connection failure dialog
    //
    else if(aStatus == NS_ERROR_CONNECTION_REFUSED) {
......
      nsCOMPtr<nsIPrompt> prompter;
......
      prompter->Alert(nsnull, msg);
      nsTextFormatter::smprintf_free(msg);
    }
  return NS_OK;
}

Comment 14

16 years ago
Can we close this bug? I suggest to do so.

Comment 15

16 years ago
I'm not seeing the problem anymore.  I agree that it can be closed.
(Assignee)

Comment 16

16 years ago
wfm per comments above
Status: NEW → RESOLVED
Last Resolved: 18 years ago16 years ago
Resolution: --- → REMIND
(Assignee)

Comment 17

16 years ago
need to change status to wfm
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
(Assignee)

Comment 18

16 years ago
wfm
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 19

16 years ago
+verifyme - I have a Sun at a remote site, but if anyone wants to verify right
now, please do.
Keywords: qawanted → verifyme

Comment 20

16 years ago
reporter: can you verify this works now?

Comment 21

16 years ago
I'm not the original reporter, but I saw the bug in 0.9.3.  It's working for me now.
You need to log in before you can comment on or make changes to this bug.