Documentation for writing fuzz targets in Chromium: https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/README.md


Current test coverage seems to be pretty good: https://chrome-coverage.storage.googleapis.com/chrome/549096_tests_only/coverage/mnt/ram-disk/chromium/src/chrome/browser/vr/elements/report.html

Bot there is no fuzz coverage at all.

mmoroz@, I have a few questions to clarify your expectations.

The general sequence is:
- Browser supplies the current URL to our UI
- We call an unrelated non-VR URL formatter method to prepare the URL for display, and generate the metadata describing where parts of the URL reside.
- Our code takes the metadata and computes the desired offset.

Testing ought to ensure that the boundary point between host and path is always visible.

The purest way to test our code in isolation would be to use a dummy string, and randomly generate metadata, allocating arbitrary parts of the string to scheme, host, path, etc.

A more end-to-end approach would be to write a URL generator, and pump the input through Chrome's formatter, then through our code, and do the same verification.  The downside is that the VR team is now fuzzing code that has nothing to do with the last-mile VR fading code.

In your view, which do you see as ideal here, and why?

Marty (mbarbella@), could you please take a look at this, as I'm quite busy right now with some code coverage bits?

Testing with metadata generated by the fuzzer rather than doing it end-to-end makes the most sense to me.

It might still make sense for us to independently fuzz the url formatter (which I'll look into), but I agree that it doesn't make a ton of sense for the fuzzer for this VR code to be the place to test that.

Acknowledged, and thanks for the quick response!