851302 - Check for any missing IID changes with changed interfaces for Fx21(Aurora)

Status: RESOLVED WORKSFORME

(Core :: General, defect, P3)

Description

[bhavana bajaj [:bajaj]]

* The automated hook for this is getting ready as a part of Bug 477166
* We need a manual comparison each time until Bug 477166 is resolved 
 
For FX21,compare the current tree(mozilla-aurora) against the previous release and see if any IID changes are missing before Fx21 beta1. Steps to do this will be posted in this bug by :jwir3 :)

Comment 1

[Scott Johnson (:jwir3)]

I apologize for the complicated nature of these instructions, but I'm kind of caught between iterations of the checkiid.py script, and been tasked with other things at the moment, so I haven't had time to update it in a while.

The steps for performing this are as follows (note: you'll need both mozilla-aurora and mozilla-central branches on your local system):

1) Get a list of changes to IDL files from Fx20->Fx21 by running the command (from your mozilla-central repository): 
> hg out /path/to/mozilla/aurora > /tmp/non-uplifted.diff
2) Open /tmp/non-uplifted.diff and determine the first changeset that you want to use. Usually this has a comment like 'Merging in version bump' or something that indicates that there was a version change. In the example I'm doing right now, it's rev 122317:5646fbea11b3.
3) Using the rev that you just found, run the following in your local mozilla-central clone:
> hg diff -r <rev> -r tip set:**idl > /tmp/aurora-diffs.diff
4) Download the script checkiid.py from http://people.mozilla.org/~sjohnson/scripts/checkiid.py
5) Run the following command from your mozilla-central repository:
> cat /tmp/aurora-diffs.diff | python /path/to/checkiid.py $(hg root)
6) The result of this will likely be something along the lines of a series of lines that say:
>  Interface 'XXXXXX' has changes and a modified IID. Looks good.
these lines can be ignored. You may also get a series of lines that look like:
> ERROR: Interface 'XXXXXX', in file 'YYYYYY.idl' needs a new IID
Open the /tmp/aurora-diffs.diff file, and do a search for each of the interfaces for which you get an error. This sucks, but because of the current lack reliability of the script, each of these will need to be manually inspected to determine if they need an IID change. Chances are they don't, and that these are false positives. If any of the following are true, the interface does not need an IID change:
   a) Changes to the interface are comments only (this should be picked up by the script).
   b) Changes to the interface are all one of the the IDL 'descriptors' listed here: https://developer.mozilla.org/en-US/docs/XPIDL#Source_and_Binary_Compatibility AND the descriptors are marked as 'Changes Binary Compatibility = N' in the table.
   c) The file listed is actually a webidl file. If the file that the interface resides in is a webidl file, then we can just ignore this (since webidl files don't have IIDs). The script needs to be modified to account for this, and it's an easy change, just one I haven't gotten to, yet.
For example, in the run that I did just now, the following was listed as a change needing an IID rev:
> ERROR: Interface 'nsIZipReader', in file 'nsIZipReader.idl' needs a new IID
but, searching for 'nsIZipReader' in /tmp/aurora-diffs.diff shows that the only changes to this interface are comments, so this one can be safely ignored.
As a counter-example, the following was listed as a change needing an IID rev:
> ERROR: Interface 'nsIDOMMozIccManager', in file 'nsIDOMIccManager.idl' needs a new IID
and searching through the file showed me that there is a change to this file that really should have an IID change accompanying it, but doesn't. This should be filed as a bug.

I would advise everyone working with this script that it's REALLY unstable right now. That said, it always defaults to making something a false positive, rather than a false negative. (i.e. it's quite unlikely that an interface that requires an IID change but doesn't have one won't be reported). That said, I would still use this as a guide so that you don't have to look through every interface that changed between one version of firefox and another, but not as something that can be relied upon (yet) as giving no false-positives.

If you get any errors (especially python errors of the form 'Traceback... blah blah'), please email them to me or post them as attachments to bug 477166 (along with the file you ran it on, and the command you used to run the script).

Comment 2

[Scott Johnson (:jwir3)]

Attachment: checkiid.py

(In reply to Scott Johnson (:jwir3) from comment #1)
> 4) Download the script checkiid.py from
> http://people.mozilla.org/~sjohnson/scripts/checkiid.py

Apparently, the server doesn't allow .py scripts to be accessed, so I renamed it to checkiid.pys. I've also attached it to this bug, if that's more convenient.

Comment 3

[Scott Johnson (:jwir3)]

Attachment: checkiid.py

Better version of the script that doesn't have problems checking comment blocks.

Comment 4

[Scott Johnson (:jwir3)]

Attachment: checkiid.py

New version of the script that has debugging turned off.

Comment 5

[Scott Johnson (:jwir3)]

Attachment: diff.diff

Guh.. the script isn't working how I would expect. Sorry, I just haven't had time to devote to bug 477177 lately.

Anyway, here are the interfaces I think that need IID revs, based on the fact that, from the attached diff file, they have changes that would warrant an IID change, and they didn't have one:

nsIB2GKeyboard
nsIXMLHttpRequestUpload
nsIDOMMozIccManager
nsIDOMEventTarget
nsIDOMSVGUnitTypes
nsIBackgroundFileSaver
nsICookiePermission (not sure if constants change binary compat, I would expect so)
nsIPrintSettings

Comment 6

[Scott Johnson (:jwir3)]

Re-assigning to bajaj for handling within releng.

Comment 7

[Scott Johnson (:jwir3)]

Removing bug 477166 as blocking because it's not going to be finished by Fx21, and it doesn't realistically block this bug.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Comment 11

[Andrew McCreight [:mccr8]]

I don't think this is relevant any more, so I'm going to close it.