Closed Bug 27339 Opened 25 years ago Closed 24 years ago

http://phonebook gives keyword search in top frame

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: paulmac, Assigned: ruslan)

References

(
URL
)

Details

(Whiteboard: [NEED INFO][dogfood+][PDT+]) 

Overview Description: The top frame at http://phonebook is being redirected to
keyword.netscape.com instead of showing the name look up frame. With keywords
off this does not happen.

Steps to Reproduce:
1) Goto http://phonebook with keywords turned on

Actual Results: Top frame goes to keywords page, bottom frame ok

Expected Results: Should get name lookup frame at top, since it is a valid url.

Build Date & Platform Bug Found: 2/9 commercial builds, Linux and Windows
Keywords: beta1
QA Contact: tever → paulmac
setting myself as QA contact. I'll try to figure why other pages like slip and
warp don't have the same problem.

Marking beta1 since who knows what other internal sites will have this problem.

We could always turn keywords off :-)

*** Bug 27031 has been marked as a duplicate of this bug. ***
bug 26930 and bug 26724 look related, if not identical, to this. This problem 
occurs all over internal sites.
the fix should *not* be to turn keywords off
adding [PDT+]
Whiteboard: [PDT+]
This happens because we do the keyword trick *before* we do the www.xxx.com
trick. Maybe we need a pref to do an order on the different tricks we do to fix
urls.

I was never able to reproduce this to begin with, but I just checked in a fix 
for basically the only exposure we had in the logic.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
good work mr. valeski! verified with 2/14 builds. other related bugs fixed also :-)
Status: RESOLVED → VERIFIED
I'm running automation with M15 builds today.
This seems to have occured again on Win-95.

Its blocking automation severely. Today I had to restart automation atlest 20-25 
times because at any random testcase, it goes to keyword + that testcase name.

Re-opening bug, marking p1, and blocker.
Severity: normal → blocker
Status: VERIFIED → REOPENED
Priority: P3 → P1
Resolution: FIXED → ---
ruslan? travis?
Assignee: valeski → ruslan
Status: REOPENED → NEW
changing QA contact to myself.
QA Contact: paulmac → desale
phonebook just crashes for me on M16 (win2k). Jad, why do you think it's my bug?
-> travis
Assignee: ruslan → travis
Jud, this is working for me, which leads me to believe the protocol handler or 
someone responsible for the uri creation is occasionally failing.
I tried it with 04-17-06 mozilla builds, and todays M15 builds too, and it is 
still there.  
Right now I can see this happening with Win-95 and Win-98. To me Linux builds 
seem good enough. I'm not seeing this one on Linux. About Mac, I'll provide 
comment on it once we test it on Mac.

Last builds we saw without this problem were 04-11-09, and 04-10-09 on windows. 
Something happened after that. 
Looks like its not seen on MAC too. Chris ran automation on MAC, and didn't see 
any problem like this. Looks like its windows specific. 
I see this on linux too with current build. Goes straight to keyword search ...
I know its hard to reproduce.
It does not happen all the time. 
The key to reproduce it is to run with keywords which can be turned on and off 
in the pref panel under smart browsing.
For us if we run 40-50 testcases in queue then it just couldn't find some 
testcase because it start finding some keywords on internet. or some server name 
 mentioned in URL assuming it as domain name. [And generally we run thousands of 
testcases at one time]
andreas.otte@primus-online.de, could you please provide steps to reproduce ?
I'm glad atleast somebody else other than me is seeing this one. 
I can reproduce it with automation, but my steps to reproduce would be really 
complicated to understand.
If you are seeing on regular basis, could you please provide steps to reproduce 
?
It was very simple. I ran with keyword support switched on. Simply typed
http://phonebook into the urlbar and ended up in keyword search. Switched
keyword support of in the prefs, typed http://phonebook again and ended up with
http://www.phonebook.com.

It may have something to do with the transition from webshell to docshell travis
is currently doing. I haven't investigated this further but I did find the
www....com trick in nsWebShell but not in nsDocShell. 
I don't think this was ever fixed if it really can be fixed at all. Currently we
try keyword search before trying the www....com trick if keyword search is
enabled. Sometimes this may be right, sometimes not. If we change that order,
the same problem applys. I can smell the bug report: "I wanted to get a keyword
search for xyz but ended up on www.xyz.com."

Adding nsbeta2 keyword, since its failing with M16 too.
Keywords: nsbeta2
Keywords: dogfood
Putting on dogfood keyword, blocking automation in QA.
Blocks: 11349
Per desale email - 
"What happens exactly about bug# 27339, is when ngdriver spawns new window to
execute testcase, new window get URL something like
http://bubblegum/ngdriver/suites/testcasefilename. Treat "bubblegum",  also like
"phonebook". Instead of loading testcase, it starts looking for 
http://www.bubblegum..com, and then show alert that could not find site 
www.bubblegum.com. 

Now this does not happen with every testcase, it happens randomly to any 
testcase. On an average after every 25-30 testcases."

THIS BLOCKING QA FROM AUTOMATED TESTING. Putting on [dogfood+] radar.
Whiteboard: [PDT+] → [dogfood+][PDT+]
I tried automation with todays builds and seems like its working fine with 
todays builds. Still I'm waiting for mondays builds, and that time I'll surely 
let you know what is happening. One thing I'm really thinking about is, this one 
was never fixed. This issue is allways there. Its just its hard to reproduce.
I'm working on testcase to reproduce it, and to get to exact point where its 
failing.

This is nuts! Why does http://aol work (expands to http://www.aol.com) (bug
35374), but http://phonebook does not and ends up in keyword search?
NS 4.72 on linux also goes to the keyword search with http://phonebook.

With http://pb it goes there to for a split second then redirects to
http://www.pb.com.


desale, is this still occurring?  Still blocking QA automation?
Assignee: travis → valeski
Whiteboard: [dogfood+][PDT+] → [NEED INFO][dogfood+][PDT+]
No, its not blocking automation. I mean yeah, sometimes it does occur, but 
frequency of occurence is very less compared to previous builds, so I can not 
say its blocker any more.
As far as bug, yeah it is still there.

Not blocker anymore though.
Changing seviarity from blocker to major.
Severity: blocker → major
I can't repro this. The phonebook does a some 302 redirects though. I bet we 
have a double/lacking OnStop being fired after a cancellation or something, and 
*sometimes* one OnStop gets through before the other??? If one comes through w/ 
an error (i.e. cancel) we'll kick the load to the keyword server.

Over to ruslan.
Assignee: valeski → ruslan
Works for me too. BTW, we can never fire OnStop twice anymore, even if Cancel 
issued incorrectly. I added a multiplexing listener (called FinalListener) to 
http handler, which will keep track of all OnStart/OnStop
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME
marking Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.