1754954 - Page url in address bar doesn't change when navigating to another page with history api

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[stacos5]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

Open any video on youtube.com. Click on address bar and edit the address in any way (e.g. delete a character at the end of the address). After that, without pressing enter or anything, click on a thumbnail for another video.

Actual results:

Another video opened, but the url in the address bar hasn't changed (it's just as it was after editing it). After navigating to any number of other videos, the address stays the same as you left it after editing.

Expected results:

The address should have changed to reflect the new video url.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Szymon Scholz]

Reproduced with UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

However pastebin works well. Navigating in bugzilla with near the same url (just changing bug id) works well too.

Smells YouTube's JavaScript

Comment 3

[Szymon Scholz]

Both React and Angular affects this behavior (similar frameworks too). It's because clicking any link on website is not a http request, i.e. You do not go to another URL, but javascript loads only parts that are missing (and somehow such frameworks edit URL in Address bar).

Tested :

• Angular
• Facebook

Notice that by editing text in Address bar you in fact change it's mode to search (shield and lock dissappears, and loupe appears). Press ESC two times and you are back (with valid Address - in YouTube it's address of current video).

Is that really an issue?

Comment 4

[Drew Willcoxon :adw]

Thanks for filing, I thought we had similar bugs on file but I couldn't find any. Szymon raises a good point about whether we want to update the address bar in this case though. I could have sworn there was similar discussion in the dupe I'm thinking of.

Comment 5

[Mike Kaply [:mkaply]]

From Alice0775 in bug 1910155

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3f585af46d397f19019f4c8d0eb53b546d532d20&tochange=a2e37e6c3ef6f40e27476400eec9d46fc65b0d89

Suspect: a982595313dd6271a23b5798e2bbebf9128e7f55 Neil Deakin — Bug 1598919, move Browser:LoadURI into BrowserTabParent actor, r=mconley

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1598919

:enndeakin, since you are the author of the regressor, bug 1598919, could you take a look?

For more information, please visit BugBot documentation.

Comment 8

[Alice0775 White]

(In reply to Mike Kaply [:mkaply] from comment #5)

From Alice0775 in bug 1910155

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3f585af46d397f19019f4c8d0eb53b546d532d20&tochange=a2e37e6c3ef6f40e27476400eec9d46fc65b0d89

Suspect: a982595313dd6271a23b5798e2bbebf9128e7f55 Neil Deakin — Bug 1598919, move Browser:LoadURI into BrowserTabParent actor, r=mconley

This regression range does not match this bug. I can reproduce this issue even on Firefox60.
However, I assume the root cause is the same as bug 1910155, so I'll leave the duplicate flag as it is.

Comment 9

[Marco Bonardo [:mak]]

There's a potential security concern if a non-trusted site convinces the user to paste a trusted site url into the address bar and then replaces contents with a copy of the trusted site.
We can surely detect history rewriting, though I have doubts we could detect a site dinamically replacing its contents to look like another one.
This can likely be mitigated by having a better indicator that the text shown in the Address Bar is not the currently loaded page, that we also discussed elsewhere.

Fwiw, it looks like a duplicate of Bug 435932, and there's bug 1199934 that should not be regressed.

Then I don't know if the found regression range made things worse. Mike or Alice0775, could you please post STR with a specific site that broke with Bug 1598919?

Comment 10

[Marco Bonardo [:mak]]

Sorry for the many needinfos. What I'm looking for is an example that started working differently with Bug 1598919, as it's true the root cause may be the same, but it's also possible there was a second regression, apart from Bug 435932.

Comment 11

[Alice0775 White]

(In reply to Marco Bonardo [:mak] (away Aug 5-12, Aug 19-21) from comment #10)

Sorry for the many needinfos. What I'm looking for is an example that started working differently with Bug 1598919, as it's true the root cause may be the same, but it's also possible there was a second regression, apart from Bug 435932.

Steps to reproduce:
    1. Open https://www.yahoo.com/
    2. Edit text in address bar
    3. Click a link (e.g. a link in section Stories for you)

Comment 12

[Marco Bonardo [:mak]]

That doesn't look different from the description of Bug 435932 though, thus I'd be surprised if it was working before Bug 1598919.