Issue 122251 – [sidebar] In Properties frame scrolling with cursor <DOWN> past Number Format property panel changes the active cell on of current sheet [ia2]

Issue 122251 - [sidebar] In Properties frame scrolling with cursor <DOWN> past Number Format property panel changes the active cell on of current sheet [ia2]


Summary:	[sidebar] In Properties frame scrolling with cursor <DOWN> past Number Format...

Status:	RESOLVED FIXED

Product:	Calc
Classification:	Application
Component:	ui
Version:	4.0.0-dev
Hardware:	All All

Importance:	P3 Normal (vote)
Target Milestone:	4.0.0
Assigned To:	AOO issues mailing list
QA Contact:

URL:
Keywords:	accessibility

Depends on:
Blocks:	[sidebar]
	Show dependency tree / graph

Reported:	2013-05-07 21:28 UTC by V Stuart Foote
Modified:	2013-07-11 13:57 UTC (History)
CC List:	3 users (show)

See Also:
Issue Type:	DEFECT
Latest Confirmation in:	---
Developer Difficulty:	---

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

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

Description V Stuart Foote 2013-05-07 21:28:47 UTC

Observed action:

The active cell of current sheet changes in response to cursor movement through the Sidebar property panels.

Steps to reproduce:

With a Calc sheet open and <F6> navigation into sidebar panel, cycling through default property panels: Text -> Allignmment -> Cell Appearance -> Number Format property panels and back to Text using a cursor <DOWN> key incorrectly changes the active cell, e.g. from A1, -> A2, -> A3, etc. with each cycle past Number Format panel. It does not reverse when using the cursor <UP> and cycling back around.

Expected action:

Cell active when opening the sheet to remain the active cell while any Sidebar property changes are being made. To not have any change of active cell on sheet until focus is returned from Sidebar to the current sheet.

Comment 1 V Stuart Foote 2013-05-07 21:30:51 UTC

Marking as unconfirmed because that is nicer for my own bug submission.

Comment 2 V Stuart Foote 2013-05-07 21:35:44 UTC

Observed on Windows 7, 64bit with JRE 1.6.45 and JAB 2.0.2 configured.
Apache OpenOffice 4.0 build AOO400m1(Build:9700) - Rev. 1478648

and also on RHEL 5.9 (Centos)
Apache OpenOffice 4.0 AOO400m1(Build:9700)
2013-05-03 07:08:08 (Friday, 3 May 2013) - Linux x86_64

OSX not tested.

Comment 3 Andre 2013-05-08 11:28:18 UTC

I can reproduce this problem even after my recent improvements to focus traveling in the sidebar.  When the focus is in the tab bar, then all key events seem to be processed both by the tab bar (actually by the FocusManager *for* the tab bar) and the Calc edit view.

Comment 4 SVN Robot 2013-05-08 11:59:58 UTC

"af" committed SVN revision 1480241 into trunk:
122251: Prevent key events from being forwarded from sidebar tab bar to Calc.

Comment 5 SVN Robot 2013-05-08 12:01:43 UTC

"af" committed SVN revision 1480243 into trunk:
122251: Avoid compiler warning.

Comment 6 Andre 2013-05-08 12:03:06 UTC

Looks like Calc is listening for events from all windows not just its edit window.  A Notify() method seems to prevent the key events to be processed by Calc, so I added one to class TabBar.

Comment 7 V Stuart Foote 2013-05-09 14:31:06 UTC

Andre,

Sorry, reopening for now. Todays pull of a WIN Dev build, AOO400m1(Build:9700)  -  Rev. 1479897 looks to have included the 122230 commit, but does not fix the traveling focus.

I can sort of follow things in SVN, but I sometimes loose the trail going from revision to commit or vice-a-verse. What is the commit number, or revision,  I should look for to check against a build with the Notify() method in comment 6 applied, is that the 122251 commit avail in revisions > 1480243?

I guess rather than testing on Windows with JAB I might have to spin up a 64-bit GNOME based Linux with ORCA for ATK annotation. 

Then test from there using the still functioning 64-bit Linux BuildBot dailys--those WOULD be the most current, right? Todays shows rev. 1480523--but the other builds are kaput (as rpt. in bug 121420).

Stuart

Comment 8 V Stuart Foote 2013-05-09 14:36:29 UTC

Sorry that should have been bug 122244 --not 121420, sloppy with my copy paste.

Comment 9 V Stuart Foote 2013-05-09 20:00:49 UTC

Took some time and set up a 64-bit Linux VM

Installed todays BuildBot 64-bit Linux
AOO400m1(Build:9700)
2013-05-09_04:09:59 - Rev. 1480523

Assume it is 122251 commit that has corrected the issue with the active cell moving with cursor key movements in sidebar.

Resetting this RESOLVED FIXED.

Comment 10 V Stuart Foote 2013-05-21 16:02:04 UTC

Reopening, looking at an IA2 branch AOO400m1(Build:9700) - Rev. 1484083
Rev.1484083

Believe SVN http://svn.apache.org/viewvc?view=revision&revision=1479558
and http://svn.apache.org/viewvc?view=revision&revision=1480241 both in place for bug 122230 and bug 122251 respectively.  However, with properties panel active, cycling with <DOWN> cursor through panel title bars is again passing cursor movement through to cell positions on the active sheet.

Again this is on an IA2 build, will have to also have a look at a current build of core.

Comment 11 V Stuart Foote 2013-05-21 16:13:11 UTC


With AOO400m1(Build:9700)  -  Rev. 1484333
2013-05-20_04:12:39 - Rev. 1484373 on 64-bit Fedora 18 linux.

Position with <F6> into sidebar with Properties panel active

Then have a similar bleed through of <DOWN> cursor movements in Sidebar moving active cell. But it is a little different in that one cell shift in active sheet occurs with a full cycle through the panel titles AND tab bar items. 

In the IA2 build, the active cell shift occurs with each <DOWN> cursor move but only while in the panel title bars. Cycling down through the Tab bar does not shift until it rolls back onto the panels.

Comment 12 V Stuart Foote 2013-05-21 16:22:02 UTC

AOO400m1(Build:9700)  -  Rev. 1484333
2013-05-20_04:12:39 - Rev. 1484373

The cell shift occurs when passing from last panel in properties, Number Format, onto to the Configuration Menu button. Can cursor upward off the button and then downward onto it and it advances the cell.  So, landing on the button with <DOWN> cursor action is what is passing through as cell movement.

Comment 13 V Stuart Foote 2013-05-21 16:26:45 UTC

Comparing key strokes on the IA2 build and the core build. 

It looks like IA2 has two issues, the one still in place with core, e.g. landing on the configuration menu button with <DOWN> cursor movement.  And a related but separate issue with <DOWN> cursor movement through the panel title bars that is not present on core build.

Comment 14 Andre 2013-05-22 08:52:00 UTC

I can confirm the strange double processing of DOWN events.  It is not restricted to the sidebar nor to Calc.  It is a general problem and needs a general solution.  I have created bug 122363 for it and will set this bug back to fixed.