Heads up: Removal of nsIDOMNSUIEvent, nsIDOMNSMouseEvent, nsIDOMNSEvent interfaces

[Ms2ger]

Hi all,

In our continuing effort to remove unnecessary interfaces, I'll be
removing nsIDOMNSUIEvent, nsIDOMNSMouseEvent, and nsIDOMNSEvent, and
moving their members into nsIDOMUIEvent, nsIDOMMouseEvent, and
nsIDOMEvent respectively. Note that, thanks to classinfo, it is not
necessary to QI to these interfaces when using them from script.

If I read MXR correctly, no changes to comm-central will be required.

You can follow along in bug 672054. [1]

Ms2ger

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=672054

[Benjamin Smedberg]

On 8/24/2011 4:52 PM, Ms2ger wrote:
> Hi all,
>
> In our continuing effort to remove unnecessary interfaces, I'll be
> removing nsIDOMNSUIEvent, nsIDOMNSMouseEvent, and nsIDOMNSEvent, and
> moving their members into nsIDOMUIEvent, nsIDOMMouseEvent, and
> nsIDOMEvent respectively. Note that, thanks to classinfo, it is not
> necessary to QI to these interfaces when using them from script.

Have you checked extensions to see if this will cause incompatibilities?
I can't imagine that most extensions would be using these, since they
are automatically flattened, but we should check and perhaps keep a stub
name around just for compatibility if there are major issues.

--BDS

[Christian Legnitto]

On Aug 25, 2011, at 5:17 AM, Benjamin Smedberg wrote:

> On 8/24/2011 4:52 PM, Ms2ger wrote:

>> Hi all,
>>
>> In our continuing effort to remove unnecessary interfaces, I'll be removing nsIDOMNSUIEvent, nsIDOMNSMouseEvent, and nsIDOMNSEvent, and moving their members into nsIDOMUIEvent, nsIDOMMouseEvent, and nsIDOMEvent respectively. Note that, thanks to classinfo, it is not necessary to QI to these interfaces when using them from script.

> Have you checked extensions to see if this will cause incompatibilities? I can't imagine that most extensions would be using these, since they are automatically flattened, but we should check and perhaps keep a stub name around just for compatibility if there are major issues.
>

Is it a big deal just keeping the stub name around? If not, let's just do it by default so we don't have to worry about the compat issue.

Thanks,
Christian

[Jonas Sicking]

On Thu, Aug 25, 2011 at 5:29 PM, Christian Legnitto
<cleg...@mozilla.com> wrote:
> On Aug 25, 2011, at 5:17 AM, Benjamin Smedberg wrote:
>
>> On 8/24/2011 4:52 PM, Ms2ger wrote:

>>> Hi all,
>>>
>>> In our continuing effort to remove unnecessary interfaces, I'll be removing nsIDOMNSUIEvent, nsIDOMNSMouseEvent, and nsIDOMNSEvent, and moving their members into nsIDOMUIEvent, nsIDOMMouseEvent, and nsIDOMEvent respectively. Note that, thanks to classinfo, it is not necessary to QI to these interfaces when using them from script.

>> Have you checked extensions to see if this will cause incompatibilities? I can't imagine that most extensions would be using these, since they are automatically flattened, but we should check and perhaps keep a stub name around just for compatibility if there are major issues.
>>
>
> Is it a big deal just keeping the stub name around? If not, let's just do it by default so we don't have to worry about the compat issue.

It would be a big deal to do that for all interfaces that we're
deprecating, yes. So some sort of migration strategy is needed.

Additionally, i'm not sure how much we increase the compatibility by
keeping empty interfaces around. Not very much I'd imagine. I could
see it hurting as much as helping if addons QI to interfaces and do
proper nullchecking.

/ Jonas

[Benjamin Smedberg]

On 8/25/2011 11:04 PM, Jonas Sicking wrote:
> It would be a big deal to do that for all interfaces that we're
> deprecating, yes. So some sort of migration strategy is needed.

Why? Is that because they are implemented with tearoffs?

>
> Additionally, i'm not sure how much we increase the compatibility by
> keeping empty interfaces around. Not very much I'd imagine. I could
> see it hurting as much as helping if addons QI to interfaces and do
> proper nullchecking.

Ignoring binary extensions, in the past we've seen patterns such as
obj.QueryInterface(nsIDOMWindowInternal) which we tried to remove. I
expect that we might see the same thing here: the JS code will still
work correctly as long as it doesn't throw because of a missing
interface name.

--BDS

[Jonas Sicking]

On Fri, Aug 26, 2011 at 4:55 AM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
> On 8/25/2011 11:04 PM, Jonas Sicking wrote:
>>
>> It would be a big deal to do that for all interfaces that we're
>> deprecating, yes. So some sort of migration strategy is needed.
>
> Why? Is that because they are implemented with tearoffs?

It's just going to leave too much cruft over time. I'm fine with
leaving things in for a few releases, but not indefinitely.

/ Jonas