Closed Bug 190449 Opened 20 years ago Closed 16 years ago

URL History uses original URL even if you edit the URL

Categories

(Firefox :: Address Bar, defect, P2)

x86
All
defect

Tracking

()

RESOLVED WORKSFORME
Firebird0.8

People

(Reporter: bugzilla, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20030120 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20030120 Phoenix/0.5

Sf you're scrolling down in your history (from the address line) and you see
http://www.google.com/search?&q=mozilla in your history but not
http://www.google.com/ even though that's where you want to go. So if you try to
use the initial URL (http://www.google.com/search?&q=mozilla) and change it to
http://www.google.com/ by erasing /search?&q=mozilla, it will revert back to the
original URL (http://www.google.com/search?&q=mozilla) even though I wanted
http://www.google.com.

Reproducible: Always

Steps to Reproduce:
1. Goto any URL in your history from the address line
2. Delete it until it is the domain address (ie:http://www.google.com)
3. Hit enter and it will revert tot he original address

Actual Results:  
Phoenix takes me to the incorrect website by going to (in my example)
http://www.google.com/search?&q=mozilla instead of http://www.google.com

Expected Results:  
gone to http://www.google.com/
Peculiar... I'm seeing this on the 20030123 Linux build as well.

Here's a more detailed explanation of how to reproduce this bug:

1) Open up the link http://www.google.com/search?&q=mozilla
2) Create a new tab or clear the current contents of the location bar
3) Start typing google in the location/address bar
4) Use the down arrow key as appropriate to select the above google search
5) With the above google search highlighted in the location/address bar hit the
'End' button
6) Delete "search?&q=mozilla"
7) Hit Enter

Phoenix goes to http://www.google.com/search?&q=mozilla rather than simply
http://www.google.com/

-->Confirming as New
-->All OS
-->Component is Autocomplete
Assignee: blaker → hewitt
Status: UNCONFIRMED → NEW
Component: History → Autocomplete
Ever confirmed: true
OS: Windows 98 → All
*** Bug 193248 has been marked as a duplicate of this bug. ***
*** Bug 202569 has been marked as a duplicate of this bug. ***
However, if after you edit the url, you use the up arrow to put the focus back
into the URL field, and hit enter, phoenix works as expected.  Probably the
easiest thing (no, i'm not a phoenix developer so i could be talking out my
rear) would be to have the focus switch to the url field when typing occurs in it.
Works for me on the latest build:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030424 Mozilla Firebird/0.6

Had seen this happening upto 20030422
Using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030425 Mozilla
Firebird/0.6

I thought that this has been fixed but it is still showing up... start typing in
any address ex) the google one, scroll down to any address that isn't the main
website, then hit backspace to delete the search string (until you are left with
just http://www.google.com) and finally hit enter. It still reverts back to the
original address that you had selected.
> I thought that this has been fixed but it is still showing up.
Why did you think it was fixed when this bug report is still open? Please don't
spam the bug report with useless comments. And no, you don't need to reply and
explain yourself. :)

(Sorry for my part of the bugspam.)
I've found it also occurs when I try to edit urls suggested in an input form
component, not just the address bar.
Taking QA. Sorry for the bugspam
QA Contact: asa → davidpjames
Confirming still present in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b)
Gecko/20030804 Mozilla Firebird/0.6.1
Just switched to Firebird for the 2nd time, and have been bitten by this lots
already. :)

Is it not a case of just closing/removing selection for the auto-complete when
the Backspace key is used? Typing normally, and arrow keys, all close the
drop-down. Why not add Backspace to this list?
*** Bug 215262 has been marked as a duplicate of this bug. ***
Still present in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030816
Mozilla Firebird/0.6.1+
*** Bug 216992 has been marked as a duplicate of this bug. ***
*** Bug 218441 has been marked as a duplicate of this bug. ***
Irritating. .8. 

Assignee: hewitt → bugs
Priority: -- → P2
Target Milestone: --- → Firebird0.8
Is this fixed?  I am using the Firebird 0.7 release and this works for me.  I
can edit a URL from the history and it loads the URL that I actually type.
Yes, it does seem to work for me actually, using a 20031109 0.7+ build on win2k.
 When the backspace key is pressed, the dropdown still remains visible, but
