Closed Bug 190449 Opened 22 years ago Closed 18 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: 21 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: 21 years ago18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.