790: Replying to comments sometimes pre-fills with most-recently-added reply text
- Fixed
- Review Board
| timw.a******@gmai***** (Google Code) (Is this you? Claim this profile.) | |
 |
|
| Jan. 2, 2009 |
Latest reviewboard and djblets (at revision 1656)... What's the URL of the page containing the problem? http://site/r/123/ (i.e., the review page) What steps will reproduce the problem? 1. Have a review open which has comments against source code (2 or more in the same file) 2. Compose a reply to one comment in file X (not the last comment for file X); click OK 3. Click 'Add comment' on the next comment in file X What is the expected output? What do you see instead? Expected: after 3, an reply edit box is visible under the comment I just tried to reply to. Actual: after 3, the reply edit box from step 2 re-opens. Further, pressing OK in the box causes an empty, uneditable reply (no "Add comment" link, no pencil icon) to appear in your name under the comment you clicked on. Upon reloading the page shows that the reply from step 2 has been repeated under step 3's comment. However, at this point, you can edit the reply from (3) to make it say what you wanted. What operating system are you using? What browser? Ubuntu 8.10's Firefox 3.0.5 on x86_64. Additional details: I see no javascript errors in the Error Console or in Firebug's console at any point.
I fixed a bug tonight that may very well be related to this. Can you try again in about 20 minutes with the new Review Board nightly (20081231)?
-
+ NeedInfo -
- Priority-Medium + Priority-Critical + Component-Reviews + Milestone-Release1.0 -
+ chipx86
Interesting tidbit:
With Firebug, after adding the first reply and hitting OK (step 2), I noticed <label
for="yourcomment_undefined-draft"> which corresponds to
for="yourcomment_{{context_id}}-{{id}}" in review_reply.html. The nearby 'dd' element
similarly has an undefined context_id.
Actually, I did an svn update 15 minutes ago when I noticed you posted that fix. It did fix the other issue, 787 (which you already marked fixed).
My apologies for the barrage of replies. Upon reloading the page (without publishing the reply), a legitimate ID is present: yourcomment_rc2087-550
Interesting. I'll look into it, but unfortunately I must head to bed shortly (full day tomorrow). I'll try to figure this out tomorrow or the day after.
-
- NeedInfo + Confirmed
I am also getting same issue with latest revision.
I believe I have this fixed in r1660. This will appear in tomorrow's nightly, but it's a one-line change (see the change in r1660 if you wnat to make it in your copy).
-
- Confirmed + Fixed
I did 'svn update' to get r1660 and then restarted apache, and I am still getting the same problem. It looks like it is not fixed yet :-(
Just in case the problem is not clear I will explain what happens. I have a review that has many comments, and when I open this review, each comment has "Add Comment" button. When I press this button next to first comment, a box opens on page allowing me to add comments - I then press OK. The problem occurs when I move to the next comment and press the "Add Comment" button - the box opens for me to type reply to comment, but the box opens under first comment, not under the second comment which I am trying to reply to.
I have discovered that if I reply to comments in different order, e.g. reply to last comment, then previous, then one before previous ... this works fine. It seems that the problem only occurs if I reply to a comment and then reply to one after it ...
Hmm, I'm pretty sure this is taken care of. I can no longer reproduce the problem. Did you clear/bypass your cache? The change was to a single JavaScript file, and it may be that the browser is caching it (which we've definitely seen happen before). Also, I take it you're not using rb-site? We may be making changes to the directory structure in the somewhat near future that will break installs served completely out of SVN. If instead you're running setup.py install from Review Board and Djblets, you're okay.
-
- Fixed + NeedInfo
I cleared the browser cache, tested again, and it now works ... Thanks. Yes, I am using svn and not rb-site. I wondered if you could provide me with a reference to allow me to change my svn installation to rb-site so that I don't miss anything in future updates ?
Glad it works :) The GettingStarted wiki page is the best bet for instructions right now. It has a section on migrating from SVN. There's not much you have to worry about. Move away your existing install directory, then follow the instructions for installing Review Board and creating your site. You can then copy your database file over (if using sqlite) or just enter your database info for MySQL or whatever. Update your installed Apache config file for the site to look like the one provided in the conf/ directory under your new site directory. The main highlights there include the PythonPath variable and the media directories. Upgrades from then on include upgrading ReviewBoard and Djblets packages, re-running 'rb-site upgrade', and restarting Apache. Right now, updating ReviewBoard or Djblets will grab nightlies. Later on, we'll have bleeding edge snapshots (new ones generated on each SVN commit), and releases. Releases will take precedence and you'll need a config option to move back to nightlies, which I'll document when we perform the first release.
-
- NeedInfo + Fixed
Gratuitous confirmation (fixed for me, too). End of meaningful content. To the other reporter here, if you track SVN for the same reason I do (local modifications, including integration code for external systems), using nightlies obviously won't work. The following steps are what I use: 1) svn update 2) ./setup.py build 3) ./setup.py install [--home $HOME if you don't install reviewboard to your global site-packages] If you track local changes to djblets, you may have to repeat steps 2-3 for djblets 4) rb-site upgrade /path/to/site 5) if you use mod_python and don't have PythonAutoReload on, restart Apache
The PythonAutoReload option is only really relevant to web applications written against mod_python specific APIs and which use its internal module import system. It doesn't make any difference for standard Python module imports. Thus you would always need to restart Apache with mod_python in this case and what PythonAutoReload is set to would make no difference.