On my test profile, I'm seeing some really strange effects with the search mode code.

I think these are the steps to repeat:

1. Have Google set as the default engine, do some searches so that they get saved, e.g. "test"
2. Switch to a different search engine, e.g. amazon.
3. Type "test"
   • Expected: "Search with Amazon", Actual "Search with Google"
4. Click the Amazon one-off
   • Shows Amazon.com test in the address bar.
   • Shows "Search with Google" in the results.
5. Press enter
   • Expected: Searches with amazon. Actual: Address bar contents replaced by the "Google" pill.

I'm guessing it is attempting to revert to saved searches from my history.

I'm not able to reproduce this one. Can you, Drew?

I can reproduce this but only up to step 3. This at least exposes some gaps in our test cases...

Sorry, I was wrong about being able to reproduce this. I did the STR wrong.

The search heuristic is added here, so this bug would indicate that queryContext.searchMode is wrong, like it's getting stuck somehow. But I'm assuming the blue "Google" indicator was not also present in the urlbar, because that would have been visually obvious and you probably would have mentioned it? That would indicate that not only is the search mode wrong, the connection between the indicator and context.searchMode is broken...

I've just found out the missing part of the STR - You need to have Google with an alias of "test". So the refined steps to repeat would be:

1. Have Google set as the default engine, give it an alias "test" in the one-click preferences.
2. Select the Address bar
3. Switch to a different search engine, e.g. amazon.
4. Type "test"
   • Expected: "Search with Amazon", Actual "Search with Google"
5. Click the Amazon one-off
   • Shows Amazon.com test in the address bar.
   • Shows "Search with Google" in the results.
6. Press enter
   • Expected: Searches with amazon. Actual: Address bar contents replaced by the "Google" pill.

Ah, thank you! In that case, this bug has to do with one alias replacing another. I think Drew is working on a few of those bugs at once, solved with a single patch for bug 1658964. Drew, would you consider this to be a duplicate?

This is fixed in the patch, but let's keep it separate for now since it also isn't a clean duplicate.

Thanks Mark!

Bug 1658964 has landed, marking fixed.

I verified this issue using 82.0a1 (2020-09-14) on macOS 10.13 and Windows 10 x64.
Adrian could you help me with Ubuntu verification?

I verified this issue using 82.0a1 (2020-09-15) on Ubuntu 20.04 Taking in account comment 8 and comment 9, marking as verified.