Partial selection starting from beginning of address includes the https:// protocol when untrimmed
Categories
(Firefox :: Address Bar, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox125 | --- | unaffected |
firefox126 | --- | unaffected |
firefox127 | --- | disabled |
firefox128 | --- | verified |
People
(Reporter: ke5trel, Assigned: mak)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [sng][search-regression])
Attachments
(2 files)
STR:
- Visit https://bugzilla.mozilla.org.
- Select the "bugzilla" subdomain in the address.
Expected:
Only "bugzilla" is selected.
Actual:
The protocol is added to the selection, resulting in "https://bugzilla".
Only happens when the first character in the address is selected, selecting "ugzilla" works as expected.
Does not happen on Chrome.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=40423991307494c32432a8410d02b2751e124a97&tochange=96d4e09e124215e9af45acf8dc6507e7a9fcf239
Regressed by Bug 1848715.
Comment 1•7 months ago
|
||
:mak, since you are the author of the regressor, bug 1848715, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Updated•7 months ago
|
Updated•7 months ago
|
Assignee | ||
Comment 2•7 months ago
•
|
||
This was actually on purpose, as one may be copying the beginning of the url, like just the domain for example, or a partial path.
The behavior in Chrome apparently differs depending on the selection being a trimmed url or not, as if I select "bugzilla.org" or just "bugzilla" it's doing different selection. That's not really discoverable though, so the preferred behavior is debatable.
I can see the reason for their behavior, we'll evaluate if it's worth it.
It makes no sense to include the protocol for something that does not resemble an address. The "https://bugzilla" selection in this case has no practical value and deleting it so the subdomain can be changed needlessly removes the protocol. The user expects to be able to select a subdomain and copy/edit it like before without untrim interference.
Assignee | ||
Comment 4•7 months ago
•
|
||
Editing the subdomain is indeed a valid use case. That is likely the reason they differenciated the behavior.
It's unfortunate the reason for that different behavior is quite obscure for the non technical user.
Assignee | ||
Comment 6•7 months ago
|
||
Yes, we should fix it, we can use URIFixup here.
Though it's not super important for the fix to be in 127, as the change is nightly only. We'll do asap.
Updated•7 months ago
|
Assignee | ||
Updated•7 months ago
|
Assignee | ||
Comment 7•7 months ago
|
||
Comment 9•7 months ago
|
||
bugherder |
Comment 10•7 months ago
|
||
The patch landed in nightly and beta is affected.
:mak, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox127
towontfix
.
For more information, please visit BugBot documentation.
Assignee | ||
Updated•7 months ago
|
Comment 11•7 months ago
|
||
Reproducible on a 2024-04-28 Nightly build on Windows 10.
Verified as fixed on Firefox Nightly 128.0a1 on Windows 10, macOS 12, Ubuntu 22.
Description
•