Refactor nsIDOMNavigator changes for pointer attribute to be in separate interface
When implementing the
navigator.pointer change to nsIDOMNavigator.idl, I noticed that none of the other recent additions to navigator were included in the interface file (e.g., geolocation). Today I noticed that these are actually done in separate interfaces, which expose a single attribute. I assume this was done so as to not alter the UUID for the Navigator Interface, or so as to separate the original definition of Navigator without recent changes. I asked dougt why he chose this method:
20:31 < humph> dougt: question for you 20:32 < humph> what was the reason you extended Navigator using nsIDOMNavigator* (e.g., new interface with single properties) vs dropping on nsIDOMNavigator. Was it to not touch the uuid, or to leave the interface unaltered or ? 20:33 < dougt> humph: its the COM way of doing things. 20:34 < dougt> but, in reality, you could do either 20:34 < dougt> i do not know of anyone looking for a specific uuid 20:34 < roc> these days we just extend the main interface 20:34 < dougt> they usually get the navigator object off of window. 20:34 < roc> we're reducing the number of interfaces 20:34 < dougt> roc: that is good 20:34 < dougt> it does break anyone looking for a specific id 20:34 < dougt> but, i don't think we should support that if it means cost 20:35 < dougt> humph: you should ask jst what he wants to do. 20:35 < khuey> well, you use separate interfaces if you want it to be preffable 20:35 < dougt> that is one way. 20:35 < khuey> indexedDB works like that 20:36 < dougt> for dom/* we should just defer to JST unless we have data that it hurts doing it this way
I emailed jst for his opinion:
Fortunately we're past the time when we were unable to change interfaces and were forced to add more. In your case, I would simply go ahead and change the nsIDOMNavigator interface, but do make sure you bump the IID before the changes land. Also, we recently made the navigator as seen from JS expandable w/o changing the interface by simply registering an XPCOM category, so if that's of any use for you guys that's an option too. I suspect in the case of mouse lock you'll want a binary implementation anyways, so writing this in C++ directly makes sense to me, but if not, there are other options.