Open Bug 435932 Opened 16 years ago Updated 2 years ago

Same-document URL changes (e.g. clicking anchor links) don't update the URL bar if its value has been edited

Categories

(Firefox :: Address Bar, defect, P3)

Product:
Firefox
Component:
Address Bar
Type:
defect
Points:
3

Tracking

()

People

(Reporter: rostislav.hristov, Unassigned)

References

Details

(Whiteboard: [fxsearch]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

Manual edits of the address bar value lead to broken Ajax/Flash location.hash based navigation scripts.

Reproducible: Always

Steps to Reproduce:
1. Load https://bugzilla.mozilla.org/show_bug.cgi?id=213946
2. Click in the URL bar, add "#c29" to the end of the URI and do not hit Enter, just leave the bar
3. Click on the link that says #c30
Actual Results:  
URL bar says https://bugzilla.mozilla.org/show_bug.cgi?id=213946#c30

Expected Results:  
URL bar says https://bugzilla.mozilla.org/show_bug.cgi?id=213946#c29

Related to https://bugzilla.mozilla.org/show_bug.cgi?id=302575
Version: unspecified → Trunk
The described behavior is correct.

If the user really does not want the url to change, they should not click any links on the page (which as expected does change the url) - or if they need the info on the new page, open it in a new tab or windows, which would not upset the url on the current page.

Current user interaction should override older user interaction. Clicking the link in the same window should absolutely change the url.

Scripts on the current page, should not be able to change the url in between location.blur() and link.focus() (this bug does not address that though).
Um, I think the actual and expected results are reversed, should read:

Actual Results:  
URL bar says https://bugzilla.mozilla.org/show_bug.cgi?id=213946#c29

Expected Results:  
URL bar says https://bugzilla.mozilla.org/show_bug.cgi?id=213946#c30

Also, you get correct behaviour to you navigate to new pages, just not when you start navigating named anchors within the current page.
Summary: After editing the URL bar gets confused about what URI is loaded → After editing the URL bar, hash change is not reflected in the URL bar
Mark is correct, I submitted the description incorrectly. 

Does anybody have an idea how to edit it?


Confirmed. This happens when you edit manually the location bar and then click to an anchor link of the page. This bug happens also on Fx 2.0.0.16. Moving to component Location Bar.

Is this a regression?
Status: UNCONFIRMED → NEW
Component: General → Location Bar and Autocomplete
Ever confirmed: true
QA Contact: general → location.bar
Summary: After editing the URL bar, hash change is not reflected in the URL bar → Location bar don't change the url if you edit it manually (see Comment 5)
Whiteboard: [regression?]
It's not related, Bug 407888 is a problem with searches in places with location bar.
I believe that this was never working or the regression has started a really long time ago. I can also see this behavior with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.7a) Gecko/20040210 Firebird/0.8.0+
Whiteboard: [regression?]
Summary: Location bar don't change the url if you edit it manually (see Comment 5) → Same-document URL changes (e.g. clicking anchor links) don't update the URL bar if its value has been edited
See https://bugzilla.mozilla.org/show_bug.cgi?id=1199934#c14

STR from bug 1309167:

> Steps to reproduce:
> 
> 1. Login to facebook.com
> 2. Edit the text in URL bar (e.g: edit "https://www.facebook.com" to "test" )
> 3. Now navigate to other page by clicking any button on the page. (Don't
> navigate by typing URL in the address bar)

video: https://bugzilla.mozilla.org/attachment.cgi?id=8800620

(In reply to arni2033 from comment #6)
> STR_2:  (assuming comment 0 is STR_1)
> 1. Open http://example.org/
> 2. Select all text in urlbar, type "asdf"
> 3. Open web console, execute 
> "onclick=()=>{history.pushState("123","123","123");}"  w/o outer quotes
> 4. Click on the page
> 
> AR:  Urlbar displays "asdf"
> ER:  Either X or Y
>  X) Value should change to "http://example.org/123", because user-generated
> event handler changed it
>  Y) Value should change to "http://example.org/123", because urlbar wasn't
> focused
Blocks: 1199934
Priority: -- → P2
Whiteboard: [fxsearch]
In order to fix this the nsIWebProgressListener code that listens for document/location changes will need to be able to determine whether the location change / navigation was triggered by the user via e.g. a click, or not, otherwise fixing this would regress bug 1199934.
Priority: P2 → P3
Points: --- → 3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.