Closed
Bug 47863
Opened 24 years ago
Closed 23 years ago
Pressing Esc in address field should restore URL to that of page
Categories
(SeaMonkey :: Location Bar, enhancement, P3)
SeaMonkey
Location Bar
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: hand, Assigned: doronr)
References
Details
Attachments
(6 files)
1.80 KB,
patch
|
Details | Diff | Splinter Review | |
1.87 KB,
patch
|
Details | Diff | Splinter Review | |
902 bytes,
patch
|
Details | Diff | Splinter Review | |
1.94 KB,
patch
|
Details | Diff | Splinter Review | |
1.99 KB,
patch
|
Details | Diff | Splinter Review | |
1.99 KB,
patch
|
Details | Diff | Splinter Review |
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•24 years ago
|
||
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)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Returning to displayed address → [FEATURE] Pressing esc should restore URL in address bar to current url
Comment 2•24 years ago
|
||
> 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 4•24 years ago
|
||
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...
QA Contact: mpt → zach
Comment 6•23 years ago
|
||
Yes. Very good idea. --> Doron.
Assignee: mpt → doronr
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → sairuh
Summary: [FEATURE] Pressing esc should restore URL in address bar to current url → Pressing Esc in address field should restore URL to that of page
Comment 7•23 years ago
|
||
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•23 years ago
|
||
Oh, I forgot to mention: When the URL is reverted, it should become selected.
Updated•23 years ago
|
Component: XP Apps: GUI Features → URL Bar
QA Contact: sairuh → claudius
Assignee | ||
Comment 9•23 years ago
|
||
ok, say i press escape and i did not change the urlbar's content, should it still highlight the url?
Comment 10•23 years ago
|
||
> 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).
Assignee | ||
Comment 11•23 years ago
|
||
Assignee | ||
Comment 12•23 years ago
|
||
patch attached, does all mpt wants
Target Milestone: --- → mozilla0.9
Comment 14•23 years ago
|
||
r=bzbarsky@mit.edu
Comment 15•23 years ago
|
||
*** Bug 32194 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
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•23 years ago
|
||
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
Keywords: nsbeta1+
Assignee | ||
Comment 18•23 years ago
|
||
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•23 years ago
|
||
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.
Assignee | ||
Comment 20•23 years ago
|
||
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?
Assignee | ||
Comment 21•23 years ago
|
||
Assignee | ||
Comment 22•23 years ago
|
||
new patch attached, takes care of Jesse's case. any nitpicks?
Keywords: mozilla0.9,
patch
Assignee | ||
Comment 23•23 years ago
|
||
forget that patch, i am not doing the correct thing for checking if we are done browsing.
Assignee | ||
Comment 24•23 years ago
|
||
Comment 25•23 years ago
|
||
"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?
Assignee | ||
Comment 26•23 years ago
|
||
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•23 years ago
|
||
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.
Assignee | ||
Comment 28•23 years ago
|
||
Assignee | ||
Comment 29•23 years ago
|
||
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•23 years ago
|
||
r=bzbarsky@mit.edu
Comment 31•23 years ago
|
||
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•23 years ago
|
||
sure enough, you can say: if (event.keyCode == KeyEvent.DOM_VK_RETURN) {...} etc..
Assignee | ||
Comment 33•23 years ago
|
||
Assignee | ||
Comment 34•23 years ago
|
||
Assignee | ||
Comment 35•23 years ago
|
||
ok, new patch added (please overlook the 15:47 one), has all of alecf's suggestions.
Comment 36•23 years ago
|
||
quick turnaround! sr=alecf
Comment 37•23 years ago
|
||
looks good. r=bzbarsky@mit.edu
Comment 38•23 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 39•23 years ago
|
||
nice! VERIFIED Fixed with 20010515 builds on all platforms
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•