Closed Bug 47617 Opened 24 years ago Closed 23 years ago

Connection to https needs to tell user to install PSM if w/o

Categories

(Core :: Networking: HTTP, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.8

People

(Reporter: mwitbrock, Assigned: darin.moz)

References

()

Details

(Keywords: helpwanted, top100)

Attachments

(1 file, 3 obsolete files)

The login for datek services doesn't work. Generally this looks like an old
fashioned auth login.

Build 2000080322 Mozilla M18 Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18)
Gecko/20000803

(Click on the investment login link)

This has never worked in Mozilla, but Mozilla seems to be getting good enough that
I want to switch to it full time, so I need this site to work.
Basic auth issues go to Networking.
Assignee: mstoltz → gagan
Component: Security: General → Networking
QA Contact: czhang → tever
stiletto@mediaone.net - also affects Mozilla/5.0 (X11; U; Linux 2.2.16 i686;
en-US; m18) Gecko/20000811.  M17 build gives error window (Unable to contact
server investment.datek.com).  Current nightly build 11 Aug 2000 dumps core. 
Both cases report on stdout just before crash:

JavaScript error: 
http://www.datek.com/investcenter/login.html line 54

And from the page source (login.html):

if (type=="invest") {
    document.location.href="https://investment.datek.com";   <----line 54
}
If one sucessfully installs PSM, under the recent builds Aug 12 2000 for 
example, the popup works fine now. I guess this means it's more of a cosmetic 
bug, since what seems to be missing is some indication that the user should 
install PSM.
CCing ddrinan@netscape.com - the guy who owns the Crpyto module.

