Welcome to the Splat alpha!

This was certainly broken in 1.0.3, but it should definitely be fixed in 1.0.4. I
can't reproduce this at all. Can you make sure to clear your server-side cache? And
can you make sure the web server was restarted since the upgrade to 1.0.4?

• Status:

  +	NeedInfo

Hi, I'm working on the same internal dev server as premek.paska. I've tried to look
on Ajax requests that go to the server. For diff at
https://our.internal-dev-server.cz/rb/r/123/diff/

clicking on three differenct "x lines hidden [expand]" links in first file's diff
yielded request on the same URL: 
https://our.internal-dev-server.cz/rb/r/123/diff/1/fragment/877/chunk/1/
which apparently returns the context lines before first changed line in the file.

"Expand changes" button above the diffs works ok.

I'll add some more info, just for clarity. When I tested 1.0.4 for the first time, I
restarted our Apache server for sure. Since yesterday we had used 1.0.1 (where the
expanding works) and now we tried 1.0.4 again. Expanding doesn't work in FF3.5,
Chrome, nor Opera 10 (after cleaning all caches).

My colleague provided some more specific info above. 

I've noticed a suspicious null argument in the call, is ti ok?
<a onclick="javascript:expandChunk('file5', '1151', '1', null, '4', this); return
false;" href="#">Expand</a>

Is there anything other we should try to investigate the problem?

Yep, that null should be there. That would be the interdiff ID for interdiffs, or
null for normal diffs.

Can you install Firebug and click the Expand link? See if there's any JavaScript
error output, and see what the HTTP response is from the action (if there is one).

There are no JS errors reported by Firebug.

The strange thing is that all Expand links within one file use the same HTTP request:
javascript:expandChunk('file1', '1147', '1', null, '12', this); return false;
.../rb/r/139/diff/1/fragment/1147/chunk/1/

javascript:expandChunk('file1', '1147', '1', null, '19', this); return false;
.../rb/r/139/diff/1/fragment/1147/chunk/1/

The next file:
.../rb/r/139/diff/1/fragment/1148/chunk/1/
.../rb/r/139/diff/1/fragment/1148/chunk/1/
.../rb/r/139/diff/1/fragment/1148/chunk/1/

etc.

And consequently, all responses for different links within the file are the same:

