Fix: Update browser extension to use a copy of the DOM

[sarvaje]

Pull request checklist

Make sure you:

• Signed the Contributor License Agreement
• Followed the commit message guidelines

For non-trivial changes, please make sure you also:

• Added/Updated related documentation.
• Added/Updated related tests.

Short description of the change(s)

This PR contains the same commits as #1910 but also add the code to share the code for traverse. The only code to review/comment is 9d40fa6

With these changes, the extension bundle size goes from 6.76MB to 11.4MB. If we stub some packages as request and tough-cookie we can save 1.1MB in the bundle, but we will probably need to work a little bit in the stubs to avoid errors.

[molant]

the extension bundle size goes from 6.76MB to 11.4MB

😱

[molant]

Have you done any tests to measure the difference with this approach in a heave website?

[antross]

@molant - Discussing with @sarvaje earlier I was debating whether we should hold off on migrating the extension until we can move parser-html and traversal support to something lighter than jsdom (e.g. once cheerio has been fixed to have location information - or using the underlying dependencies that cheerio uses directly).

We certainly aren't getting much code savings in this case - seems hard to justify the extra weight at the moment.

And yes, we absolutely should test the before/after to see if there's a noticable performance impact on heavy websites (if we decide to move forward).

[molant]

I think the biggest reason to use this approach was for performance so we should test if this actually improves it or not. If it does then we should start looking into optimizing the bundling process. IIRC we weren't minifying the code and we can probably be more agressive with other configurations.

[antross]

Currently it won't be a performance win as the existing code was able to traverse the native DOM directly in one shot. That changes if/when we decide to move analysis in extension-browser to a worker, though.

[molant]

Maybe we should evaluate contributing back to cheerio to get the location fixed sooner rather than later?

[antross]

Personally I think we may be better off using the underlying components. We don't need much more than basic DOM data and a selectors API, both of which are provided by dependencies of cheerio (htmlparser2, domhandler, domutils, and css-select to be specific - all developed to work together). The jQuery emulation is unnecessary overhead for us.

[molant]

'head :first-child' is the most complicated selector we are using (meta-charset-utf-8) so I guess underlying should be fine.

[sarvaje]

Maybe we should evaluate contributing back to cheerio to get the location fixed sooner rather than later?

cheerio already has this fixed, but is going to be part of the v1.

[molant]

Superseeded by #1943