Gerv
confirming.. changing status.. sounds good??
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Cannot log into www.datek.com investment site (authentication popup doesn't appear, connection refused) → Connection to https needs to tell user to install PSM if w/o
If at all something like this has to be implemented it would be in docshell 
area. 
Assignee: gagan → adamlock
Component: Networking → Embedding: Docshell
QA Contact: tever → adamlock
Shouldn't the https protocol handler use the prompt service to notify the user 
when the PSM is not installed?
See example from the ftp protocol handler:

http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/ftp/src/nsFtpConnection
Thread.cpp#971

The https protocol can prompt the user in a similar way to tell them to 
install the PSM. You could probably even ask them if they want to be taken to 
the PSM site right away in which case, open an http channel to the appropriate 
URL.
Component: Embedding: Docshell → Networking
Reassigning back to network module
Assignee: adamlock → gagan
QA Contact: adamlock → tever
no this should happen in a more common place like docshell. ->rpotts.
Assignee: gagan → rpotts
Why should the DocShell need to know about https?  Or how/where to install PSM.

THis should be done by the https handler - or a dummy https handler if the 
"real" https handler is only installed with PSM

-> networking
Assignee: rpotts → gagan
The last attachment was a mistake... that stack trace was meant for a different
bug... sorry for the ** spam **
*** Bug 45952 has been marked as a duplicate of this bug. ***
Copying mostfreq keyword from dup.
Keywords: mostfreq
Keywords: top100
*** Bug 60294 has been marked as a duplicate of this bug. ***
Platform/OS=All/All per dupe (bug 45952).
OS: Windows NT → All
Hardware: PC → All
*** Bug 60275 has been marked as a duplicate of this bug. ***
Blocks: 61687
http bugs to "Networking::HTTP"
Assignee: gagan → darin
Component: Networking → Networking: HTTP
Target Milestone: --- → M19
Is this bug still relevant now that PSM is built in?

Gerv
Yes, although the rate of duplicates will probably be about 25% of what it was 
before.  There have been several bugs recently where the built-in PSM didn't 
work, so many users are still seeing this error message and getting confused.
Target Milestone: --- → Future
Keywords: mozilla0.9.1
Jesse: what error message? This bug is about there _not_ being an error message.

Gerv
darin: Can we close this out, now that PSM is built in?

Gerv
No. Since PSM is an extension, it is possible (and legitimate) to build Mozilla 
without it, and Mozilla must not behave badly if PSM is not included.
> Jesse: what error message? This bug is about there _not_ being an error 
> message.

At one point, trying to go to an https:// site without PSM resulted in 
a "connection refused" message.  I'm not sure if that still happens.
I get "Connection refused" with Mozilla-0.8.1 on RedHat 6.2.
BTW, I do have PSM installed, but I still get "connection refused" if the PSM
process dies for some reason.
Is this still a problem with the latest builds (using PSM2)?

I seem to be able to go to this site, click on cancel in the basic-auth password
dialog(since I don't have an account), and I get back an error page which is
delivered via HTTPS.
Reading this, I have the feeling this could be related to my recent trouble
getting https to work. I'm using "Navigator only + SSL" installations and
haven't been able to get https to work with neither 0.9.3 or 0.9.4. After I had
tried those I've went back to 0.9.2 without https problems.

In 0.9.3 and 0.9.4, clicking on a https URL has been doing nothing at all. No
error message, no warning, no sign of activity, nothing. I've just reinstalled
Mozilla 0.9.4 (RH 7x RPMS) from scratch and got rid of all old config files, and
suddenly https URLs now work for me. I hope it will stay like that.
blizzard: any thoughts on michael's comments regarding the mozilla RPMs?
https worked on my windows32 url functional test.

I haven't done linux yet.
*** Bug 101786 has been marked as a duplicate of this bug. ***
Can protocol handlers like https: and foo: be pluged in easily enough via an XPI
install, or does the core browser need intrinsic knowledge of what protocols
exsist? I ask because the correct UI reaction depends on whether https is
special or not.
https is built in... it is not a separate component.  the backend, PSM2, is a
separate component.  however, PSM2 should always be present in the nightly
mozilla builds.  this bug was more of an issue back in the PSM1 days when
mozilla nightly builds did not include PSM1 by default.
marking WONTFIX (see above comments)
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Errr... are you saying if PSM isn't selected for install Mozilla should still be
able to load https pages? Cause it doesn't. You type in https://foo and nothing
happens. No 'https is an unknown protocol', no 'connection refused', no 'go
install PSM'. That's definatly not a WONTFIX problem...
PSM is by default part of mozilla installations these days.  it is not an
optional component.  however, when this bug was filed, PSM was an optional
component that was not distributed with mozilla b/c back then, crypto code
wasn't open source.
I know on Debian, mozilla-psm is a separate package.  It is quite
possible for someone to not install psm and therefore not recieve any
error message.

I could be wrong about that though.
darin: please see the following bugs.  All these bugs are resolved invalid.  All
are post recent, where PSM2 is included in the nightlies/milestones.

Many people do a custom install and uncheck PSM in the install options because
they don't know what it does.  Until it is impossible to uncheck PSM in the
installer, this bug should not be WONTFIX.  Please reconsider.

Bug 101101
Bug 96288
Bug 94357
Bug 95435
Bug 92842
Bug 101076
Bug 87647
A few more bugs that are invalid because the reporter didn't have PSM are below
(there's more too I'm sure.  I know I've marked a few more of them invalid in
the last couple of weeks).

Also, Duncan Findlay is right in saying there is a separate RPM for the PSM
module.  It is very possible for people to not have PSM installed.

Anyway....  the bugs go on:

bug 84550
bug 84660
bug 95543
bug 92283
bug 77511
Darin Fisher wrote:
> [PSM] is not an optional component.  however, when this bug was filed,
> PSM was an optional component

No, PSM is most definatly optional. And it should remain so, incase the
flexibility is ever desired (or required by a countries law).

I think you're looking at a commercial build, where it isn't optional.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
you are correct... i was looking at a commercial build.  thank you everyone for
the feedback.

targeting mozilla 0.9.6
Severity: critical → major
Target Milestone: Future → mozilla0.9.6
The suggestion of giving the "unregistered protocol" is a good one, but we have
lots of related problems here (it only works in the location box, it only works
w/ URLs that use "CISS" (have ://)).

I think there is a generic "fix errors for non-existent schemes everywhere" bug,
if not, I'll create one.
See also bug 86486, "URL: Invalid protocols in HREF links fail silently".
of all the bugs... in all the world.. nominating this one.
Keywords: mozilla1.0
When I type asa://foo.bar I get a "asa is not a registered protocol" alert. The
same thing should happen if I type in https:// without PSM. This bug is causing
a lot of noise in Bugzilla and wasting a lot of testing time. 
Status: REOPENED → NEW
well, the https protocol handler is not registered by PSM, so we have to handle
it a little differently... however, if we could manage to not register a https
protocol handler when PSM is not present, that would do it.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
*** Bug 105106 has been marked as a duplicate of this bug. ***
Hi,

I'm suffering from the symptom of getting no response at all for links to
https:// pages. The status line shows "Document: Done (0.023 secs)", but there
is no page fetched. This is with Mozilla 0.9.5 binary distribution on Solaris.
(Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.5))

Mozilla 0.9.4 works fine in this area. How do I tell whether I've got PSM, and
how to install it if I haven't?
Scott Davis:
You have PSM if you have the SSL Tab: 
Edit/Prefences/Prvacy&Security/ssl

If you want PSM you must use a PSM enabled build or build with --enable-crypto (?)
Thanks Matthias.

The SSL tab is not in the Solaris 2.8 build of Mozilla 0.9.5.

I have filed bug 106401 to observe that. It does highlight the above discussion
that PSM is an option, not core, and so Moxzilla needs to recognise its absence.

I don't think I have the necessesary infrastructure set up to make a build from
source myself, or I'd contribute a properly built one.
a simple solution to this bug might be to make nsHttpHandler::NewURI return
NS_ERROR_UNKNOWN_PROTOCOL if the nsSocketProviderService doesn't have a
registered nsISocketProvider for the "ssl" socket type.  then, docshell would
end up alerting the user to the fact that the https protocol is unknown.  this
would be a good step in the right direction.  of course, it would be nice to
instruct the user to go and download PSM, but i'd really like to avoid adding
specialized alert code to necko.
Sounds like a good-enough-for-1.0 fix to me, Darin.

Remember, the only people without PSM are those that did a custom install. At
least if they get a vague message, they'll probably remember, 'oh yeah, I
deselected that security thing in the install.'

Unfortunatly, it's not well know you can just jump on the FTP site, click the
XPI, and you're set up for https. Maybe the custom install process should
briefly mention you can do that if you want to add components later? Or a link
on the release download pages, saying "Add components to a current install" or
whatever.

I think the log term fix is a similar thing to how plugins work. Click a foo:bar
link, and you get a dialog that will let you search for foo protocol plugins.
Right off the bat, chatzilla and psm could be added post-install with that, the
first time a user needs them. The dialog would also let you hook it up to an
external protocol... things like telnet: could be hooked up to 'xterm -e telnet
%h %p'.
the only problem with this solution is that it'll incur an extra memcmp for each
and every call to nsHttpHandler::NewURI ... that's unfortunate.  it would be
better to somehow not effect such a critical path.
Attached patch v1.0 patch (obsolete) — — Splinter Review
this patch adds code to nsWebShell::EndPageLoad to alert the user to a
NS_ERROR_UNKNOWN_SOCKET_TYPE error.  this corresponds to PSM not being
installed.

i thought about adding a comment about PSM as a hint in the alert, but i
instead decided to leave the alert message generic.
Comment on attachment 60884 [details] [diff] [review]
v1.0 patch

r=gagan
Attachment #60884 - Flags: review+
Status: NEW → ASSIGNED
Keywords: patch
Whiteboard: [patch needs sr=]
Comment on attachment 60884 [details] [diff] [review]
v1.0 patch

sr=mscott
Attachment #60884 - Flags: superreview+
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
"Unknown socket type.  Loading aborted"

Your generic error message is fairly unhelpful. If the error is
triggered because psm is missing then it should say that. (as the summary
of this bug specifies)


reopening this and cc'ing rudman who i believe has something to do with
creating user readable error messages.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
yeah, i see your point... but at least it is an improvement from users seeing a
blank page ;-)

perhaps webshell can check the URL scheme and then add a message that suggests
this error could be caused by not having PSM installed.  something like:

 "Unknown socket type (perhaps PSM is not installed).  Loading aborted."
*** Bug 116474 has been marked as a duplicate of this bug. ***
*** Bug 116687 has been marked as a duplicate of this bug. ***
It boggles me that this one hasn't made the most frequent list yet - presumably
bugs are getting marked INVALID rather than as dupes : just in the last 72
hours, we have the two dupes above, bug 116430 and bug 116619.  It comes up in
the newsgroups about 1-2 times a week.
*** Bug 101076 has been marked as a duplicate of this bug. ***
*** Bug 116619 has been marked as a duplicate of this bug. ***
*** Bug 116430 has been marked as a duplicate of this bug. ***
*** Bug 106193 has been marked as a duplicate of this bug. ***
*** Bug 116884 has been marked as a duplicate of this bug. ***
*** Bug 117062 has been marked as a duplicate of this bug. ***
*** Bug 117113 has been marked as a duplicate of this bug. ***
*** Bug 117195 has been marked as a duplicate of this bug. ***
*** Bug 117217 has been marked as a duplicate of this bug. ***
*** Bug 117272 has been marked as a duplicate of this bug. ***
*** Bug 117480 has been marked as a duplicate of this bug. ***
Ideally we'd have:
|
| This document cannot be displayed properly unless you install the Personal
| Security Manager. Would you like to install it now?
|
Without implementing all the complicated effects of the `Install' button in 
such an alert, however, even the following would be an improvement:
|
| This document cannot be displayed properly unless you install the Personal
| Security Manager (PSM). Download and install PSM and try again, or contact
| your system administrator.
|
Anyone want to make a patch for that? Should be fairly simple, unless (as I 
understand the previous patch) that abortful message comes up no matter whether 
it's https:// or asa:// or whatever://, in which case we need a dummy protocol 
handler to special-case https:// and put up that message each time. (Probably 
this should be another of the cases handled by bug 28586, once that's 
implemented.)

P.S.: I know it probably made perfect sense to the programmers involved at the 
time, but for future reference (and this is to everyone), please don't ever 
make/r=/sr= a patch which introduces a UI string with `abort' in it. The same 
applies to `kill', `execute', `illegal', `invalid', or `violation'. If you need 
help coming up with a message which won't cause offense or worse, just ask.
Keywords: patchhelpwanted
Whiteboard: [patch needs sr=]
Matthew Thomas (mpt) wrote:

> Ideally we'd have:
> |
> | This document cannot be displayed properly unless you install the Personal
> | Security Manager. Would you like to install it now?
> |
> Without implementing all the complicated effects of the `Install' button in 
> such an alert, however, even the following would be an improvement:
> |
> | This document cannot be displayed properly unless you install the Personal
> | Security Manager (PSM). Download and install PSM and try again, or contact
> | your system administrator.

I think that there really ought to be a warning during installation, too. That
is, if you omit the PSM, a message box should alert you that you won't be able
to access HTTPS pages, and explain what that means in layman's terms.

I'm not a layman, but I omitted it (all I want is a browser, not all these
steenking optional components), not knowing that it was a required component for
any useful browsing.

Why is it optional, in any event? What use is a browser without HTTPS?

-- 
David W. Fenton  dfenton@bway.net
David Fenton Associates
> Ideally we'd have [...] "unless you install the Personal Security Manager."

Why is https special? Did Mozilla screw up it's architechture that badly already
that arbitrary plugins can't be done for such things? The fix for this seems to
me to be to get PSM to use the normal code paths, or create them if they don't
exsist.  Then if we want a special switch { case https: }, that might be
temporarily acceptable. But as we're not an end user browser, it shouldn't be
necessary.
I have to concur with David Fenton. I'm a programmer, and do have a clue about
what I'm doing. And I tend to omit all the optional stuff when I'm installing a
software package. Which is what I did - I use other programs for email, irc and
usenet, so didn't install the optional stuff (save for the talkback app) when I
installed Mozilla. 

There really should be a notice of some kind that appears when you uncheck PSM
during installation, simply because there's no way to know that HTTPS etc. won't
work without it. Most people just assume that the basic browser will handle
HTTPS, as did David and I both.

Jill Mitchell
I tend to agree with comment 77 and 78; I don't see why https:// needs to be
separate from the usual http/ftp/irc stuff that comes with milestone and nightly
builds. I do, however, see how some embeddors would want to not include it, but
I definitely think mozilla.org should integrate it tighter into its browser.
(While still keeping it standalone and separated enough that it /can/ be disabled.)
I guess this is another 'me too' comment. I didn't install PSM initially because
I too do not like most optional software. I assumed that PSM handled such things
as saving user IDs and passwords for web sites. I didn't want this feature so I
didn't install PSM. Only to find out later that PSM is required. HTTPS is fairly
critical to such web activities as online retail, online banking, online stock
trading, etc... These are standard activities on the net now and as such should
be viewed as a critical and necessary part of any browser. If PSM is needed for
HTTPS, then it should not be an optional install.
The three people not installing PSM because they didn't know what it did is a
case for better documentation, not uncomponentizing Mozilla. Release notes need
to mention what PSM is and does, and the installer could use a better desription
to offset the stupid name of the module.
I concur with the recent comments saying that HTTPS is a behavior expected
supported by default in any modern web browser -- needing to install an optional
component to get HTTPS support is a surprise.
Attachment #16380 - Attachment description: New stack trace with mElderQueue block commented out. → nothing to see here (this is for some other bug)
Attachment #16380 - Attachment is obsolete: true
Ok ie just killed my comment. needless to say i'm not happy. This comment will 
not be polite because i'm steamed.

Hwaara: you're wrong.  PSM is no different from IRC. both are individually 
wrapped.  Even in the redhat distribution.

MPT you're suggestion is mean.

preface: there's current a bunch of bugs about the plugin downloader plugin aka 
the null plugin.
one bug for its obscure error message
one bug for the fact that it says Mozilla or Netscape
one bug for each of the various platforms that don't have the plugin at all
and a bug to obsolete them all, a (XP) rewrite that works everywhere (XBL based)
[LotR reference]

mpt+Annoying someones: PSM doesn't build on at least: BeOS, QNX, mach-o.
Suggestions which would annoy BeOS and Mac OSX users: change the installer to 
tell them to install psm or else they won't get https support.

Reason: They're ui conscious and will get very upset when they can't find the 
checkbox for this PSM thing.

[QNX users are probably also UI conscious, but they aren't anywhere near as 
vocal when it comes to UI as Mac/exMac users]

jmd: One of the reasons i'm opposed to explicit PSM references is that i'd like 
to write a JSS based https impl for mozilla. why? because i can. BeOS, QNX, and 
mach-o all have access to a JRE (personal java, ibm microjava, apple java).  
JSS is mozilla.org (well netscape.com)'s java based security implementation.

with it, I could implement just https support. Not s/mime, not personal 
certificates, and not certificate management (all of which are part of the 
heavyweight psm).  I could then plug this in for Mozilla on any platform w/ 
Java support including the few that can't build psm.

And why might i not want psm? it's HEAVY.  QNX4 can be shipped on a single 
floppy. Mozilla w/o xul as measured by layout+content is 2 [1.44] floppies.  
Assuming QNX4 didn't include Photon, Photon would require 1 more floppy.

QSSL the makers of QNX have created a moz_server, which i could use w/ voyager 
so I wouldn't need the mozilla gui (somewhat heavy). Voyager is a plugable web 
browser, it has two pieces, the front end, and the backend. There are three 
backends available at this time: Voyager, Opera, Mozilla.

So it would take me 2 [2.88] floppy disks to have a working mozilla for an 
embedded system where i didn't need PSM.  If you force me to include PSM (when 
it works, until then you'd be forcing me to not build mozilla) then I'd need an 
extra disk.

This is a skewed size sample: 1,597,521 pipnss.dll, it won't fit on your 
average floppy (yes it'd take me 4 floppies if i was using 1.44mb ones in my 
scenario above, but who cares, this stupid file wouldn't fit.

dlr: oh cut it out. I blame you for the fact that my old much more polite post 
was eaten by ie. (it did this as a favour to me, the page had changed, so 
obviously my comment wasn't important). gopher was an essential part of the web 
browser and we didn't ship w/ support for it for ages.
*** Bug 117576 has been marked as a duplicate of this bug. ***
> jmd: One of the reasons i'm opposed to explicit PSM references is that i'd
> like to write a JSS based https impl for mozilla. why? because i can.

Then we're in agreement. I too would like to see a competing plugin which gives
mozilla ssl support.

Mozilla being open source, structed as it is with XUL, XPI application install,
plugins, etc, could have been the perfect PLATFORM with truckloads of 3rd party
developers doing neat things like Chatzilla, or a napster client, or new mail
clients, or any number of other things. But, as I understand it from previous
discussion here, https: is going down a differant code path then foo: does, so
obviously somewhere someone screwed up the platform idea.

I've also filed a bug to get Composer split off, so competing HTML editors can
exsist. (maybe just a very basic text editor with ctrl+e bound to end the
current element... no 5 differant WYSIWYG views). Also, the base install needs
to stop having knowledge of Java. Why is my tasks->tools->java console greyed
out. Why do I have a pref to turn Java on and off. Mozilla should have no idea a
language called Java exsists, until I install an x-java-vm handler.

Mozilla being "not for end users" is all the more reason to compontentize it
like this. Netscape is more then welcome to include Java, and "Composer" as the
HTML editor.

I think Mozilla is doomed to be a 2nd rate browser on its current path, when it
could be a 1st rate platform, with 1st rate applications running on it. I don't
get why such an obvious idea is being ignored, when most of the elements have
been there. Is it too late?
*** Bug 117581 has been marked as a duplicate of this bug. ***
*** Bug 117581 has been marked as a duplicate of this bug. ***
*** Bug 117588 has been marked as a duplicate of this bug. ***
Please don't SPAM bugs. 
This is a bug database and not a newsgroup (use the newsgroups to discuss stuff
like this)

An installer RFE is bug 116703
David:
*   A warning on installation is irrelevant to this bug. Please read it.
*   Your .signature is irrelevant to this bug, or any bug. Please don't.
*   HTTPS is optional because (as Timeless took a very long time to say) we
    want Mozilla to be distributable in places where HTTPS is unimplemented
    (e.g. QNX), unnecessary (e.g. some kiosks), or illegal (e.g. Iran).
HĂĄkan:
*   How tightly PSM is integrated into ftp.mozilla.org builds is irrelevant to
    this bug. See above.
Jeremy:
*   Rearchitecting the world, or turning Mozilla from a useful Web browser into
    a `platform' which is so modular that no-one can be bothered using it, is
    irrelevant to this bug. Please file it elsewhere.
*   Don't be silly, of course Mozilla is for end users. The binaries on
    ftp.mozilla.org may not be intended as such, but they're trivial in
    popularity compared with the builds made by other Mozilla distributors. And
    if *every one* of those distributors has to fix (or suffer from) useless
    error messages like this one, then Mozilla is unnecessarily difficult to
    distribute, so the Mozilla Organization is not doing its job properly.
Timeless, Jeremy:
*   It is indeed possible, in theory, for there to be some HTTPS implementor
    other than PSM. And if anyone ever implements one, the message can be
    changed. However, users are more interested in reality than theory, and
    right now, `Download and install PSM' is much more useful than either
    `Download and install, um, some random thing that implements HTTPS' *or*
    `Elbow error: Loading amputated'. So, can someone fix the wording? Please?
>   HTTPS is optional because (as Timeless took a very long time to say) we
    want Mozilla to be distributable in places where HTTPS is unimplemented
    (e.g. QNX), unnecessary (e.g. some kiosks), or illegal (e.g. Iran).

But on the front page it says that it can't be distributed in places like 
Iran, so why bother trying to make it so it can if it can't by federal law? 
Anyway, it would be legal if there was an option to disable it, surely?
On 2002-01-01 06:44, mpt@mozilla.org.uk wrote:

> David:
> *   A warning on installation is irrelevant to this bug. Please read it.

I don't think it's irrelevant at all. I don't think it's not really a bug so
much as a usability issue, as silent failure of https requests is not very
useful to end users experiencing the problem. And those end users might very
well never experience the problem if they understand during installation what
the repercussions of leaving out various components might be.

In other words, I wouldn't be here in this bug and wouldn't even know about it
if the installation process had indicated that PSM was required for HTTPS. I
never would have wasted the afternoon uninstalling and reinstalling in an effort
to figure out why Hotmail had stopped working when I upgraded form 0.9.3 to 0.9.6.

Ideally, I'd like to be able to install HTPPS support while omitting all the
stupid password management features, of which I have absolutely no need (and
providing it allows lots of people the opportunity to compromise their own
safety, but that battle is long lost, so I'll not prolong it). From my point of
view HTTPS should be base-level browser functionality (even if implemented as
some kind of installable module), while the password management and all the
garbage that goes along with it are bells and whistles that are convenient for
some people and a waste of HDD space for others.

> *   Your .signature is irrelevant to this bug, or any bug. Please don't.

Pardon me, but in reading all the comments, I have a hard time telling who said
what, and that's why I sign my messages. So, I'm trying to make it clear who is
saying what.

> *   HTTPS is optional because (as Timeless took a very long time to say) we
>     want Mozilla to be distributable in places where HTTPS is unimplemented
>     (e.g. QNX), unnecessary (e.g. some kiosks), or illegal (e.g. Iran).

OK, fine.

The installation program for any particular implementation of a product built on
Mozilla should not require the end user to understand this. The installation
program should either not offer the option to omit the component or it should
attempt to explain the repercussions of not doing so.

As long as Mozilla.org is producing a binary installation program, that
installation program should be as user-friendly as possible and should hide the
complexities of the underlying architecture from end users.

I just cannot comprehend why there would be any resistance to the thought of
making the install routine more user-friendly, as it would have prevented some
portion of the people reporting this "bug" from having the problem in the first
place. If you want people to try Mozilla, this should be a no-brainer. If not,
then, well, why the hell is Mozilla providing a binary with an installer in the
first place?

-- 
David W. Fenton
dfenton@bway.net
*** Bug 118444 has been marked as a duplicate of this bug. ***
0.9.7 is out -> 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 118459 has been marked as a duplicate of this bug. ***
*** Bug 118529 has been marked as a duplicate of this bug. ***
*** Bug 118581 has been marked as a duplicate of this bug. ***
*** Bug 118634 has been marked as a duplicate of this bug. ***
*** Bug 118919 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0mozilla0.9.8
Attached patch v1.1 patch (obsolete) — — Splinter Review
this patch revises the previous wording from:

  Unknown socket type.	Loading aborted.

to:

  Unknown socket type.	Unable to load the requested page.  This error
  typically occurs when the Personal Security Manager component has not been
  installed.

IMO this is sufficient enough to guide users to remember that they did not
install the Personal Security Manager (as it is worded in the installer).

I've also included some other cleanup in the file.
Attachment #60884 - Attachment is obsolete: true
does anyone object to this latest patch?
I'm no usabilty expert but for Mozilla purposes this shouold be sufficient
(where "Mozilla purposes" means cutting down on worthless bug reports and the
associated wasting of triage time and effort). Can we get this in before the
freeze in  a few days?
Blocks: 115520
darin: i do. Please make explicit mention of https. And bare in mind my 
comments about JSS, they are reasonable, QSSL's QNX Mozilla does have java 
support thanks to IBM MicroJava, so i'm going to try to get people to work on a 
jss based impl of https.

[timeless@viper timeless]$ lynx https://sourceforge.net
Alert!: This client does not contain support for HTTPS URLs.

[timeless@viper timeless]$ lynx shttp://sourceforge.net
Alert!: Unsupported URL scheme!

lynx apparently hardcodes recognition of https. so if we mean https there is a 
precedent to explicitly reference it.

If this message really applies to simap, snews, spop, or other protocols then 
we should probably be talking to the mail people anyways, however i doubt it 
does.
This message is an improvement, but I think it would be better to also offer a
way to resolve the problem, such as:

"~...This error typically occurs when the Personal Security Manager component is
not present.  Please try installing <product name> again."

I don't think this is worthless; fixing it could waste less time than having
users encounter the problem, file duplicate bugs or ask support questions on the
newsgroups.

> Alert!: This client does not contain support for HTTPS URLs.
> Alert!: Unsupported URL scheme!

lynx having a shitty architechture is not a reason for Mozilla to have one. Why
wouldn't they both be like the first "special case message", except with HTTPS =
$SCHEME. They don't even make use fot the special case to do anything at all
useful. Unfortunatly I have Redhat 7.2, so everything is prebuilt with SSL
support, and I can't check wget/links/w3m's error messages as they all just
Work. Fancy that :).

re: Darin's message

certainly better, but I'm still disapointed there are two codepaths.

re: trudelles message

"Please install $PRODUCT again" is awful... we have XPIs! Here's my suggestion.
One code path for any unregisted URL scheme. Pops up a window (or preferably
loads a page, when error dialogs have been eliminated, seperate bug):

 "$SCHEME" is an unknown URL scheme. Unable to load the requested page. Would
 you like more information, and links to install support for viewing this page?

                                               [ More information ] [ Cancel ]

The last sentence could use a bit better wording, but you get the idea. 'More
information' loads http://mozilla.org/protocol-helper/?scheme in the current
browser window, where it's explained a bit further, and here we can say stuff
like deselecting PSM in a custom install is the most common cause. XPIs could be
offered here that add aditional protocol support, but the main attraction would
be a link to install the PSM XPI, generated based on the browser User-Agent. The
page shouldn't be an issue to create either, just start it out simple, a link to
the last few milestones PSM XPIs for common platforms, and instructions on how
to install it manually for other builds. Later we can worry about making it
pretty and compreshensive, and using the ?scheme variable it passes.

The only reason this bug is currently so critical is because the wording for PSM
in the custom install is so incredibly awful. There's another bug on that, with
some good ideas, and as soon as it's fixed, occurances of this "bug" will be
drastically reduced (near 0). People picking 'custom' install aren't dumb, it's
just with the current wording (all they have to go on), PSM sounds like
incredibly unnecessary bloat, rather then the almost necessary component that it is.
Mach-o, BeOS, and QNX don't have PSM.  Suggesting to re-install the product is
stupid.

BeOS, QNX, and Mach-o don't have PSM.  Suggesting to download a (non-existant)
XPI is stupid.

QNX, Mach-o, and BeOS don't have PSM.  Because of that, this bug would be
critical whether or not the Custom install process described PSM better.

Read timeless's comment 84.
*** Bug 119723 has been marked as a duplicate of this bug. ***
'Stupid'?  'Awful'?  Would you guys please try to be more civil?

Jeremy: If there is an XPI we can reliably point the user to, then fine, include
that. Displaying a page with more helpful information would be much better, but
until we have the infrastructure you allude to in place to do it in every
similar error case, it will at least be inconsistent.  Still, if someone wants
to do that (I don't see any patch), and can guarantee that the page and the
information it links to will be maintained, go for it. I would advise not
mentioning URL schemes, as that is technical gobbledygook, and would turn off
nearly all users.  BTW, do you know the IDs of the bugs you refer to? They seem
much more important than this.

Christopher: I don't think we should worry so much about making this totally
generic for the sake of platform versions that don't currently have any
installable handler for this protocol. Those few users are not going to be
satisfied, even with a lot of explanatory text, but we can help users who are
able to install PSM.  If proponents of those platforms feel so strongly about
this, they can add a platform-specific message, or better yet, add PSM or other
support.
Sorry Peter... but 'awful' was the civil version. :)

> do you know the IDs of the bugs you refer to?

Bug 28586 Should use error page, not dialog, for inaccessible pages
  Note: also should cover other error dialogs, like POSTDATA. IE parity.
Bug 116703 Add a warning if the user decides to not install PSM
  Note: discussion has turned from adding a warning to providing better text.

> They seem much more important than this.

Apperantly not. 28586 is futured (with 47 votes), 116703 is untargeted.
Well, if that is your best behavior then I thank you for your restraint.

The state of 28586 is all the more reason why simply adding a suggested solution
to this error message may be the best we can do here for 1.0. (If worse is
better, maybe awful is best)  I've added a comment to 116703 endorsing an
installer text change, and hope that will greatly reduce the incidence of this bug.
Darin:

> Unknown socket type.
This doesn't mean anything. Please remove it.

> Unable to load the requested page.
This sentence is incomplete, and it won't even be true if (for example) an HTTP 
page contains HTTPS graphics or iframes.

> This error typically occurs when the Personal Security Manager component has
> not been installed.
The error doesn't typically occur, it just *has* occurred.

So, my text still stands. "This document cannot be displayed properly unless 
you install the Personal Security Manager (PSM). Download and install PSM and 
try again, or contact your system administrator." Granted, this text would be
*mildly* annoying for those users for whom PSM is not available, but I think 
that annoyance is outweighed by the greater usability for other platforms.
> I would advise not mentioning URL schemes, as that is technical gobbledygook

It's 6 words long. Very helpful and straight to the point. Many users do
understand what it means, and many more, when $SCHEME=https, will be able to
figure it out easily. Please please please, let's not head down the IE path of
braindead error messages where it's impossible to figure out the real problem.

It's not hard to accurately state the problem, and also provide very helpful
information on how to resolve it. I think my idea does this well.

> This sentence is incomplete, and it won't even be true if (for example) an
> HTTP page contains HTTPS graphics or iframes.

non-issue. We should not be popping a dialog if a page has <img src="foo:bar">.

> So, my text still stands.

As does mine, which you did not comment on.
changed unknownSocket to mpt's proposed wording.
I don't have access to obsolete patch 64614.
Jeremy, obviously you and some other mozilla contributors know what these terms
mean, but you may not appreciate just how rare that knowledge is among the
target users for this browser.  The vast majority (99 and 44/100ths?) of users
see this as impenetrable jargon, and may be so turned off by it that they make
no further attempt to resolve the problem, but instead go to IE or some other
browser that is built with the masses in mind.  I think that is a more important
consideration than giving a tiny few technical contributors such information up
front.  Perhaps  a debug version could somehow log this information, until we
can provide sufficient infrastructure to put all of the information about these
errors on web pages, carefully presented so as to satisfy both groups.
> The vast majority

First of all, the vast majority shouldn't be using Mozilla to begin with. In
Netscape's vendor release you can't select/deselect PSM.

Second of all, the vast majority that do decide to to use a non-end user browser
shouldn't be doing a custom install.

Third of all, the vast majority who decided to use a non-end user browser, and
to do a custom install, shouldn't be unchecking things they don't understand.

Finally, once a decent error message is implemented for unknown URL schemes, 
users who broke 1, 2, and 3 above "make[ing] no further attempt to resolve the
problem" should be eliminated, and once a decent description for PSM is
implemented (116703), users who broke 1 and 2 should be able to tell it's kind
of an important thing to NOT uncheck.

I don't have any idea what you're proposing giving "a tiny few technical
contributors" or what you're proposing doing with "a debug version [...]
log[ing] this information"
Attachment #64614 - Attachment is obsolete: true
Mozilla is an end-user browser, it is just not distributed directly, or
supported as an end user product.  However, companies like RedHat expect to
distribute it relatively intact to their end users, and support it.  Perhaps
people shouldn't be doing these things, but they are, and they will probably
continue.  When they do, we should be helpful, rather than spewing techno
jargon. If you want to see this info, you should be enabling protocol logs,
running a debugging version (and breaking on the errors), or using some other
means that doesn't require confusing other users.
Speaking for myself as an end user, as a representative of Red Hat and
mozilla.org I have to agree with Peter here.  I'd rather see the technical
jargon kept out of the dialogs as much as possible.  Mozilla, while not directly
distributing to end users or supporting them is targetted at the end user market
so we need to keep those end users in mind when making decisions like this.

If my mom can't figure it out, it's probably too technical.  Let's keep this in
mind and try to tone down the rhetoric. OK, guys?
Jeremy-
Re: bug 116703, this will not fix Linux (not sure about other platforms) on
which each product is distributed separately.  No, all Linux users will NOT
understand exactly what this does just because they regard themselves as "L33T".

Ideally, I'd like to see HTTPS and S/MIME support be separated from the password
manager, etc., but until that happens and PSM must be a separate product,
ANYTHING that tells a hapless user (who's a little confused about the myriad
install options of the Mozilla product) that PSM (roughly) = HTTPS will be a
fantastic improvement.
 
Just noticed, other unregisted URL schemes also have poor bahavior. Typing them
into the URL bar pops up a 'unregistered' error dialog, but following a
qwew://dsfds link, or a irc://dfsdsdf/dsf link without chatzilla installed, or a
mailto: without mailnews installed gives no feedback. Ideally the fix here will
cover those cases as well.
> First of all, the vast majority shouldn't be using Mozilla to begin
> with. In Netscape's vendor release you can't select/deselect PSM.
>
> Second of all, the vast majority that do decide to to use a non-end
> user browser shouldn't be doing a custom install.
>
> Third of all, the vast majority who decided to use a non-end user
> browser, and to do a custom install, shouldn't be unchecking things
> they don't understand.

None of the above points apply.  I installed using the rpm from mozilla's
download page.  There wasn't clear documentation stating how the
components related to the browser.  I falsely assumed the rpm labelled
just 'mozilla' was all that was needed for the basic web browser.

I could not make the connection between "Unknown socket type" and the need
to install the psm.  A README in the RPM download directory extrapolating
a little on what the different components were would have helped
tremendously.  Perhaps even putting the port number or HTTPS in the error
message would allow most users to figure out the problem.
I went through the same RPM install process, skipping PSM because (at the time)
I didn't know what it was.  I figured installing just the Mozilla RPM should be
enough to get basic browser features (like HTTPS).  At that time, I didn't get
any message at all when accessing content over SSL -- a co-worker who'd had the
same problem turned me on to the solution (of installing the PSM RPM).
i like mpt's suggested wording.  it's definitely clearer than what i had
suggested.  so, let's just check it in.  it is head-over-heals better than what
we currently have (and there is little time left before mozilla 0.9.8).  can
someone r= his patch?  trudelle, blizzard?
Status: REOPENED → ASSIGNED
Attachment #64739 - Flags: superreview+
Comment on attachment 64739 [details] [diff] [review]
v1.2 - mpt's proposed wording on unknownSocket

r/sr=darin
*** Bug 120084 has been marked as a duplicate of this bug. ***
Comment on attachment 64739 [details] [diff] [review]
v1.2 - mpt's proposed wording on unknownSocket

r=blizzard
Attachment #64739 - Flags: review+
*** Bug 120179 has been marked as a duplicate of this bug. ***
ok, patch checked in... i wonder if this one will stick ;-)
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
A=<Blizzard's Mom>  ;-)
could someone w/o psm please verify Darin's changes are in.  Thanks.
*** Bug 120380 has been marked as a duplicate of this bug. ***
*** Bug 120381 has been marked as a duplicate of this bug. ***
verified. I now get a text warning.
I've opened bug 120394 on the word "properly" in the sentence.
Status: RESOLVED → VERIFIED
*** Bug 120672 has been marked as a duplicate of this bug. ***
*** Bug 120952 has been marked as a duplicate of this bug. ***
*** Bug 121098 has been marked as a duplicate of this bug. ***
The underlying problem here is that Mozilla was basically re-writes of an
existing end-user product, Communicator. When necko and the URL handling was
re-written, nobody really looked back at it as a set of networking components
that could support any URL scheme.

And also, the networking QA people (me) were guilty of not having the time (or
foresight) to bother to test browser, built or installed as minimally as possible.

The underlying problem is that we have horrible URL scheme error handlers in
general.

What we need is something like what #106 said. It needs to be a solution that
applies to all URL handlers, that persents something sensible so you can figure
out what do to get the missing protocol scheme working.

After that, everyone else can take their scheme specific bugs, and we can
re-debate all the end-user and ease of use items. For Netscape 6's target
audience, I think mpt's suggestions were very much what is needed for that product.

What I wanted to ask now (of darin and the other code contributors), is whether
or not this fix has brought us closer to or farther from a good, generic URL
scheme error handler.

Otherwise, my thinking is that this is fixed and essentially dead for the
existing product cycle (mozilla 1.0 + netscape "whatever is next")...
*** Bug 121232 has been marked as a duplicate of this bug. ***
benc: some more generic / complete solution should probably be worked out
sometime in the future.  currently, the necko error codes must be translated
(usually by docshell) into something meaningful to an end user.  this is poor
design IMO since error codes tend to lack any context with which to really
explain what has gone wrong.  how about filing a bug to look into this more...
obviously, with a future target milestone :-/
*** Bug 121435 has been marked as a duplicate of this bug. ***
Thanks.
*** Bug 121507 has been marked as a duplicate of this bug. ***
*** Bug 122383 has been marked as a duplicate of this bug. ***
*** Bug 122609 has been marked as a duplicate of this bug. ***
*** Bug 122835 has been marked as a duplicate of this bug. ***
*** Bug 123252 has been marked as a duplicate of this bug. ***
*** Bug 123328 has been marked as a duplicate of this bug. ***
*** Bug 125264 has been marked as a duplicate of this bug. ***
*** Bug 123559 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.