72109 - Internet Keywords: starts because of incorrect frame src url

Status: RESOLVED DUPLICATE of bug 65421

(Core :: DOM: Navigation, defect)

Description

[Jens-Uwe]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; 0.8.1) Gecko/20010314
BuildID:    2001031409

I very often have the problem, that Mozilla calls the Netscape-Search without me
knowing why with some random search word.
I think I now managed to find a reliable way to reproduce this problem :-)

Reproducible: Always
Steps to Reproduce:
1.go to
http://www.ieq.de/scripts/shopframe.asp?M=W&BURL=kswglist.asp&HNR=&WG1=50&WG2=50&WG3=30&SID=112489874&TT=36965%2C942974537&SC=9
2. if step one did not work, go to www.ieq.de -> Haushalt -> Elektrogeraete ->
Geschirrspueler



Actual Results:  after a while you see the Netscape search with the search
results for the word "scripts".


Expected Results:  it should show informations about Geschirrspueler (dish washer)

In the long URL (step 1 in Steps to Reproduce) is a session ID, so it might stop
working. The way mentioned in step 2 should always work.

Comment 1

[Doron Rosenberg (IBM)]

seeing this too on win98

Comment 2

[Boris Zbarsky [:bzbarsky]]

That page returns the following code:
<frame marginwidth="0" marginheight="0" border="0" frameborder="no"
framespacing="0" name="ListFrame"
src="http:/scripts/ksalist.asp?M=W&BURL=/scripts/shopframe.asp&HNR=&WG1=50&WG2=50&WG3=30&WG4=&WG5=&VIEW=K&SORT=S&MPRI=0&PAGESIZE=25&PAGE=1&SID=112490193&TT=36966%2C0271990741&SC=2">

note the _single_ slash after http: in the frame src.

This is a malformed URL and mozilla tries to do the best it can with it...  So
it tries to find the "scripts" host and can't.  Not sure it should be starting
search, though.....

I would say this is a duplicate of bug 32966 or an evang bug...

Comment 3

[Jens-Uwe]

ok, I agree that the given URL is just plain wrong. So all this bug is talking
about is, why the search get started, since this is probably the last thing the
user expects. 
Better error message?
Rendering the page as it was intended, even if its not 100% right thing to do?
Any other browser displays the page, so the user will say that Mozilla does it
wrong, not the author of the page.

Comment 4

[timeless]

this probably belongs to webshell, we shouldn't do a web search for frame urls.

Comment 5

[neeti]

Changing component to search

Comment 6

[Jens-Uwe]

is this a dupe of 65911??
but that bug argues, that the Netscape search engine is used and not the default one. 

Comment 7

[Claudius Gayle]

this might very well be a dupe of 65911. In both cases if you give the url bar something
that is not a url(in this case a malfromed url) - a search starts up (actually the Internet 
Keywords service). This is no surprise however, 4.x has been doing the same thing for years
now and Moz has always done it. If you turn off Internet Keywords in your Navigator|Smart
Browsing prefs then you'll just get an error message saying "www.your malformed url.com"
was not found.

Comment 8

[Jens-Uwe]

claudius: 
thanks for the hint with disabling internet keywords. Seems I always disabled
this feature on 4.x but did not thougt about it when I created a new profile for
mozilla.After disabling this feature I get the behaviour I expected and which
you described.
I think now this should be marked as invalid, since it works as intented. 

I still think its an unexpected behaviour for most users and can lead to
surprising results, just go to the URL I mentioned in my comments.

Comment 9

[benc]

VERIFIED:
I think that we should not hook up "feature" like auto-searching to inline 
content like frames and inline images, but I think this is better dealt with in 
other bugs I have seen about non-fqdn hostnames.

Comment 10

[benc]

-> networking

This is a networking bug. We lose our mind and call the keyword routines.

Comment 11

[Peter Trudelle]

really

Comment 12

[neeti]

dns

Comment 13

[gordon]

This is not a DNS problem.  The DNS service knows nothing about keywords.

Peter, could you provide a more complete description of why this bug is being
reopened?  The bug was originally created because the reporter didn't realize
they had enabled the keyword feature when they created a new profile.

Comment 14

[Jens-Uwe]

as the reporter of this bug I suggest to mark it WorksForMe, since it does. I
don't know, if the shop changed or the bug was fixed in the meantime (it was
reported 10 monthes ago).
Mozilla does not run amok if you click through the shop, it always works as
expected. When I reported this bug, Mozilla either started the Netscape search
or showed an 404 file not found error, depending of either this smart keyword
feature was enabled. As I said, this does not happen anymore on the mentioned
page and I never had this problem on other pages since a while.

Marking WFM, reopen if you think I am wrong :-)

Comment 15

[Peter Trudelle]

I wasn't trying to reopen this, sorry if that somehow happened, I think it was a
side effect of the component change, not intentional.  I just saw the
->networking comment, and that the component hadn't actually been changed, so I
tried to help.

Comment 16

[benc]

REOPEN to mark as dupe.
corrected summary. It is DNS in the sense that IK was preempting what should
have gone to DNS. 

Comment 17

[gordon]

Huh?  The fact that Internet Keywords were interfering, does not imply any
problem with the DNS service.  Why do you need to change the summary to identify
this as a DNS bug?  This bug was closed almost a year ago.  Do we really need to
keep messing with it?

Comment 18

[Jens-Uwe]

benc:
for me as the reporter this bug looks fixed (see my comment #14). Does it really
matter, if it is a WFM or a dupe? And if it is a dupe, can you please mark it as
such and don't leave it 'reopened', which might cause some people to wasted time
for something already fixed?

Comment 19

[benc]

Jens-Uwe: sorry about the mess. Last night's second change didn't take on bugzilla.

This bug needed to be duplicated correctly, because it was the only bug ever
filed that accurately showed how the problem occurred.

I know some of these bug updates seem like they are dredding up the past, but in
QA, we want to correctly characterize problems and build a single test suite for
each area that will catch most problems in a single set of tests.




*** This bug has been marked as a duplicate of 65421 ***

Comment 20

[benc]

gordon was right... -> Docshell.

relucantly, I've slowly been spending time cleaning out the IK and Domain
Guessing bugs so everything is in the right place (not networking..)

I think, at this point, domain guessing will also correctly NOT fire in this
case (if IK is off, domain guessing gets called sometimes).