Refactor nsIDOMNavigator changes for pointer attribute to be in separate interface

From CDOT Wiki
Jump to: navigation, search

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.