Issue 58312 - font tab: Font-size widget has wrong behavior
Summary: font tab: Font-size widget has wrong behavior
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.0
Hardware: PC All
: P4 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: michael.ruess
QA Contact: issues@gsl
Keywords: oooqa
: 46922 52823 (view as issue list)
Depends on:
Reported: 2005-11-22 15:59 UTC by rifaccio
Modified: 2010-02-02 13:38 UTC (History)
3 users (show)

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

Selectionsequence1_3 (39.86 KB, image/jpeg)
2005-12-14 16:45 UTC, rifaccio
no flags Details
Sorry thi one is the correct one.(Sequence) (127.77 KB, image/jpeg)
2005-12-14 16:54 UTC, rifaccio
no flags Details
Fix of selection in font size box. (1.05 KB, patch)
2008-08-13 21:07 UTC, dtardon
no flags Details | Diff
move the focus grabbing to ComboBox::Notify() (964 bytes, patch)
2009-07-14 11:13 UTC, dtardon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description rifaccio 2005-11-22 15:59:26 UTC
Open the paragraph style editor dialog.  
Select the font tabbed panel.  
Select a value for the size.  
Scroll down the list until the selected value is out of port view.  
Select a size value.  
The list scrolls up until the old selected size value and a different value,
close to the old one, is selected.
Comment 1 lars 2005-11-22 20:38:31 UTC
I don't see any problems: could you give a more detailed explanation please?
Comment 2 michael.ruess 2005-12-14 15:57:22 UTC
I cannot see any problem here. It works fine on my Windows XP (with "Windows
classic" theme). Do you have a specific theme other than the default activated
on your system?
Comment 3 rifaccio 2005-12-14 16:45:00 UTC
Created attachment 32402 [details]
Comment 4 rifaccio 2005-12-14 16:53:35 UTC
My SO is the WIndows 2000 with default theme.
I try to explain in a more clear way.
Let suppose thatthe layout for the font size list, in the font tabbed pane for
the paragraph editor dialog, it's:
--------(start view port)
/12pt/  (selection)
13pt     |  (scroll cursor position)
--------(end view port)

Lets scroll the list  with the scrollbar, not the buttons up and down but the
cursor, till the selected entry will be out of view:

--------(start view port)
19pt     |  (scroll cursor position)
--------(end view port)

now try to select 19pt
The list will be scrolled up and the selection will be
on a value close to the 12pt:

--------(start view port)
13pt     |  (scroll cursor position)
/14pt/  (selection)
--------(end view port)

I've attached som pictures
Comment 5 rifaccio 2005-12-14 16:54:37 UTC
Created attachment 32403 [details]
Sorry thi one is the correct one.(Sequence)
Comment 6 michael.ruess 2005-12-15 08:49:56 UTC
Now I see the problem; it is essential that you use the fontsize selector two
times to see the bug.

MRU->OS: open the font tab (does not matter wether it is the Format.Character or
the Edit.Paragraph style dialog). Use the scrollbar to move the selected font
size out of the visible area. Now select a new FontSize. Again, use the
Scrollbar to move the selection out of the visible area. Try to select a new
FontSize -> now the control will display a different area of the sizes list.
Comment 7 Oliver Specht 2006-06-20 13:54:48 UTC
Target adjusted
Comment 8 ace_dent 2008-05-15 15:12:04 UTC
This Issue requires more information ('needmoreinfo'), but has not been updated
within the last year. Please re-test with one of the latest versions of OOo -
the problem(s) may have already been addressed. Either use the recent stable
or consider trying the new OOo 3 BETA (still in testing):
Please report back the outcome so this Issue may be closed or progressed as
necessary - otherwise it may be Resolved as Invalid in the future. You may also
wish to search for (and note) any duplicates of this Issue that may have
advanced further :
Many thanks,
Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~
Comment 9 dtardon 2008-07-18 06:35:30 UTC
This bug is still present in DEV300_m25. My OS is Linux (Fedora 9) on x86_64.
Comment 10 Oliver Specht 2008-07-18 08:07:55 UTC
->pl: The problem seems to be in MetricBox::Notify()
On EVENT_LOSEFOCUS the box wants to be reformatted. That causes the stack below
and ends in a change of selection. 

 	vclmi.dll!ImplListBoxWindow::SetTopEntry(unsigned short nTop=1)  Line 1868	C++
 	vclmi.dll!ComboBox::ImplUpdateFloatSelection()  Line 938	C++
 	vclmi.dll!ComboBox::SetText(const String & rStr={...}, const Selection &
rNewSelection={...})  Line 895	C++
 	vclmi.dll!FormatterBase::ImplSetText(const String & rText={...}, Selection *
pNewSelection=0x00000000)  Line 392	C++
 	vclmi.dll!MetricFormatter::Reformat()  Line 1677	C++
 	svtmi.dll!FontSizeBox::Reformat()  Line 1174	C++
>	vclmi.dll!MetricBox::Notify(NotifyEvent & rNEvt={...})  Line 1934	C++
 	vclmi.dll!Window::Notify()  + 0x327 bytes	C++
 	vclmi.dll!Window::Notify()  + 0x327 bytes	C++
 	vclmi.dll!ImplListBox::Notify(NotifyEvent & rNEvt={...})  Line 2436 + 0x1a
bytes	C++
 	vclmi.dll!Window::Notify()  + 0x327 bytes	C++
Comment 11 dtardon 2008-08-13 21:03:30 UTC
I have found a simple solution of this bug and one more I found working on
this one. It's not particularly smart--it simply tests in
ComboBox::PreNotify() if the window sending notification is the listBox
and doesn't let the mpSubEdit grab focus in that case--yet another
workaround relying on specific behaviour of other components involved.

The solution changes behaviour of ComboBox, however--click on any part
aside of the listBox (even the scrollbars) is followed by the editField
getting focus.


The other bug I've spoken about is reproducible following these steps:

1. open font dialog
2. click to size box on some number somewhere in the middle of the listBox
3. click on one of the arrows of vertical scrollbar

Now focus is on item before (or after, depending on which arrow has been
used) the selected one.
Comment 12 dtardon 2008-08-13 21:07:17 UTC
Created attachment 55757 [details]
Fix of selection in font size box.
Comment 13 dtardon 2009-07-14 10:51:19 UTC
*** Issue 52823 has been marked as a duplicate of this issue. ***
Comment 14 Rainer Bielefeld 2009-07-14 11:00:32 UTC
No further info required
Comment 15 Rainer Bielefeld 2009-07-14 11:06:13 UTC
For the sake of completeness: This is not a special WRITER problem, same effect
ca be seen in CALC and DRAW.
Comment 16 dtardon 2009-07-14 11:11:33 UTC
The problem is caused by calling mpSubEdit->GrabFocus() in ComboBox::PreNotify()
when processing EVENT_MOUSEBUTTONDOWN on mpImplLB. This causes EVENT_LOSEFOCUS
to be emitted on mpImplLB, which in turn ends in reformatting the whole control
box (through MetricBox::Notify()). Because, at this stage, the click hasn't been
processed yet, the item selected in the listbox is still the original one, thus
the listbox is scrolled to get it to view. Thus, when the click is finally
processed, the view of the listbox has already been set to differenent range.

dtardon->pl: It seems to me the best thing is to move the problematic code from
ComboBox::PreNotify() to ComboBox::Notify(). Do you agree, or could there be any
hidden consequences that I haven't spotted?
Comment 17 dtardon 2009-07-14 11:13:02 UTC
Created attachment 63538 [details]
move the focus grabbing to ComboBox::Notify()
Comment 18 dtardon 2009-07-14 11:13:36 UTC
adding myself to cc
Comment 19 philipp.lohmann 2009-07-14 13:59:52 UTC
You won't hear me say that there is no side effect for this change; when
changing focus behavior bets are usually off. However I confirmed your patch
fixes the issue, and I see no harm either, so I'll commit it in CWS vcl104.
Thanks for this patch !
Comment 20 philipp.lohmann 2009-08-25 12:42:31 UTC
please verify in CWS vcl104
Comment 21 michael.ruess 2009-08-31 13:37:42 UTC
Verified fix in CWS vcl104.
Comment 22 michael.ruess 2009-10-02 08:47:55 UTC
Checked in DEV300m60.
Comment 23 Rainer Bielefeld 2010-02-02 13:38:18 UTC
*** Issue 46922 has been marked as a duplicate of this issue. ***