nothing is selected, and hitting enter goes to the resulting URL in the text
box, not the original.
Can anyone on Linux confirm?

WFM 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Just a little note - while backspace seems to work now, I can break it
*horribly* by using Ctrl-Backspace (delete word).
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Bug seems to have been fixed in this release.  Can edit URLs in the URLBar, and
on hitting enter, am taken to the edited version of URL.  Yay.
Confirmed WFM on Win and Lin.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031206
Firebird/0.7+

Seeing this again/still, and going back to about 11/22 in builds and still
seeing it.  It doesn't seem to happen under all circumstances, but I'm not
entirely sure when it does and doesn't.  For one thing, it works fine when I
just append to the URL at all though, but not always when I replace text or add
something in the middle.
v.
Status: RESOLVED → VERIFIED
Bug still here in v0.9.3 on win2003.

I can not reopen the bug. Someone please reopen it or I will submit a new bug.

Details:

1.) Visit http://redhat.com/
2.) Open a new tab
3.) enter "red" into the URL bar
4.) Press cursor-down to select "http://redhat.com/" in the drop down history
 - note that the URL bar now shows "redhat.com/" instead of "http://redhat.com/"
is that a known bug ?
5.) Press the Home key and add "fedora." to the beiginning of the URL
 - note : the drop down menu is still shown and the "http://redhat.com/" is
still selected in it ( colored inverse, as opposed to the rest of the items inmenu )
6.) Press ENTER on keyboard

Actual result : 
http://redhat.com/ is loaded

Expected result :
http://fedora.redhat.com/ is loaded
I've been able to recreate this bug again as outlined recently using on WinXP
using version:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3


However the initial complaint was connected to the suffix of a URL non being
deleted. That has no longer an issue, but obviously trying to add a prefix to a
URL  is resulting in the same behaviour of the original bug.
Reopening until someone can verify.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
I can definitely reproduce the issue David outlines in comment 25. My guess
however, is that this is not a regression. It was originally marked WORKSFORME
because hitting backspace unselected the history entry from the dropdown. This
is still the case, however, David is just using a different editing operation,
which doesn't deselect the entry.

Any insertion or deletion of text (and don't forget about the wacky text-ops
like control-backspace, control-w, etc) should deselect the history dropdown,
AND cause the dropdown to be regenerated, so that only entries matching the new
string in the URL bar are listed.

Interesting to note, that the <- back and -> forward arrow keys completely
cancel the history dropdown. Whatever the fix, this should do the same as
home/end. I'm not sure if canceling the dropdown when the cursor is moved is
necessary.
Something simular:

Reproducible: Possibly needs preference 'browser.urlbar.autoFill'
(case-sensitive) to be (created and) set to 'true'.
Probably/possibly only works if the 'root' URL is NOT the best
auto-complete-match, so if this test is done quite a few times another URL must
be used.

Steps to Reproduce:
1. Go to any bugzilla bug, e.g.
'http://bugzilla.mozilla.org/show_bug.cgi?id=190449' (this one).
2. Type 'bugzilla.mozilla', it gets auto completed to something longer
('http://bugzilla.mozilla.org/show_bug.cgi?id=190449').
3. Select the part AFTER the first slash (so 'http://bugzilla.mozilla.org/' is
not selected).
4. Hit DELETE.
5. Hit ENTER.

Expected Result:
1. Go to 'http://bugzilla.mozilla.org/'.

Actual Result:
1. Went to 'http://bugzilla.mozilla.org/show_bug.cgi?id=190449' (or whichever
URL was the best/first match).

Quick Workaround:
1. Hit DELETE twice instead of once.

This could (indirectly) be fixed if
http://bugzilla.mozilla.org/show_bug.cgi?id=240397 is FIXED.
QA Contact: davidpjames → location.bar
Assignee: bugs → nobody
Status: REOPENED → NEW
WFM Win32 Minefield 2007040504.
Status: NEW → RESOLVED
Closed: 19 years ago16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.