Closed Bug 838668 Opened 7 years ago Closed 7 years ago

nsIDOMFile should have IID revved

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla21
Tracking Status
firefox19 + wontfix
firefox20 + fixed
firefox21 --- fixed

People

(Reporter: jwir3, Assigned: jwir3)

References

Details

(Keywords: regression)

Attachments

(1 file)

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.
Attachment #710759 - Flags: review?(benjamin)
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
Attachment #710759 - Flags: review?(benjamin) → review+
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.
(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?
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.
(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.
Inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2308bb67a6fa
Assignee: nobody → sjohnson
Target Milestone: --- → mozilla21
(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?
I can't think of any.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> I can't think of any.

OK I'm sending the heads up now.
Presumably an uplift to Aurora is good form at this point (but perhaps unnecessary). Please nominate for uplift if you agree.
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
Attachment #710759 - Flags: approval-mozilla-aurora?
(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).
F-Secure, Avira?
https://hg.mozilla.org/mozilla-central/rev/2308bb67a6fa
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Attachment #710759 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(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.
(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.
.. and don't forget HttpWatch! :)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.