http://phonebook gives keyword search in top frame




19 years ago
18 years ago


(Reporter: Paul MacQuiddy, Assigned: ruslan)



Firefox Tracking Flags

(Not tracked)


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



19 years ago
Overview Description: The top frame at http://phonebook is being redirected to 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


19 years ago
Keywords: beta1
QA Contact: tever → paulmac

Comment 1

19 years ago
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 :-)

Comment 2

19 years ago
*** Bug 27031 has been marked as a duplicate of this bug. ***

Comment 3

19 years ago
bug 26930 and bug 26724 look related, if not identical, to this. This problem 
occurs all over internal sites.

Comment 4

19 years ago
the fix should *not* be to turn keywords off

Comment 5

19 years ago
adding [PDT+]
Whiteboard: [PDT+]

Comment 6

19 years ago
This happens because we do the keyword trick *before* we do the
trick. Maybe we need a pref to do an order on the different tricks we do to fix

Comment 7

19 years ago
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.
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 8

19 years ago
good work mr. valeski! verified with 2/14 builds. other related bugs fixed also :-)

Comment 9

18 years ago
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
Priority: P3 → P1
Resolution: FIXED → ---

Comment 10

18 years ago
ruslan? travis?
Assignee: valeski → ruslan

Comment 11

18 years ago
changing QA contact to myself.
QA Contact: paulmac → desale

Comment 12

18 years ago
phonebook just crashes for me on M16 (win2k). Jad, why do you think it's my bug?

Comment 13

18 years ago
-> travis
Assignee: ruslan → travis

Comment 14

18 years ago
Jud, this is working for me, which leads me to believe the protocol handler or 
someone responsible for the uri creation is occasionally failing.

Comment 15

18 years ago
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. 

Comment 16

18 years ago
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. 

Comment 17

18 years ago
I see this on linux too with current build. Goes straight to keyword search ...

Comment 18

18 years ago
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]

Comment 19

18 years ago, 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 

Comment 20

18 years ago
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

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 trick in nsWebShell but not in nsDocShell. 

Comment 21

18 years ago
I don't think this was ever fixed if it really can be fixed at all. Currently we
try keyword search before trying the 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"

Comment 22

18 years ago
Adding nsbeta2 keyword, since its failing with M16 too.
Keywords: nsbeta2


18 years ago
Keywords: dogfood

Comment 23

18 years ago
Putting on dogfood keyword, blocking automation in QA.


18 years ago
Blocks: 11349

Comment 24

18 years ago
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, and then show alert that could not find site 

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

Whiteboard: [PDT+] → [dogfood+][PDT+]

Comment 25

18 years ago
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 

Comment 26

18 years ago
This is nuts! Why does http://aol work (expands to (bug
35374), but http://phonebook does not and ends up in keyword search?

Comment 27

18 years ago
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

Comment 28

18 years ago
desale, is this still occurring?  Still blocking QA automation?
Assignee: travis → valeski
Whiteboard: [dogfood+][PDT+] → [NEED INFO][dogfood+][PDT+]

Comment 29

18 years ago
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

Comment 30

18 years ago
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

Comment 31

18 years ago
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
Last Resolved: 19 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 32

18 years ago
marking Verified.
You need to log in before you can comment on or make changes to this bug.