Bug 12364 – Frontend allows illegal moves in general

Bug 12364 - Frontend allows illegal moves in general


Summary:	Frontend allows illegal moves in general

Status:	CLOSED FIXED

Product:	Miniature
Component:	UI
Version:	master
Platform:	All Harmattan

Importance:	High major (vote)
Target Milestone:	0.4
Assigned To:	Michael Hasselmann
QA Contact:	general

URL:
Keywords:

Depends on:
Blocks:	12342
	Show dependency tree

Reported:	2011-09-01 01:23 UTC by Uwe Kaminski
Modified:	2011-09-18 07:57 UTC (History)
CC List:	3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description Uwe Kaminski (reporter) 2011-09-01 01:23:58 UTC

EXACT STEPS LEADING TO PROBLEM: 
1. Run Minature
2. Selct "join as guest"
3. Select "New" to create a new game and confirm tapping to the created list
entry
4. Tap on e4
5. Tap on e7

EXPECTED OUTCOME:
A visual signal that this move is illegal. Move is not executed. White has to
choose an other (legal) move.

ACTUAL OUTCOME: 
Pawn is moved to e7 (substituding the black pawn). It's possible to go on with
the game using a black piece.

REPRODUCIBILITY: 
always

Comment 1 Quim Gil 2011-09-01 01:31:04 UTC

You're doing this in "Testing mode" or in real games?

Comment 2 Uwe Kaminski (reporter) 2011-09-01 03:18:54 UTC

Uhm... in testing mode. but maybe it's time to try out it in real games. What
is the best way to get precise information about the difference between both
modes?

Comment 3 Michael Hasselmann 2011-09-01 03:24:41 UTC

No move validation yet, but what I will do for 0.4 is to parse the FICS
response for each submitted move and then, for invalid moves, just reset the
position or so. Next on my list.

Comment 4 Quim Gil 2011-09-01 18:01:42 UTC

Setting as High since this is a problem that we need to fix at least on a
minimum level for 0.4.

Comment 5 Quim Gil 2011-09-01 20:07:52 UTC

(In reply to comment #3)
> No move validation yet, but what I will do for 0.4 is to parse the FICS
> response for each submitted move and then, for invalid moves, just reset the
> position or so. Next on my list.

The UI for this can be as simple as running the wrongTap red effect on both the
origin and destination squares right before moving the piece(s) back.

Comment 6 Michael Hasselmann 2011-09-01 23:44:43 UTC

(In reply to comment #5)
> (In reply to comment #3)
> > No move validation yet, but what I will do for 0.4 is to parse the FICS
> > response for each submitted move and then, for invalid moves, just reset the
> > position or so. Next on my list.
> 
> The UI for this can be as simple as running the wrongTap red effect on both the
> origin and destination squares right before moving the piece(s) back.

I thought of just displaying an invalid move message for now. That's at least
easy for me to do. Well, and perhaps this can be done entirely in the UI then,
the red square flashing: Upon receiving that message, you need to highlight the
last two selected squares.

Comment 7 Quim Gil 2011-09-01 23:49:34 UTC

No worries, you start with the message or whatever is easiest for you and I
will continue from there, if needed.

Comment 8 Michael Hasselmann 2011-09-02 02:27:52 UTC

Fixed with 176516a507729b47a6e102daeeb14feacf4c8802, for FICS games at least.

Comment 9 Uwe Kaminski (reporter) 2011-09-02 10:02:06 UTC

Works great as it is.

If I try to do a false move by:
1a) tapping on an origin field in my own color or
1b) tapping on an origin field in the opponents color
2a) tapping on a target field which is not compliant to the rules
2b) tapping somewhere

The piece "jumps" back to the origin field immediately. I checked the same in
eboard on my desktop an it handles wrong turns in the same way.

Not sure if we need the red flash solution proposed in comment 6.