I validated the same effect. Chrome nails me to the way too close... scary close.
Whereas Firefox missed by about 500 miles and a whole state.
So what gives?
When you dig into the HTML5 geoLocation documentation you'll find that the API is by definition agnostic about the source of your geoLocation service.
It could be a GPS-enabled device, it could be a Cell tower network, it could be via WIFI hotspots, or it could be via Geo-IP.
So with that as a background I formed the hypothesis that Chrome was using WIFI hotspots but Firefox was falling back to GeoIP. (Many sites will easily give you a GeoIP... and sure enough, my GeoIP shows up in Hood Oregon or somewhere far away from where I really am. - Blame this on the ISP I guess.)
So with this info in hand, when I test my geoLocation using Firefox, sure enough: Hood Oregon.
But as I said, when I test my geoLocation using Chrome: Practically spot on.
What I haven't mentioned so far, but what is critical to my hypothesis, is that up until this time, I have been carrying out my tests using my WIFI-enabled laptop.
On to test 2:
Disable WIFI on the laptop, connect the laptop to the router via the ethernet cable, and repeat the above geoLocation test using Chrome.
Results: Chrome places me right where Firefox did, far away in Hood Oregon.
Empirical Conclusion:
Chrome calculates your geoLocation using WIFI hotspots if available, whereas Firefox does not.
The HTML5 GeoLocation API does have a 'High Accuracy' flag, which is set to False by default. Perhaps it is as simple as Chrome is setting this to True, while FireFox is not.
Follow-up question:
How can one snoop the data stream to verify this?