Open Bug 1814946 Opened 1 year ago Updated 5 months ago

Edge - Don't list resources for import when those resources won't actually bring things over


(Firefox :: Migration, enhancement)





(Reporter: kpatenio, Unassigned)


(Depends on 1 open bug)



(1 file)

We want to return resource objects only if a resource has actual data inside. The Edge migrator has its own implementation of
getResources that tries to get various bits of information from a profile on Edge:

  • bookmarks
  • cookies
  • history
  • reading list (although no longer supported, they're saved as favorites)
  • passwords

Let's not worry about cookies since there's Bug 1801051 for removing cookie references. One thing that stands out from the other migrators is the existence of EdgeTypedURLMigrator and EdgeTypedURLDBMigrator in the resource list. Both of these seem linked to history, given the resource type label MigrationUtils.resourceTypes.HISTORY.

Severity: -- → N/A
Assignee: nobody → angelvillalobos1995

So a bunch of the infrastructure for this is already in place. It looks like the Edge migrator resources each have these exists methods defined on them, and after constructing the migrator resource list, its filtered for only resources that exist:,539

So I think the work here is to make the exists methods a bit more comprehensive, because they're very simple right now.

For example, the EdgeTypedURLMigrator already seems to check that there are some typed URLs to migrate:

So there's nothing to do there.

The rest of the migrators all just test for the existence of a pointer to an "ESE" database (this is a Microsoft-specific database technology where Edge Legacy stores information). What I think we need to do is to teach our ESE database reader library to be able to determine how many rows are inside of a table, so that we check both for the existence of the db AND the size > 0 for these exists functions to return true.

Interestingly, our ESE database reader library is written in JavaScript, but uses a privileged library called "js ctypes" to make it so that our JavaScript can call into native function calls within DLLs like esent.dll (that's an ESE database library) and kernel32.dll:

I think what we're going to want to do here is augment our ESEDBReader to expose a new function that forwards to JetIndexRecordCount, which is an ESE function that lets us get the number of records in a particular database table. That should get us what we need to do those exists calls.

The way to make the JetIndexRecordCount function available to the library first starts by declaring it in this function:

Here's an example of an ESE function for JetGetDatabaseFileInfo being declared: Notice that it doesn't start with "Jet" on the function name - that's because for some reason it's being automatically pre-pended in this helper function:

We'll also probably want to use the "wide" version of the method, so we should declare for "IndexRecordCountW". This is a weird quirk of win32 for making sure any strings are Unicode:

So we're going to want to do a similar declaration for JetIndexRecordCountW, making sure we get the arguments right. Then, we need to expose that function to consumers of ESEDBReader. That means adding a new function here:

and having it call ESE.IndexRecordCountW, passing in the right arguments and returning a number.

Then, when that's done, we can update the resources in EdgeProfileMigrator to call that method to check that there exist some rows in the databases, and using that to make a more refined judgement on whether "exists" is true or not.

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: angelvillalobos1995 → nobody
You need to log in before you can comment on or make changes to this bug.