838668 - nsIDOMFile should have IID revved

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Scott Johnson (:jwir3)]

Attachment: patch to fix this bug

From the merge from Firefox 18 -> Firefox 19, changeset cf1bbed http://hg.mozilla.org/mozilla-central/rev/cf1bbed46731 changed the nsIDOMFile interface, but incorrectly changed the nsIDOMBlob interface IID.

Since then, it doesn't look like nsIDOMFile.idl has been touched on m-c. We should restore the IID for nsIDOMBlob and rev the IID for nsIDOMFile instead.

Comment 1

[Benjamin Smedberg]

Comment on attachment 710759 [details] [diff] [review]
patch to fix this bug

Don't undo the nsIDOMBlob change, just keep it and rev nsIDOMFile also. r=me with that change

Comment 2

[Alex Keybl [:akeybl]]

My understanding is that this is not a critical issue for FF19/20 and we can leave those untouched. Please set tracking-firefox19 if that isn't the case.

Comment 3

[Scott Johnson (:jwir3)]

(In reply to Alex Keybl [:akeybl] from comment #2)
> My understanding is that this is not a critical issue for FF19/20 and we can
> leave those untouched. Please set tracking-firefox19 if that isn't the case.

Hm, I'm not sure that's the case. This is actually an issue that I found in the diff between FF17->FF18 merge, using a new IID checking script I wrote. So, it's entirely possible that this could cause a similar issue that we saw in the Norton crashes after the FF18 release. 

Bsmedberg, do you have thoughts on this?

Comment 4

[Benjamin Smedberg]

The original changeset happened in FF19. So this somewhat equivalent to the problem in FF18 with nsIPrefBranch. But it's exceedingly unlikely that any binary code is using nsIDOMFile, and we're helped by the nsIDOMBlob IID changing, which most clients will have to have first. So I don't think we should take any patches in 19 beta to fix this. Maybe we should inform the few clients who use binary API wrappers, though.

Comment 5

[Scott Johnson (:jwir3)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> The original changeset happened in FF19. So this somewhat equivalent to the
> problem in FF18 with nsIPrefBranch. But it's exceedingly unlikely that any
> binary code is using nsIDOMFile, and we're helped by the nsIDOMBlob IID
> changing, which most clients will have to have first. So I don't think we
> should take any patches in 19 beta to fix this. Maybe we should inform the
> few clients who use binary API wrappers, though.

Yep, sorry, I meant the FF18->FF19 merge.

Comment 6

[Scott Johnson (:jwir3)]

Inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2308bb67a6fa

Comment 7

[Alex Keybl [:akeybl]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> Maybe we should inform the
> few clients who use binary API wrappers, though.

So Skype, Norton, any others come to mind?

Comment 8

[Benjamin Smedberg]

I can't think of any.

Comment 9

[Alex Keybl [:akeybl]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> I can't think of any.

OK I'm sending the heads up now.

Comment 10

[Alex Keybl [:akeybl]]

Presumably an uplift to Aurora is good form at this point (but perhaps unnecessary). Please nominate for uplift if you agree.

Comment 11

[Scott Johnson (:jwir3)]

Comment on attachment 710759 [details] [diff] [review]
patch to fix this bug

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 793955
User impact if declined: Possibly binary incompatibility
Testing completed (on m-c, etc.): None, yet.
Risk to taking this patch (and alternatives if risky): It changes an IID, but nothing else, so it's low risk in terms of code stability, but moderate risk in terms of maintaining binary compatibility. 
String or UUID changes made by this patch: IID change to nsIDOMFile

Comment 12

[Scott Johnson (:jwir3)]

(In reply to Alex Keybl [:akeybl] from comment #7)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> > Maybe we should inform the
> > few clients who use binary API wrappers, though.
> 
> So Skype, Norton, any others come to mind?

Is Comcast's toolbar/plugin a binary plugin? (I just remember having issues with a Comcast plugin a while ago, but it could be unrelated).

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

F-Secure, Avira?

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/2308bb67a6fa

Comment 15

[Alex Keybl [:akeybl]]

(In reply to Olli Pettay [:smaug] from comment #13)
> F-Secure, Avira?

I don't have any contacts here, but will try to dig some up.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/2a137b3c2d0d

Comment 17

[Alex Keybl [:akeybl]]

(In reply to Alex Keybl [:akeybl] from comment #15)
> (In reply to Olli Pettay [:smaug] from comment #13)
> > F-Secure, Avira?
> 
> I don't have any contacts here, but will try to dig some up.

Kev sent me contact details for both F-Secure and Avira, so I've reached out to them.

Comment 18

[Mohd Rozi]

.. and don't forget HttpWatch! :)