47863 - Pressing Esc in address field should restore URL to that of page

Status: VERIFIED FIXED

(SeaMonkey :: Location Bar, enhancement, P3)

Description

[hand]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    2000080608

The Address bar does not respond to the ESC key

Reproducible: Always
Steps to Reproduce:
1. Open any page.
2. Go into the address bar and change the address without pressing ENTER
3. Press ESC.

Actual Results:  Nothing happens

Expected Results:  Should replace whatever is in the address bar with the 
address of the page that is currently being displayed.  The new text should be 
selected.

Comment 1

[David Hallowell]

The expected behaviour occurs in IE but not Netscape Communicator. I dunno if
it's useful or not, I've got used to typing in the url bar then hitting escape
to stop the page (for example) redirecting while still composing another URL.

Confirming this RFE and marking as new. I've updated the subject line to
hopefully be more descriptive (was: Returning to displayed address)

Comment 2

[Matthew T (active 1999-2002)]

> I've got used to typing in the url bar then hitting escape to stop the page
> (for example) redirecting while still composing another URL.

That need would be pretty much removed if bug 15050 was fixed.

Comment 3

[leger]

Reassigning from bdonohoe to hangas

Comment 4

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 5

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 6

[Matthew T (active 1999-2002)]

Yes. Very good idea. --> Doron.

Comment 7

[Matthew T (active 1999-2002)]

Here is a test which a fix to this bug should pass:

1.  Load <http://mozilla.org/>.
2.  Click in the address field, and clear all the text.
3.  Type `abc'.
4.  Click in the content area.
5.  Click in the address field again, and place the caret at the end of the
    `abc'.
6.  Type `def'.
7.  Press Escape.

After these steps, the contents of the address field should have reverted to
`http://mozilla.org/' (without quotes).

Comment 8

[Matthew T (active 1999-2002)]

Oh, I forgot to mention: When the URL is reverted, it should become selected.

Comment 9

[Doron Rosenberg (IBM)]

ok, say i press escape and i did not change the urlbar's content, should it
still highlight the url? 

Comment 10

[Karl Ove Hufthammer]

> ok, say i press escape and i did not change the urlbar's content,
> should it still highlight the url? 

Yes (IE for Windows works this way).

Comment 11

[Doron Rosenberg (IBM)]

Attachment: proposed patch

Comment 12

[Doron Rosenberg (IBM)]

patch attached, does all mpt wants

Comment 13

[Doron Rosenberg (IBM)]

patch attached, does all mpt wants

Comment 14

[Boris Zbarsky [:bzbarsky]]

r=[e-mail]

Comment 15

[Jesse Ruderman]

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

Comment 16

[Jesse Ruderman]

If a page is loading, pressing Esc the first time should stop the page from 
loading without changing the contents of the location bar.  That way, if I 
realize I made a mistake typing the URL and press Esc, I wouldn't have to re-
type the entire URL.  (Pressing Esc a second time should revert the location 
bar, assuming the location bar has focus.)

Comment 17

[timeless]

nsbeta1+ [from dupe]

we can check this in as an interim.

the correct fix will change
if( event.keyCode == 27 ) { resetURLBar(); }
to check to see if we are throbbing and either resetURLBar() or stopThrobbing

Comment 18

[Doron Rosenberg (IBM)]

ok, so if I press "ESC" while throbbing inside the urlbar should just stop us
throbbing, and NOT highlight the urlbar contents and revert?

everyone agree with this? if yes, i'll try if I can patch that today.

Comment 19

[Matthew T (active 1999-2002)]

Sounds fine to me. It should not select the contents of the field in that 
situation, otherwise you'd have slight dataloss in the case of stopping a 
redirect while you're trying to type a new URL.

Comment 20

[Doron Rosenberg (IBM)]

ok, first we should then call browserstop() _after_ the reset(). I can check it
in 2 ways - window.XULBrowserWindow.status or with:

var foo = Components.interfaces.nsIWebProgressListner;
foo.STATE_IS_NETWORK.

or should I |&| them?

Comment 21

[Doron Rosenberg (IBM)]

Attachment: proposed patch

Comment 22

[Doron Rosenberg (IBM)]

new patch attached, takes care of Jesse's case.

any nitpicks?

Comment 23

[Doron Rosenberg (IBM)]

forget that patch, i am not doing the correct thing for checking if we are done
browsing.

Comment 24

[Doron Rosenberg (IBM)]

Attachment: new patch

Comment 25

[Boris Zbarsky [:bzbarsky]]

"throbberElement is NULL if homepage is set to about:blank"

Does this mean is stays null?  Or becomes non-null as soon as we navigate to a 
different page (one that is not about:blank)?  If the home page is _not_ 
about:blank, does throbberElement become null if we go to about:blank by typing 
it in the URLbar?

Comment 26

[Doron Rosenberg (IBM)]

argh, looks like my comments i posted after posting the patch did not make it
through.

without the !throbberElement check and about:blank as homepage, i got a
"throbberElement has no properties." It only happens if about:blank is your
homepage. I guess it is set to NULL untill the first activity.  it does not
happen if another page is your homepage or if you visit about:blank after
loading the homepage.

I only hit this by mistake when trying a new profile ;)

Comment 27

[Boris Zbarsky [:bzbarsky]]

so.  A degenerate case.  Homepage is about:blank.  I bring up a new window,
start typing in the URL bar, then hit escape.  Should the URL bar be cleared? 
(reset to "")?  If so, that "if (throbberElement ...)" needs an else clause.

Comment 28

[Doron Rosenberg (IBM)]

Attachment: new patch

Comment 29

[Doron Rosenberg (IBM)]

hopefully final patch. the global throberElement has been removed by some other
checkin, so now am getElementById'ing it.  This now makes the NULL check useless.
r=/sr= or nitpicks?

Comment 30

[Boris Zbarsky [:bzbarsky]]

r=[e-mail]

Comment 31

[Alec Flett]

ack! can you move that whole onkeypress handler out into a seperate function?
there shouldn't be that much logic in a XUL file.

also, I think (I could be wrong) that there is a way to get to the DOM's
DOM_VK_ENTER and DOM_VK_ESCAPE property off of the "event" object..

Comment 32

[Alec Flett]

sure enough, you can say:
if (event.keyCode == KeyEvent.DOM_VK_RETURN) {...}

etc..

Comment 33

[Doron Rosenberg (IBM)]

Attachment: new patch, with alecf's suggestions

Comment 34

[Doron Rosenberg (IBM)]

Attachment: this time the right file...

Comment 35

[Doron Rosenberg (IBM)]

ok, new patch added (please overlook the 15:47 one), has all of alecf's
suggestions.  

Comment 36

[Alec Flett]

quick turnaround!
sr=alecf

Comment 37

[Boris Zbarsky [:bzbarsky]]

looks good.  r=[e-mail]

Comment 38

[Blake Ross]

Fix checked in.

Comment 39

[Claudius Gayle]

nice! VERIFIED Fixed with 20010515 builds on all platforms