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.

seeing this too on win98

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

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.

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

Changing component to search

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

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.

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.

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.

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

really

dns

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.

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 :-)

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.

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

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?

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?

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

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