This is related to bug 1595641. The case I'm describing here is the same. When we show a nudge on google.com for example, the urlbar input should not be focused initially, and its value should remain the google.com URL. When the user clicks the tip's "got it" button, we need to focus the input and also clear it, so that it's ready for the user to start typing.

We should add a general purpose browser.urlbar.setValue function. We could instead add a clear function, but setValue is much more likely to be useful to more experiment extensions in the future.

This is based on D52612 (bug 1595641)

Hmm, actually there's more to it than this. To open the view and show the tip in the first place, the extension calls search(""), which should clear the input. But I'm noticing that when I load google.com and the tip is shown, sometimes it does and sometimes it doesn't. And that's not to mention the question of whether we should even be clearing google.com from the input when showing the tip in the first place. I'll have to think more about this and maybe ask Verdi for clarification.

Verdi says we should clear the input when showing the tip on google.com. That's good news because it means we don't need a setValue and the extension can just call search(""), as I've been doing in my wip.

However, I'm still seeing when I load google.com and the extension calls search("") that the input isn't always being cleared. It seems to be a timing problem. When I call search on a small timeout, the input is cleared as expected. I'm guessing the URL is being put into the input after I call search.

on which event do you invoke search? It's likely the urlbar is looking at the same or similar event, so it's possible that waiting a tick helps.

On browser.webNavigation.onCompleted (which seems to be the only reliable way of listening for page loads in webextensions). I haven't started to debug it yet. It may end up being easy to work around.

The reason I'm sometimes seeing the input's value being set after I call search is because an onLocationChange sometimes happens right after browser.webNavigation.onCompleted is fired. The onLocationChange stack is:

set value@resource:///modules/UrlbarInput.jsm:945:11
URLBarSetURI@chrome://browser/content/browser.js:3309:3
onLocationChange@chrome://browser/content/browser.js:5483:19
callListeners@chrome://browser/content/tabbrowser.js:823:31
_callProgressListeners@chrome://browser/content/tabbrowser.js:837:22
_callProgressListeners@chrome://browser/content/tabbrowser.js:5518:46
onLocationChange@chrome://browser/content/tabbrowser.js:5936:14
_callProgressListeners@resource://gre/modules/RemoteWebProgress.jsm:75:32
onLocationChange@resource://gre/modules/RemoteWebProgress.jsm:117:10

At first I was using browser.tabs.onUpdated instead of webNavigation, but the reason I switched is that it's impossible to tell with onUpdated when a tab is done loading. google.com fires two onUpdated events where status == "complete". It also fires two events where url is set. And they aren't the same events. But now I'm wondering if I should go back to onUpdated -- somehow -- because maybe it corresponds to these onLocationChange calls.

Maybe it's enough to just wait 200ms or so before calling search. Using a timeout of 0 doesn't always work. Probably 200ms isn't guaranteed to always work either, but it probably should like 99% of the time...?

Waiting on a timer seems fine for the experiment purposes.

All right, I'll wontfix this.