Closed
Bug 54804
Opened 24 years ago
Closed 23 years ago
PAC: migrated profiles set to PAC go deaf to network
Categories
(Core :: Networking, defect, P1)
Core
Networking
Tracking
()
VERIFIED
FIXED
mozilla1.2alpha
People
(Reporter: buster, Assigned: trudelle)
References
Details
Attachments
(2 files)
Forgive the long description, but I want to show how serious this problem can be for a new user. 1. installed NS6 build id 2000092908, WinNT 2. at first launch, selected a Nav4-created profile. Profile was migrated, successfully as far as I can tell. 3. activation launches. it hangs for a long time, then just goes away. the sign-up form never loads. 4. browser launched. HRML content area was completely blank (white background.) URL bar was empty (despite prefs showing a default URL), and nothing I could do would cause a network URL to load. I tried: a) typing in the URL bar and hitting return: no response b) File > Load Web Location, same window. No response, no error msg, nothing c) File > Load Web Location, new window. Same. 5. Finally, I tried to open a local file: d) File > Open File. This worked. 6. Tried other applications. Mail works fine. IM works fine. Editor works fine on local URLs, not on network URLs. 7. Created a brand new profile. I can load network URLs just fine with the new profile. 8. Went back to my previous (migrated) profile, looked through prefs to see if anything could cause the problem. Found that I had "Automatic proxy configuration url" set to "Supernova:8080" Changed this to "direct connection to the internet" and restarted browser. Now, activation finds what it's looking for and I can hit network URLs in the browser just fine. ========================================================================== So, I have no idea what are stated support for proxies is for beta3. But anyone who loads beta3 and either migrates a profile or clicks the auto proxy option is going to rip us off their machine in a heartbeat when they can't connect and they get no error message or feedback of any sort. So, we need to do one of these 3 things unless you can come up with a better solution for beta3: 1) enable a meaningful error message, if possible. This is potentially the lowest risk solution for the short term. 2) disable the auto proxy option, and make sure we handle migrated profiles that might have this pref already set by defaulting to something else, like "direct connect" or whatever makes sense. 3) convince the pdt that my situation was somehow unique, and users won't run into this problem.
I think this is important enough to get consideration for pull-beta3-off-the-wire. I hope someone in the networking group can convince me that I'm over-reaction. I want to be very clear: it's not the lack of support for proxies that I'm complaining about, I'm sure that's covered in some other bug (but if not, please use this bug as a placeholder for that problem too.) I'm most concerned about the total lack of feedback that the user gets in this situation. No normal user will have a clue how to fix this.
Keywords: nsbeta3
Priority: P3 → P1
Comment 2•24 years ago
|
||
Adding RTM keyword under th epresumption that we won't be able t ofix this for beta3 :-(
Keywords: rtm
Agree a plus for rtm. If it would help I could add a warning on detecting a PAC configuration at startup. Should be a small/safe fix for beta3...
Whiteboard: [rtm+]
Comment 4•24 years ago
|
||
Made summary more specific on when you can't browse URL's.
Summary: cannot browse any URLs → cannot browse any URLs, Migration of PAC preference doesn't work
Comment 5•24 years ago
|
||
PDT marking [rtm need info] until patch and code reviews are available.
Whiteboard: [rtm+] → [rtm need info]
Comment 6•24 years ago
|
||
This is a result of the UI for PAC not working properly. There is an effort underway to get it working properly, but since the patch is large, the PDT has said that they would probably rtm- it. Therefore, we need to disable the PAC UI or make it clear that it is not functioning.
Comment 7•24 years ago
|
||
Not sure which PDTer told you we wouldn't take the patch, but since I haven't seen that patch, I don't have an opinion yet. We will not hold N6 RTM for this, though, if no safe fix appears in time.
Comment 8•24 years ago
|
||
Isn't this a dup of 41072?? How is this different from that bug?
Comment 9•24 years ago
|
||
Marking [rtm-] after discussing with gagan yesterday. The people who can use the limited proxy support that mozilla currently has will have to distribute their proxy setting along with their install.
Whiteboard: [rtm need info] → [rtm-]
Comment 10•24 years ago
|
||
add proxy to summary for better searching hits
Summary: cannot browse any URLs, Migration of PAC preference doesn't work → cannot browse any URLs, Migration of Proxy PAC preference doesn't work
Comment 11•24 years ago
|
||
In my mind, this is not a dupe, it should be a migration bug that is an "inverse depends" of the PAC implementation (i.e, if you don't implement PAC, you need to flip it off when you migrate). This is especially important because customer feedback on failed PAC sessions is really negative. Apparently there is sort of a dumb pause without a sensible error message. NS4 was very good about throwing up lots of different error messages (albiet it rarely accurate error messages...) when PAC loading failed.
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
I've attached a sample proxy.pac that doesn't work. This proxy.pac file is somewhat complicated, but I've abbreviated it significantly from what it started out to be. I just wanted to show the kind of proxy.pac file we are using at Sabre. I even tried a minimal proxy.pac that simply returns the proxy to use, and it didn't work.
Comment 14•24 years ago
|
||
Comment 15•24 years ago
|
||
This really needs to be fixed if possible. If PAC is not in (or fails to make the milestone, then we need to cut off the pac migration and give an error message.
Keywords: mozilla0.8
Updated•24 years ago
|
Keywords: mozilla0.9
Comment 16•24 years ago
|
||
this should get fixed when bug 53080 lands. marking as dep. nominating for nsbeta1. Cc'ing hong since this is an e-client feature.
Comment 17•24 years ago
|
||
tfv dependend on 53080
Comment 19•24 years ago
|
||
marked for RELNOTE: It's worth noting here that you need to double-release note the SOCKS version issue here. People with existing PAC files are making SOCKS V4 connections if they get a "SOCKS" directive. Even if we migrate and support the file format, their actual network milage may vary.
Keywords: relnote
Comment 20•24 years ago
|
||
This seems to be same than bug #41072. Actually 53080 is in, just little more cleanup needed.
Comment 22•24 years ago
|
||
updated depends: It is an inverse dependency on PAC implementation, which is now tracked in 79793 PAC has enough bugs where I think the feature is at risk, perhaps we will need to use the patches in bug 41072 to disable PAC migration...
Comment 23•23 years ago
|
||
- relnote: I don't think we have go-deaf problems anymore, do we?
Keywords: relnote
Comment 24•23 years ago
|
||
I have build 2001110803 loaded on a Win98 plateform (I know stop groaning and/or laughing), and have experienced one problem with proxy setup. I was using Netscape 4 previously and migrated a profile from there. All the proxy settings where correctly replicated, except http & socks, both of which had port settings of zero (0). Not a terrible problem for me, but a normal Joe might run into one. The effect of no port setting emulated a DNS request failure, the error was something to the effect of "Unable to resolve www.mozilla.org." And having seen this problem in the past I checked that my proxy server was running correctly first (I pointed Netscape at www.mozilla.org). Once I knew the proxy was working it was a short jump to finding the incorrect settings. Thanks for your time. RTH
Keywords: mozilla1.0
Comment 25•23 years ago
|
||
This is a new bug. Can you create a new bug, and paste in the prefs.js entries that start w/ "networking" into that bug?
Comment 27•23 years ago
|
||
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Comment 28•23 years ago
|
||
RESOLVED: Fixed Comment #24 is going to a new bug, (manual should work if port==0) I'm also expanding the UI testcases to include: PAC being selected but URL is empty PAC being selected but not having valid URL. These should error and just return "DIRECT" for everything. I will file bugs if this fails. +verifyme Some please mark this as verified if you think this is the right plan. Tell me if I forgot anything here.
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: verifyme
QA Contact: pacqa → benc
Resolution: --- → FIXED
Comment 29•22 years ago
|
||
VERIFIED: no point in targeting this when it's just some QA work left.
You need to log in
before you can comment on or make changes to this bug.
Description
•