Bug 884502

Summary: navigation breaks in filter mode after saved status not included in filter view
Product: [Retired] Zanata Reporter: Runa Bhattacharjee <runab>
Component: Component-UIAssignee: Patrick Huang <pahuang>
Status: CLOSED CURRENTRELEASE QA Contact: Ding-Yi Chen <dchen>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 2.0CC: ankit, pahuang, zanata-bugs
Target Milestone: ---   
Target Release: 2.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 2.1-SNAPSHOT (20121217-0033). Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-26 04:06:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Runa Bhattacharjee 2012-12-06 10:16:57 UTC
Description of problem:

Given the user has chosen the checkbox to save and move to the next string with the 'Enter' key, for a project with multiple pages this feature stops working after the 1st string of the 2nd page.

Version-Release number of selected component (if applicable):

Zanata 2.0 

How reproducible:


Steps to Reproduce:
1. Open a project with multiple pages on the translation editor
2. From the 'Editor Options' , choose the 'Untranslated' and/or 'Needs Review' filters
3. Select the checkbox for 'Enter key saves immediately'
4. Translate the last string (or maybe a couple more ahead of it) of the 1st page and for each press the 'Enter' key to save and move to the next page.
5. When the focus moves to the 1st string of the Next page, translate and save using the 'Enter' key again, to continue moving to the 2nd string.
  
Actual results:

The 1st string of the second page is saved, but does not move to the next string

Expected results:

The 1st string of the second page is saved and the focus moves to the next string.

Additional info:

Comment 1 Runa Bhattacharjee 2012-12-06 10:17:41 UTC
Verification and technical evaluation requested.

Comment 2 Patrick Huang 2012-12-10 01:05:04 UTC
It's a caching issue. After we optimize the system to do pagination in database, once saved as approved in first page, then go to second page, all the content state index has changed (the one just saved as approved is no longer part of the result set). We have two options here:
1. reload navigation index everything we change page (more overhead on performance especially for large document)
2. navigation index cached on client side need to be smarter. i.e. when calculate next/previous index, taking into account there may be some updated rows that has changed its state and should not be consider as part of the result set.

I am evaluating both solution and see which one better solve the problem.

Comment 3 Patrick Huang 2012-12-10 23:46:38 UTC
committed into master:
https://github.com/zanata/zanata/commit/d369ba4b599a500edfde0d3ab2b28a67ecf8291a
https://github.com/zanata/zanata/commit/9cc04362337a9a46703e87ad1f1b0ec3cfa8961d

I combine both options mentioned above. It doesn't cause much performance overhead and we can ensure correctness.

Comment 4 Ding-Yi Chen 2012-12-17 02:17:20 UTC
Runa,

After I tested Zanata version 2.1-SNAPSHOT (20121214-0032).

The actual behavior changed to: 
 After you translated the last entry and press enter, the page reload and filled with another untranslated entries (and/or fuzzy, depending on your filter setting), and you are still in the same page at the N-M+1 th entry, where N is the page size, and M is the number of message you translated in that page.

For example, you are in page 1, and the doucment has 100 untranslated entries and the page size is 10.

Scenario 1
You translated message 8~10, and press enter on the 10th entry.
Then message 1-7 and 11-13 is shown in page 1, and the cursor is at the 8th position (message 11)

Scenario 2
You translated message 1~10, and press enter on the 10th entry.
Then message 11-20 is shown in page 1, and the cursor is at the 1st position (message 11)

Indeed, this might confuse many users. Yet I don't think we can do what you want with current message filters.




That is, in your bug reproduce step 4, it 

1. Open a project with multiple pages on the translation editor
2. From the 'Editor Options' , choose the 'Untranslated' and/or 'Needs Review' filters
3. Select the checkbox for 'Enter key saves immediately'
4. Translate the last string (or maybe a couple more ahead of it) of the 1st page and for each press the 'Enter' key to save and move to the next page.
5. When the focus moves to the 1st string of the Next page, translate and save using the 'Enter' key again, to continue moving to the 2nd string.

Comment 5 Ding-Yi Chen 2012-12-17 02:27:33 UTC
Please ignore the last paragrah of my last comment.

We might be able to , however, provide an additional message filter/mode, namely, to-do list mode.

It shows what the messages that were fuzzy and untranslated before you load this document.

However, challenges of this approach are:
1. Multiple login: If you sign in from different computers, it may cause confusion.
2. Multiple users: If someone changed the document just before you finish loading, it may cause problem.
3. Performance: This function may consume system resources, which slow the system.

Comment 6 Ding-Yi Chen 2012-12-17 02:32:22 UTC
Tested Zanata version 2.1-SNAPSHOT (20121214-0032)

It is very slow on latter pages with the big projects like freeciv.

With firefox, dialog "Warning: Unresponsive script" keep poping up when working on the last and second last pages.

Reassigned.

Comment 7 Patrick Huang 2012-12-17 03:49:01 UTC
The slowness is not related to this bug. Even if you turn off message filter, it's still slow in last few pages (Firefox only). I am investigating the cause. 

(In reply to comment #6)
> Tested Zanata version 2.1-SNAPSHOT (20121214-0032)
> 
> It is very slow on latter pages with the big projects like freeciv.
> 
> With firefox, dialog "Warning: Unresponsive script" keep poping up when
> working on the last and second last pages.
> 
> Reassigned.

Comment 8 Patrick Huang 2012-12-17 04:05:17 UTC
Suspect cause of slowness: unnecessary logging of large data.

Comment 9 Ding-Yi Chen 2012-12-17 04:58:02 UTC
The slowness is tracked with Bug 887718, and this bug should be verifed according to the functionality.

Please file a new RFE if you do want the todo list filter/mode.

Verifed with Zanata version 2.1-SNAPSHOT (20121217-0033).