"Confirm" button in instant review mode broken

Bug #496578 reported by Daniel Kulesz
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
RevAger
Fix Released
Medium
Unassigned
1.2
Fix Released
Medium
Unassigned

Bug Description

Steps to reproduce:

- Start RevAger 1.1 and create a new review session, then save it.
- Change some preferences: disable auto-updates and auto-saving
- Quit RevAger 1.1
- Start RevAger r28/trunk
- Agree to import old settings
- Enter "Instant Review" mode
- Try to proceed without an attendee (you will get an error message)
- Enter the attendee's name
- Try to proceed (The error message will still be in place)

See the attached Video (you need an ogg player to play it) for a quick demonstration.

Revision history for this message
Daniel Kulesz (kuleszdl) wrote :
Changed in revager:
importance: Undecided → Critical
Revision history for this message
Johannes Wettinger (jojow) wrote :

Daniel, you're really able to find every bug! ;-)

Revision history for this message
Johannes Wettinger (jojow) wrote :

I think it is a permission problem for Unix-based systems. Do you this problem on Windows systems as well?

Revision history for this message
Johannes Wettinger (jojow) wrote :

I've just tried to reproduce this bug, but all is fine! Used system:

Ubuntu 9.10 karmic, 2.6.31-16-generic
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.6.1) (6b16-1.6.1-3ubuntu1)
OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)

I'm going to test it on Windows XP as well.

Can someone else confirm this bug on any system?

Revision history for this message
Johannes Wettinger (jojow) wrote :

For Windows XP with Sun JDK 1.6.0_17 it's working fine. I cannot reproduce the bug on this system as well. So I think this bug is not really critical, because it seems to be present only under special circumstances. So this bug is not a "release blocker" for 1.2 IMHO ;-)

@Daniel: Could you please try to do the following, after the old settings are copied to the new location by RevAger:
* Change into the directory where the ".revager" dir is located.
* Do a "chmod 777 -R .revager" and try it again.

Changed in revager:
importance: Critical → Medium
Revision history for this message
Holger Röder (roederhr) wrote :

I couldn't reproduce this bug with a 'clean' install of RevAger trunk/r28 on MacOS X 10.6.2 (Java 1.6.0_17).

@Daniel: Does this bug only apply to 'upgrade installations' (i.e. installations that use previous versions' data directories)?

Revision history for this message
Johannes Wettinger (jojow) wrote :

I've also tested it for an 'upgrade installation', but there was no problem at all.

Revision history for this message
Johannes Wettinger (jojow) wrote :

Have tested it now on a third system:

Macbook x86, Ubuntu 9.10 karmic, kernel 2.6.31-15-generic
java version "1.6.0_16" (Sun JDK 6)
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)

There's also no chance to reproduce the bug.

Revision history for this message
Daniel Kulesz (kuleszdl) wrote :

Actually after re-trying this once more, I was not able to reproduce this either. Strange...I remember I had the old 1.1-instance of RevAger running at the same moment. Maybe the auto-save feature could have corrupted the import of the settings into the 1.2-instance?

Revision history for this message
Davide Casciato (casciade) wrote :

I have tested it on:

Sony Vaio VGN-NS11S, Windows Vista Home Premium SP2, java 1.6.0_17 (Sun JDK 6)

I also couldn't reproduce this bug.

Revision history for this message
Daniel Kulesz (kuleszdl) wrote :

Finally I was able to reproduce it as well. I started off with the old revager-data dir already, without recreating it in 1.1.

Here is some (not complete) output I captured on the console, after this problem occured.

Revision history for this message
Daniel Kulesz (kuleszdl) wrote :

It seems that the trick is to really make use of the "back" button AFTER entering the attendee's name. Here's are the updated reproduction instructions:

- Start RevAger r30/trunk
- (no need to import 1.1 data, works with plain 1.2 as well)
- Enter "Instant Review" mode
- Try to proceed without an attendee (you will get an error message)
- Enter the attendee's name
- Hit the back botton
- Hit the confirm button
- Enter the attendee's name (since the textfield has been somehow erased?)
- Try to proceed (The error message will still be in place)

Revision history for this message
Davide Casciato (casciade) wrote :

I've detected the problem. After some changes the bug doesn't occurs any more in my local project. Shall i commit my changes, because the trunk is still frozen?!

Revision history for this message
Daniel Kulesz (kuleszdl) wrote :

Depends. I think, once we haven't clarified the policy just commit it directly into the trunk.

Revision history for this message
Johannes Wettinger (jojow) wrote :

@Davide: Yes, commit the change please! ;-) After that the trunk branch is frozen again.

Revision history for this message
Davide Casciato (casciade) wrote :

Ok, it's done. Sorry, i wasn't at home till now.

Revision history for this message
Johannes Wettinger (jojow) wrote :

Thanks Davide! I think it should be clear that we're goin' to rewrite the complete Assistant dialog for the next release. ;-)

Revision history for this message
Johannes Wettinger (jojow) wrote :

PS #17: "next release" in this case: "next major release" = 1.3

Revision history for this message
Daniel Kulesz (kuleszdl) wrote :

The fix seems to work - but occasionally I get a garbled screen, see the attached screenshot. (I am not sure it's related to thix fix, but some more investigation could help)

Revision history for this message
Johannes Wettinger (jojow) wrote :

@Daniel: Is this bug reproducible somehow?

Revision history for this message
Daniel Kulesz (kuleszdl) wrote :

Well I wished it would be :-) I succeeded in reproducing it twice by just navigating around in the wizard. Unfortunately, it does occur only occasionally. Maybe a threading issue?

Revision history for this message
Johannes Wettinger (jojow) wrote :

In the past we had similar problems with Swing (in combination with threading by SwingWorker classes), before we structured the thread handling. I think it's very difficult to detect the real source for this kind of bugs.

Changed in revager:
status: New → Fix Committed
Changed in revager:
status: Fix Committed → Fix Released
Revision history for this message
Daniel Kulesz (kuleszdl) wrote :

Let's continue with the threading issues here, since it seems to be independent from the original bug:

https://bugs.launchpad.net/revager/+bug/499309

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.