Reviewing delta between two patchsets doesn't show link for "Next file with change/comment"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a patchset with multiple files
2. Edit some files in the patchset, upload new patchset.
3. Begin code review
4. Change "Left" listbox from Base to "Patch Set 1" and click "Go".
5. Look at the top status bar above the side-by-side diffs.

What is the expected output? What do you see instead?

I'd expect to see the "Next file with change/comment" link in the status bar 
(the link with shortcut key "K").  Instead, I see "no next file with 
change/comment".  In an initial patch set file with a large number of changes, 
it slows things down significantly do iterate through files with no changes in 
the subsequent patches.

What browser are you using?  What version? On what operating system?

Chrome 14, Linux

At what URL are you accessing Rietveld?  (e.g. codereview.appspot.com)
Please note if you are using the Google Apps Labs version (e.g.
codereview.<yourdomain>).

codereview.basis.com (via appspot).

Please provide any additional information below.

Original issue reported on code.google.com by ahaw...@basis.com on 20 Sep 2011 at 4:32

[GoogleCodeExporter]

Original comment by albrecht.andi on 29 Sep 2011 at 9:30

• Changed state: Accepted

[GoogleCodeExporter]

It looks like the label of the link is wrong/misleading. It actually points to 
the next file with comments, but not to the next file with changes.

Original comment by albrecht.andi on 29 Sep 2011 at 9:32

[GoogleCodeExporter]

Thanks for looking at this!

My main observation is this:  it slows the review down to iterate through files 
with no changes when looking only at the diffs between patch set 1 and patch 
set 2.

The way our reviews work is we go through the original changes, we make 
comments, the submitter fixes/defends, and updates the issue.  We do a second 
round reviewing, and wash, rinse, repeat until everything looks good.  If we 
could streamline subsequent rounds, it would make it less painful to review 
changes beyond round 1.  Theoretically, we've also already reviewed the changes 
from round 1, and generally there are many fewer changes for each round.

So your original analysis for this bug is that the label's wrong.  Would you 
consider revising that instead that the functionality is wrong?  I can file an 
RFE if the label is truly in error.

Original comment by ahaw...@basis.com on 29 Sep 2011 at 4:36

[GoogleCodeExporter]

Original comment by albrecht.andi on 6 Apr 2012 at 6:20

• Added labels: Component-UI