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)

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: mwitbrock, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: helpwanted, top100)

Attachments

(1 file, 3 obsolete files)

v1.2 - mpt's proposed wording on unknownSocket
1.33 KB, patch
blizzard
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
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 ago → 23 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: patch → helpwanted
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.0 → mozilla0.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 ago → 23 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.

Attachment

General

Creator:
Created:
Updated:
Size: