235825 - "I'm Feeling Lucky" search from address bar doesn't activate Stop toolbar button

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[Ahmet A. Akin]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219 Firefox/0.8.0+

When you write lets say ony "dir" in the url bar, the web page goes to Google "i
am feeling lucky" url such as " http://www.dir.bg/ " but user cannot stop
loading page. The stop button is inactive.

Reproducible: Always
Steps to Reproduce:
1. open a new window or tab,
2. write only "dir" to the URL bar (without the " signs)
3. try to stop loading of page

Actual Results:  
http://www.dir.bg/ page loads but does not allow stoping

Expected Results:  
allows stopping.

Comment 1

[Jason Barnabe (np)]

Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b)
Gecko/20040331 Firefox/0.8.0+

The Stop toolbar button is active at first, but gets deactivated part way
through (after it finishes loading from Google and starts loading the
destination page?) You CAN stop it by pressing ESC at any point.

Comment 2

[Gene Sokolov]

This seems to be the same as #94033

Comment 3

[Gene Sokolov]

(In reply to comment #1)
> destination page?) You CAN stop it by pressing ESC at any point.

No. The ESC does not work after the stop button is deactivated. The only way to
stop the browser is to close the tab.

This seems to be a duplicate of
http://bugzilla.mozilla.org/show_bug.cgi?id=94033
Can someone double check?

Comment 4

[Simon Paquet [:sipaq]]

Don't set the blocking+ flag. This is not only spam (because of the amount of 
mail it generates) but also serious abuse. Developers track these bugs to 
identify serious showstoppers. What a showstopper is is up to the developers 
decide, not you, not other commenters, not even QA Contacts like me have any 
say in that.

You may set the blocking? flag to nominate a bug which you believe to be a
serious showstopper. Showstoppers means bugs which YOU wouldn't want to release
FF with if you were in charge and keeping in mind, that you would have to let
other serious bugs unfixed to fix this bug.

This is not a showstopper.

Comment 5

[PikeUK]

*** Bug 248014 has been marked as a duplicate of this bug. ***

Comment 6

[Jesse Ruderman]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040629
Firefox/0.8.0+

Comment 7

[Nigel McNie]

This happens for me whenever I try to visit a "vague" url - e.g. "srv007". When
you try such a url and it's not a virtual host or something similar, after
Google is contacted you cannot stop the browser loading the page.

Comment 8

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

Mozilla/5.0 (Windows; U; Win98; es-ES; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

Still happening, STOP activated at first but not on the load of the site, ESC
doesnt work at this point.

Comment 9

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

> Mozilla/5.0 (Windows; U; Win98; es-ES; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

If you use 2 words ("hello all") the stop button can be used (also ESC), but if
you only type "hello" you cant

Comment 10

[Tracy Walker [:tracy]]

*** Bug 282085 has been marked as a duplicate of this bug. ***

Comment 11

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

BUg confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8b4)
Gecko/20050908 Firefox/1.4

Comment 12

[Scott MacGregor]

no patch, not a regression over 1.0 and not serious enough for us to stop the
release. Hopefully someone will work on this for the next release. 

Comment 13

[Steve England [:stevee]]

*** Bug 332153 has been marked as a duplicate of this bug. ***

Comment 14

[Simon Bünzli]

Attachment: handle "nested" requests for this special case

The issue seems to be that nsWebShell:EndPageLoad starts a new request before the old one is stopped. This causes progress listeners which only keep binary state information (loading/not loading) - such as those implemented by tabbrowser.xml - to believe that the request is done although it's not. I suppose the problem lies in this case with the progress listeners (since the different requests could be distinguished).

This patch fixes the issue in tabbrowser.xml by counting the open requests and ignoring STATE_STOP when it's due to an "unknown host" error (which triggers the keyword search in the above mentioned nsWebShell:EndPageLoad) and there are still other requests open for the tab in question.

Comment 15

[Mike Connor [:mconnor]]

Comment on attachment 216739 [details] [diff] [review]
handle "nested" requests for this special case

Looks good, let's get this in for some wider testing.

Comment 16

[:Gavin Sharp [email: [e-mail]]]

mozilla/toolkit/content/widgets/dialog.xml 	1.25.2.5
mozilla/toolkit/content/widgets/tabbrowser.xml 	1.103.2.32