Note that it's not clear to me that Gecko's setup here (tying the selection object to the presentation instead of the document) is sane...  There isn't even a concept of "presentation" in the specs right now as things stand.

Fair enough.  It's conceivable for us to be able to move our selection code to attach it to the document rather than its "presentation".  But still I think there are other reasons why getSelection() could be conceived to return null, such as the UA operating in an environment where user selection is not supported.

Anything that returns a usable object in all normal cases and fails in weird cases will break any code that tries to use the API in the weird case, because no code will account for the weird case.  Returning null is only okay if it comes up in common cases, or is logically unavoidable.

I think a Selection should be returned in all cases.  If selection is not allowed, the returned selection should have no ranges in it.  If a script adds a range, the user agent is free to ignore it if selections are not currently supported.  If selections later become allowed, like if the iframe is added to a document, the added range should take effect.  This approach would make author code very likely to work correctly even if selections are not supported.

So I'm inclined to say WONTFIX.  Gecko is what should change here.

Over to you, Ryosuke.

I tend to agree with Aryeh that returning null in getSelection() may break things.  It might be better to add a property to Selection that indicates whether the user could interact with selection or not.

OK, I'm convinced!  :)