Generated search shortcuts paste links after being copied instead of the string in newtab

VERIFIED FIXED in Firefox 63



6 months ago
5 months ago


(Reporter: cfogel, Assigned: adw)


Firefox 64
Dependency tree / graph

Firefox Tracking Flags

(firefox61 unaffected, firefox62 wontfix, firefox63 verified, firefox64 verified)



(3 attachments)



6 months ago
Created attachment 9003794 [details]
2018-08-24 16-14-21.mp4

[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;

Comment 1

6 months ago
Copying without the space pastes the string properly.

Comment 2

6 months ago
The same behaviour is found for the other @search shortcuts (ex: amazon, bing, duckduckgo, ebay, yandex, twitter)

Comment 3

6 months ago
Not a regression, introduced with 1482205.
Blocks: 1482205
Keywords: regressionwindow-wanted
Having trouble reproducing on the latest nightly.  Tried on both Mac and Windows.
Flags: needinfo?(cristian.fogel)

Comment 5

6 months 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)
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.
Component: Activity Streams: Newtab → Search


5 months ago
Component: Search → Address Bar

Comment 7

5 months ago
When you type it manually, we end up here in the copy code because this.valueIsTyped is true:

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 should just set valueIsTyped to true.

Is this a high priority for Activity Stream?
Blocks: 1480503
Priority: -- → P3

Comment 8

5 months ago
Created attachment 9010105 [details]
Bug 1485987 - Make fire an input event.

`` needs to simulate the user's typing. Fire an input event, as we do elsewhere to simulate it.


5 months ago
Assignee: nobody → adw
Priority: P3 → P1
Comment on attachment 9010105 [details]
Bug 1485987 - Make fire an input event.

Marco Bonardo [::mak] has approved the revision.
Attachment #9010105 - Flags: review+

Comment 10

5 months ago
Pushed by
Make fire an input event. r=mak

Comment 11

5 months ago
Last Resolved: 5 months ago
status-firefox64: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64

Comment 12

5 months ago
Issue is no longer reproducible on 64.0a1 (2018-09-21) over macOS 10.13.6, Ubuntu 16.04, win10x64.
status-firefox64: fixed → verified
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)

Comment 14

5 months ago
Yes, this seems OK to uplift.  Will request
Flags: needinfo?(adw)

Comment 15

5 months ago
Created attachment 9011031 [details] [diff] [review]
Beta/63 patch

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?]:

[Has the fix been verified in Nightly?]:

[Needs manual test from QE? If yes, steps to reproduce]:
See comment 0

[List of other uplifts needed for the feature/fix]:

[Is the change risky?]:
Low risk

[Why is the change risky/not risky?]:
The patch mainly touches a single urlbar function,, which is only used by the search tiles on the newtab page

[String changes made/needed]:
Attachment #9011031 - Flags: approval-mozilla-beta?
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 months ago
status-firefox63: affected → fixed
status-firefox62: affected → wontfix
Flags: qe-verify+

Comment 18

5 months ago
Fix verified with 63.0b9 on win10x64, macOS 10.9, Ubuntu 16.04.
status-firefox63: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.