54804 - PAC: migrated profiles set to PAC go deaf to network

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[buster]

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.

Comment 1

[buster]

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.

Comment 2

[Jim Roskind]

Adding RTM keyword under th epresumption that we won't be able t ofix this for
beta3 :-(

Comment 3

[Gagan]

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

Comment 4

[Jason Eager]

Made summary more specific on when you can't browse URL's.

Comment 5

[Phil Peterson]

PDT marking [rtm need info] until patch and code reviews are available.

Comment 6

[Jason Eager]

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

[Phil Peterson]

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

[selmer (gone)]

Isn't this a dup of 41072??  How is this different from that bug?

Comment 9

[Phil Peterson]

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.

Comment 10

[chris hofmann]

add proxy to summary for better searching hits

Comment 11

[[e-mail]]

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

[Jon Keatley]

Attachment: Sample proxy file that doesn't work.

Comment 13

[Jon Keatley]

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

[kcd]

Attachment: Clarifications as to platforms, non-circumventability of bug

Comment 15

[[e-mail]]

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.

Comment 16

[Gagan]

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

[Gagan]

tfv dependend on 53080

Comment 18

[Gagan]

hoping that 53080 lands by 1.0

Comment 19

[[e-mail]]

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.

Comment 20

[Tomi Leppikangas]

This seems to be same than bug #41072. Actually 53080 is
in, just little more cleanup needed.

Comment 21

[benc]

mass move, v2.
qa to me.

Comment 22

[benc]

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

[benc]

- relnote:

I don't think we have go-deaf problems anymore, do we?

Comment 24

[Robert Hershberger]

  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

Comment 25

[benc]

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 26

[Gagan]

->trudelle

Comment 27

[scottputterman]

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 [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 28

[benc]

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.

Comment 29

[benc]

VERIFIED: no point in targeting this when it's just some QA work left.