Closed
Bug 1485987
Opened 5 years ago
Closed 5 years ago
Generated search shortcuts paste links after being copied instead of the string in newtab
Categories
(Firefox :: Address Bar, defect, P1)
Firefox
Address Bar
Tracking
()
VERIFIED
FIXED
Firefox 64
Tracking | Status | |
---|---|---|
firefox61 | --- | unaffected |
firefox62 | --- | wontfix |
firefox63 | --- | verified |
firefox64 | --- | verified |
People
(Reporter: cfogel, Assigned: adw)
References
Details
Attachments
(3 files)
9.44 MB,
video/mp4
|
Details | |
46 bytes,
text/x-phabricator-request
|
mak
:
review+
|
Details | Review |
4.48 KB,
patch
|
pascalc
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
[Affected versions]: - 62.0b20, 63.0a1(build id: 20180823220048) [Affected platforms]: - win 10x64, ubuntu 16.04LTS, macOS 10.13 [Steps to reproduce]: 1. Launch Firefox; 2. Access the newtab page; 3. Click on the button for google or amazon search; 4. Copy the generated string from the address bar "@google "; 5. Paste it anywhere; [Expected result]: - the exact string is pasted [Actual result]: - "http://google/" is pasted [Regression range]: - will check if it's a regression asap [Additional notes]: - attached screen recording with the issue; - the link for google is not working either;
Reporter | ||
Comment 1•5 years ago
|
||
Copying without the space pastes the string properly.
Reporter | ||
Comment 2•5 years ago
|
||
The same behaviour is found for the other @search shortcuts (ex: amazon, bing, duckduckgo, ebay, yandex, twitter)
Reporter | ||
Comment 3•5 years ago
|
||
Not a regression, introduced with 1482205.
Blocks: 1482205
Keywords: regressionwindow-wanted
Comment 4•5 years ago
|
||
Having trouble reproducing on the latest nightly. Tried on both Mac and Windows.
Flags: needinfo?(cristian.fogel)
Reporter | ||
Comment 5•5 years ago
|
||
Still reproducible with current nightly 63.0a1 (2018-08-28), checked over win10. It's really important to copy the space after the string as well, otherwise it will not happen. ex: [@google ] leads to the issue, while [@google] is fine.
Flags: needinfo?(cristian.fogel)
Comment 6•5 years ago
|
||
I can also replicate this on Mac. It doesn't happen if you manually type in "@google " but does if you click through from the search shortcut.
Updated•5 years ago
|
Component: Activity Streams: Newtab → Search
Updated•5 years ago
|
Component: Search → Address Bar
Assignee | ||
Comment 7•5 years ago
|
||
When you type it manually, we end up here in the copy code because this.valueIsTyped is true: https://dxr.mozilla.org/mozilla-central/rev/703546ab6d0cb643028a1ab4fda997b38f38a2e6/browser/base/content/urlbarBindings.xml#1321 But when you click a tile, we end up farther down that method and fix up the value, which is why you end up with a weird pseudo URL. I'm not sure what the best fix is. Maybe urlbar.search() should just set valueIsTyped to true. Is this a high priority for Activity Stream?
Blocks: 1480503
Priority: -- → P3
Assignee | ||
Comment 8•5 years ago
|
||
`urlbar.search` needs to simulate the user's typing. Fire an input event, as we do elsewhere to simulate it.
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → adw
Status: NEW → ASSIGNED
Priority: P3 → P1
Comment 9•5 years ago
|
||
Comment on attachment 9010105 [details] Bug 1485987 - Make urlbar.search() fire an input event. Marco Bonardo [::mak] has approved the revision.
Attachment #9010105 -
Flags: review+
Comment 10•5 years ago
|
||
Pushed by dwillcoxon@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9828a37ea75f Make urlbar.search() fire an input event. r=mak
Comment 11•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9828a37ea75f
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Reporter | ||
Comment 12•5 years ago
|
||
Issue is no longer reproducible on 64.0a1 (2018-09-21) over macOS 10.13.6, Ubuntu 16.04, win10x64.
Status: RESOLVED → VERIFIED
Comment 13•5 years ago
|
||
Drew, this bug is a P1, does it make sense to uplift it to 63 or can it ride the trains to 64? Thanks
Flags: needinfo?(adw)
Assignee | ||
Comment 15•5 years ago
|
||
Approval Request Comment [Feature/Bug causing the regression]: Search shortcut tiles on the new tab page -- bug 1480505 added the blue highlight in the urlbar that this bug is about, and bug 1479806 is the main meta bug for the project [User impact if declined]: The original bug (bug 1480505) landed in 62, and this bug landed in 64. So if declined, users will have to wait for two releases before this bug is fixed. [Is this code covered by automated tests?]: Yes [Has the fix been verified in Nightly?]: Yes [Needs manual test from QE? If yes, steps to reproduce]: See comment 0 [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: Low risk [Why is the change risky/not risky?]: The patch mainly touches a single urlbar function, urlbar.search(), which is only used by the search tiles on the newtab page [String changes made/needed]: None
Attachment #9011031 -
Flags: approval-mozilla-beta?
Comment 16•5 years ago
|
||
Comment on attachment 9011031 [details] [diff] [review] Beta/63 patch Low risk patch fixing a bug in a new 62 feature, uplift approved for 63 beta 9, thanks.
Attachment #9011031 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 17•5 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/5fa1ca7189f9
Updated•5 years ago
|
Updated•5 years ago
|
Flags: qe-verify+
Reporter | ||
Comment 18•5 years ago
|
||
Fix verified with 63.0b9 on win10x64, macOS 10.9, Ubuntu 16.04.
Flags: qe-verify+
You need to log in
before you can comment on or make changes to this bug.
Description
•