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

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.

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?

Pretty sure this is bug 407888.

Then again, maybe not...

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+

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

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.