Created attachment 463717 [details] test case See attachment. At first glance, the WebKit/Opera behavior seems more consistent. It matches what you would get in a visible iframe that had no selection in it. Equivalent webkit bug: https://bugs.webkit.org/show_bug.cgi?id=43655
Gecko's selection objects are tied to a presentation; there simply isn't one in a display:none iframe. In particular, you can't select text in such an iframe programmatically, unlike a visible iframe.
That kind of makes sense to me, but if you get the selection and then display:none the iframe, you end up in the same situation (have a Selection object inside a display:none iframe). So you still need to deal with that case anyways. Again, I don't feel strongly about this, but I slightly prefer the consistency of the webkit/opera approach. I'll bring this up on whatwg.
The buggy function, getSelection(), isn't mentioned anywhere in this bug, so it doesn't show up in search results. While you are deciding what the proper behavior is, I think it would be helpful to update the mozilla developer docs on the function: https://developer.mozilla.org/en/DOM/window.getSelection asserts that the function always returns a selection object, which does not reflect the current behavior when display:none is in effect.
It appears getSelection no longer exists in HTML5. I'm not sure what the relevant spec would be.
IE, Webkit, and Opera all seem to agree that every Window has a Selection. This is what the spec says too. Gecko's behavior is more complicated and in the minority, so I haven't changed the spec.