Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add placesHistoryStorage as a history provider #184
This patch adds places as a history provider to the reference browser. As things stand, this will conflict with #40 - that PR hooks up the "generic" provider while this hooks up the "places" provider - I'm assuming that we want the places one, although I'm not sure if there was some intention to have that be configurable?
Because the geckoview changes necessary to collect history haven't landed yet, (a) I haven't tested that part of this patch actually works, and (b) for the awesomebar to work you will need to have copied in a places.sqlite generated by rust code in the app-services repo - but this seems clean enough to think about landing even before we have that set up.
Yeah, let's just land places for the
You should be able to test this entirely if you build the reference browser against the SystemEngine, which fully supports history tracking.
I'm not sure why you'd need to manually copy stuff if you're using GV? Do you mean to actually see some results, right? Because
Also, GV right now will emit title change events, which will be passed on to
I think this is the change to
doh! That file also had a change so
Yes, that's correct - places.sqlite will be created but will not have visit data, so isn't going to find matches.
Hopefully we will do the right thing there now (it's ok to have a place without visits), but we can tackle issues there on the application-services side.