1834218 - a string that is pasted in URL bar gets deleted upon switching to another tab and back

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Dan]

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

Steps to reproduce:

Open new tab, paste some string (text) into URL bar of that tab. Then switch to another tab (a website or another empty tab), and switch back to the tab again where you pasted text into URL bar.

Actual results:

entire posted string/text has vanished.

Expected results:

Text/string should remain until that tab is closed. This was also the browser behaviour before version 113/113.0.1

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alice0775 White]

I was able to reproduce this issue if paste text like Mozilla　Firefox which includes u+3000 ideographic space. And also reproduce if paste text includes new line.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=81bec1bb5b4e34a819dc9159b194f1896edd2436&tochange=22e706c2ff1d4469907bc44c8c1bc256512553e7

Comment 3

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

:daisuke, since you are the author of the regressor, bug 1185358, could you take a look?

For more information, please visit BugBot documentation.

Comment 4

[Dan]

"u+3000 ideographic space" wow, interesting!! Thanks, I hadn't noticed that only that character appears to cause this behaviour.

Comment 5

[Daisuke Akatsuka (:daisuke)]

Thank you very much for the report.
Yes, I also could reproduce this issue. I will take a look at this.

Comment 6

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1834218: Set userTypedValue to the selected browser when pasting value on the urlbar

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/72036585358c
Set userTypedValue to the selected browser when pasting value on the urlbar r=adw

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/72036585358c

Comment 9

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

The patch landed in nightly and beta is affected.
:daisuke, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox114 to wontfix.

For more information, please visit BugBot documentation.

Comment 10

[Daisuke Akatsuka (:daisuke)]

Comment on attachment 9335755 [details]
Bug 1834218: Set userTypedValue to the selected browser when pasting value on the urlbar

Beta/Release Uplift Approval Request

• User impact if declined: When user pastes text having a line break or whitespace except for half-width space on the urlbar, then switches to another tab and back to the original tab, the value in urlbar will be vanished.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The main change is just 4 lines. And the change affects only pasting behavior.
• String changes made/needed: none
• Is Android affected?: Unknown

Comment 11

[Pascal Chevrel:pascalc]

Comment on attachment 9335755 [details]
Bug 1834218: Set userTypedValue to the selected browser when pasting value on the urlbar

Low risk, approved to land on the beta branch before Monday merge to mozilla-release for our RC build, thanks.

Comment 12

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/b36e5390290d

Comment 13

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Reproduced the issue with Firefox 115.0a1 (2023-05-21) (64-bit) on Windows 10x64 by using STR from comment 2. After pasting the Mozilla　Firefox text inside the URL bar and switching to another tab and back to the original one, the URL bar is empty.
The issue is no longer reproducing with Firefox 114.0 RC1 (20230529085652) and 115.0a1 (2023-05-29) on Windows 10x64, macOS 12 and Ubuntu 20.04. Pasting the text from comment 2 or a text that contains a new line and switching tabs will no longer delete the text from the URL bar inside the original tab.

Comment 14

[Dan]

Thank! There's a difference currently though, in 114.0, the STR currently is automatically marked when switching back to the tab containing the STR, while in 115.0a1 (2023-05-30) it is not marked. Wouldn't the intended behaviour be that it isn't marked automatically?

Comment 15

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: tab_switch.gif

(In reply to Dan from comment #14)

Thank! There's a difference currently though, in 114.0, the STR currently is automatically marked when switching back to the tab containing the STR, while in 115.0a1 (2023-05-30) it is not marked. Wouldn't the intended behaviour be that it isn't marked automatically?

Hello! Are you referring to the fact that the pasted string is selected or not after the tab is switched back? It seems that this happens if the tab that we are switching to is a new tab with an empty URL bar or a tab containing a link in the URL bar.
For example:

• when switching to a new tab that has an empty URL bar and switching back to the tab with the string, the string is not selected
• switching to a new tab that already has a loaded page like facebook.com inside the URL bar and switching back to the tab with the string, the string is selected.

I see this happening with Firefox 111.0a1 (2023-02-02) as well so I think that this is not related to this fix at least. Maybe might be worth filling an issue. I can do that if you don't have the time. Thank you very much for your input!

Comment 16

[Dan]

Exactly that issue!! Thanks a lot for this very quick clarification, interesting that it even matters what kind of tab the user is switching from! o_O And yes, since you already have created such a super-helpful .gif and identified the behavior so well, I'd appreciate if you can also file this new issue. And thx a lot for appreciating my input, the FF-community is such a great place! :D

Comment 17

[Alexandru Trif, Desktop Test Engineering [:atrif]]

(In reply to Dan from comment #16)

Exactly that issue!! Thanks a lot for this very quick clarification, interesting that it even matters what kind of tab the user is switching from! o_O And yes, since you already have created such a super-helpful .gif and identified the behavior so well, I'd appreciate if you can also file this new issue. And thx a lot for appreciating my input, the FF-community is such a great place! :D

Thank you as well! I filled in bug 1836051.

Comment 18

[Dan]

Thanks a lot for the very fast fix, Daisuke, can't wait to see this land tomorrow on FF 114 release day! And thanks Alice White for having been so fast in identifying the exact issue and even working out the regression!