One of them starts with this html code:
 <tbody id="chunk0.1">

  <tr line="26">

   <th>26</th>


   <td><pre><span class="p">{</span></pre></td>
   <th>26</th>
   <td><pre><span class="p">{</span></pre></td>

  </tr>

  <tr line="27">

   <th>27</th>

...

I compared the responses and realized that they always return the first five lines of
the file that are already displayed (first lines of the file's diff). So never the
correct lines.

Sounds like this would be the cause, though it's still not happening here. I'll try
to repro it some more.

• Tags:

  -	Priority-Medium
  +	Priority-High
  +	Milestone-Release1.0.x
  +	Component-DiffViewer

• Status:

  -	NeedInfo
  +	Confirmed

• Assigned to:

  +	chipx86

Fixed on release-1.0.x and master (r331a1bf).

• Status:

  -	Confirmed
  +	Fixed

Unfortunately, I can't confirm the fix. The issue is still present in version 1.0.5
in our installation (tested with Chromium 4.0.222.4, Firefox 3 and 3.5; all in Linux).

The link "Expand" behaves still the same way as in 1.0.4. It is sending wrong
requests as described in comments #2 and #5 above.

I don't see our configuration obscure in any way; it is the following:
Response Headers
Date	Fri, 23 Oct 2009 22:31:23 GMT
Server	Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_jk/1.2.26 PHP/5.2.6-1+lenny3 with
Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9 OpenSSL/0.9.8g
mod_perl/2.0.4 Perl/v5.10.0
Content-Length	232
Content-Language	en-us
Content-Encoding	gzip
Vary	Cookie,Accept-Language,Accept-Encoding
Content-Type	text/html; charset=utf-8
Keep-Alive	timeout=15, max=100
Connection	Keep-Alive

Request Headers
Host	...
User-Agent	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090824
Firefox/3.5.3
Accept	text/html, */*
Accept-Language	en,en-us;q=0.8,fr;q=0.5,fr-fr;q=0.3
Accept-Encoding	gzip,deflate
Accept-Charset	UTF-8,*
Keep-Alive	300
Connection	keep-alive
X-Requested-With	XMLHttpRequest
Referer	https://.../rb/r/171/diff/
Cookie	rbsessionid=ae1bc5f72f8e0af9e9f8de5d857676be; ...

Did you clear both the server-side and client-side caches?

Yes, I restarted both apache and memcached (and tried also disabling memcached),
reloaded the page multiple times, cleared the browser cache and tested it also in
Chromium's incognito mode.. ..just to be sure.

And I think there is not a problem with any cache, because it works immediately after
downgrading to 1.0.1. What about checking changes in the diff viewer between 1.0.1
and 1.0.3?

Things definitely did change between those versions, and I verified that it was
broken. However, I'm no longer able to reproduce this at all since my fix.

I'll attempt to reproduce this some more. Perhaps there's another broken case that
was missed.

• Status:

  -	Fixed
  +	New

• Duplicates:

  +	1384 - expand diff not working in 1.0.5

Using 1.0.5.1 and seeing the same issue reported in comment 2, 5, 10.

The problem seems to be that an old version of diffviewer.js is being served up,
containing an old version of expandChunk() with 4 arguments instead of 6.

I've always installed new versions using "easy_install -U reviewboard", so I was a
bit surprised to find that all the old versions are still present under
   /usr/lib/python2.5/site-packages/
where I see subdirectories for:
   ReviewBoard-1.0-py2.5.egg/
   ReviewBoard-1.0.1-py2.5.egg/
   ReviewBoard-1.0.3.1-py2.5.egg/
   ReviewBoard-1.0.4-py2.5.egg/
   ReviewBoard-1.0.5.1-py2.5.egg/
   ReviewBoard-1.0alpha4-py2.5.egg/
There is a copy of diffviewer.js in each of them.  I'm being served the version from
the ReviewBoard-1.0-py2.5.egg directory (this is evident from looking at the
Last-Modified time stamp in the GET request for diffviewer.js).

Should the old versions be there?  How does reviewboard decide which directory to
serve the static files from?  How do I get rid of the old unwanted eggs?

Could the same problem happen with any other "dependencies" that easy_install pulled in?

Oh, I found it.  Apache has two aliases:
        Alias /media /var/www/rb/htdocs/media
        Alias /errordocs /var/www/rb/htdocs/errordocs

These directories contain symlinks to the wrong ReviewBoard version:
errordocs ->
/usr/lib/python2.5/site-packages/ReviewBoard-1.0-py2.5.egg/reviewboard/htdocs/errordocs
media/ ->
/usr/lib/python2.5/site-packages/ReviewBoard-1.0-py2.5.egg/reviewboard/htdocs/media/admin
media/djblets -> /usr/lib/python2.5/site-packages/Djblets-0.5-py2.5.egg/djblets/media
media/rb ->
/usr/lib/python2.5/site-packages/ReviewBoard-1.0-py2.5.egg/reviewboard/htdocs/media/rb

I don't recall how these links were created... manually or by a script...

I corrected these links and restarted apache, now the "expand changes" buttons work
correctly again.

Ultimate cause of the problem: forgetting to run "rb-site upgrade".  The instructions
on the web site are pretty clear, but nevertheless I still managed to forget this
step, repeatedly.  Oops.

When I ran the upgrade, it took me from 1.0 to 1.0.5.1, including "unapplied
evolutions for diffviewer".  I restarted apache and memcached, everything seems to be
working fine now.

Thanks! This fixes the issue for us, too.

Nevertheless, I'm pretty sure I did run "rb-site upgrade" at each RB upgrade. I
followed the upgrade guide step-by-step before reporting the issue. There must be
some other problem.

• Status:

  -	New
  +	Fixed

I'm seeing this in recent nightlies again. In particular:

ReviewBoard-1.1alpha3.dev_20100121-py2.5.egg
ReviewBoard-1.1alpha3.dev_20100201-py2.5.egg

I had upgraded after running ReviewBoard-1.1alpha2.dev_20091023-py2.5.egg for quite a
while. rb-site upgrade does not fix the problem. There are no javascript errors
reported with Firebug. Confirmed the symlinks in media and errordocs are correct. The
chunk urls are different for each chunk. I'll need to debug further on a test server...

Having the same problem. It was a clean install, rb-site upgrade does nothing (and
odes not fix it).


What version are you running?
1.5beta1


What steps will reproduce the problem?
1. open a review request with a diff (not covering all the lines of a file)
2. view the diff
3. click on the Expand link next to a "Hidden lines" bar inside the diff

What is the expected output? What do you see instead?
The hidden lines should show up. Instead, I have "Loading..." for a while, then
nothing happens. 

What operating system are you using? What browser?
Host: Debian Sarge, python 2.4
Client: Windows XP + Firefox 3.5, Windows 7 + Firefox 3.6, Windows 7 + Chrome, works
in none of these.

Please provide any additional information below.
Debian Sarge, python 2.4, apache2, everything stock, clean install, 100% reproducible.

The bug in 1.1/1.5 is fixed in the 1.5 nightlies.