Bug 105293 - UX: Clicking the font color button should apply the select font color instead of a color pour bucket
Summary: UX: Clicking the font color button should apply the select font color instead...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Yousuf Philips (jay) (retired)
URL:
Whiteboard: target:5.4.0
Keywords:
: 105365 107613 (view as bug list)
Depends on:
Blocks: Color-Picker-Widget Unify-Across-Apps
  Show dependency treegraph
 
Reported: 2017-01-12 18:39 UTC by Telesto
Modified: 2022-08-11 18:57 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-01-12 18:39:34 UTC
Description:
The font color selector in Writer doesn't behave the same way as in Calc or Impress (or Word, Google Docs, Wordpad for that matter). 
I'm not able to click the font color icon, so I can type in that color next. Instead I get a mouse pointer with a bucked, to change already typed text.

Steps to Reproduce:
1.Open Writer
2.Type some text
3. Click on the font color button (default Bordeaux red)
4. Type something (text should be red)
5. Compare with Impress or Calc



Actual Results:  
Text typed next is black

Expected Results:
Typed text should be red


Reproducible: Always

User Profile Reset: No

Additional Info:
Found in:
Version: 5.4.0.0.alpha0+
Build ID: 88f561204d7cee25633df8117cc8d7e1ebd8e9ad
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-11_23:07:37
Locale: nl-NL (nl_NL); Calc: CL

and in
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4


User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Buovjaga 2017-01-14 19:23:53 UTC
Yeah, let's bring this to the attention of the design team
Comment 2 Telesto 2017-01-14 20:16:48 UTC

*** This bug has been marked as a duplicate of bug 88989 ***
Comment 3 Heiko Tietze 2017-02-18 10:38:04 UTC
Reopening since bug 88989 is about the interaction of splitbuttons and this ticket deals with the workflow. It is similar to bug 88903 about the automatic color that is not properly set on default text.
Comment 4 Yousuf Philips (jay) (retired) 2017-04-25 18:02:24 UTC
So the behaviour of the main button is to go into paint mode (see the mouse cursor change) similar to the highlight color, if no text is selected, which is different from what happens when you open the color picker widget and select a color, which works correctly.
Comment 5 Yousuf Philips (jay) (retired) 2017-05-02 15:37:25 UTC
So as regina mentioned in bug 88989 comment 12, .uno:FontColor can be swapped out with .uno:Color, which doesnt have the paint bucket feature.

@Regina: Thanks for the info, as i recently recently swapped out .uno:FontColor with .uno:Color in the notebookbar as .uno:FontColor didnt work in textboxes.
Comment 6 Yousuf Philips (jay) (retired) 2017-05-03 14:01:17 UTC
Patch is in - https://gerrit.libreoffice.org/37203
Comment 7 Commit Notification 2017-05-03 19:44:29 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c31c338fa2a941e128d0dac251fb99f777ac7b00

tdf#105293 tdf#81475 Tweak standard and formatting toolbars

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 3191602956 2017-05-05 00:47:47 UTC
*** Bug 107613 has been marked as a duplicate of this bug. ***
Comment 9 Justin L 2022-08-11 18:57:07 UTC
*** Bug 105365 has been marked as a duplicate of this bug. ***