Just curious why you want this?

It would be nice to have information about how long it takes pages to reach certain amounts of data. It might guide our view of considering throttling large pages that may be open for a long period (e.g., an email service open for weeks vs. a heavy page that eats data within minutes).

+Bengr@, wdyt?

I guess I'm wary of adding more UMA (we have a *lot* of UMA and it's not clear that most of them are used) unless we have a really concrete open design question that hinges on the data. My understanding is that on Android, pages are not open for very long to begin with as the browser is only foregrounded for a minute or so at a time and average usage is less than 20 minutes/day. Just trying to understand our overall strategy here and avoid burdening ourselves with more work/data analysis if we don't know for sure it will be useful.

Part of the design for throttle large page throttling is the choice of halting all URLRequests for a large page until the user gives consent to continue vs the choice of slowing URLRequests for that page to some amount of URLRequests/minute. I am in favor of halting the requests entirely, but it would be informative to have data for the other implementation. I agree that you are probably correct about android for multiple reasons (chrome is backgrounded, tab is backgrounded, tab is purged, etc.), so you are probably correct about this on android. Unless bengr@ thinks this is valuable, I'll hold off on these histograms for the sake of not-increasing UMA-data-use considering this would affect all UMA opted in users.

I agree with mdw@ here. I don't see a need for this UMA.