Bug 129032 - Missing warning when renaming page with same name
Summary: Missing warning when renaming page with same name
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Heiko Tietze
URL:
Whiteboard: target:7.0.0 target:7.2.0
Keywords:
Depends on:
Blocks: Page
  Show dependency treegraph
 
Reported: 2019-11-26 07:36 UTC by Rizal Muttaqin
Modified: 2021-02-01 22:32 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
A dialog warning in Calc after trying to renaming with same name sheet (13.36 KB, image/png)
2019-11-27 18:27 UTC, Rizal Muttaqin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rizal Muttaqin 2019-11-26 07:36:53 UTC
Step to reproduce:

1. Create a new Draw files
2. Rename existing first page (e.g. Test)
3. Create a new page (Page > New Page, or in the page left side panel right click > New Page))
4. Rename the new page with the same name as the first page (e.g. Test) (Page > Rename page, or in the page left side panel right click > rename page)

Actual result:
The OK button disabled but there's no warning tell me that renaming with already used name is not allowed.

Expected result:

there's warning (a dialog?) tell me that renaming with already used name is not allowed.
Comment 1 Durgapriyanka 2019-11-26 17:39:23 UTC
Thank you for reporting the bug. I can not reproduce this bug in

Version: 6.4.0.0.alpha1+ (x86)
Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
	

and in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 2 Xisco Faulí 2019-11-27 15:01:01 UTC Comment hidden (obsolete)
Comment 3 Xisco Faulí 2019-11-27 15:03:33 UTC
I can reproduce it in

Version: 6.5.0.0.alpha0+
Build ID: 3a6f270edfffb97763927b2732feacedbdac1e80
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

but let the UX Team decide whether we want to show the warning.
Do we show this warning in other dialogs ?
Comment 4 Rizal Muttaqin 2019-11-27 18:25:10 UTC
> Do we show this warning in other dialogs ?

In Impress, this issue is happen as Draw and Impress shares the same based code (CMIIW)

I have checked similar step in Calc, after trying to rename a new sheet with existing name, there's dialog appears.
Comment 5 Rizal Muttaqin 2019-11-27 18:27:34 UTC
Created attachment 156158 [details]
A dialog warning in Calc after trying to renaming with same name sheet
Comment 6 Heiko Tietze 2019-12-02 08:40:59 UTC
Disabling the action when requirements are not fulfilled (see bug 62851) is the correct way to go. While this behavior is common (and IMHO easy to grasp), we could show a warning like "Name has been assigned to another slide" (or page).

I would rather change Calc to not interrupt the workflow (as done in bug 128521).
Comment 7 Rizal Muttaqin 2019-12-03 04:15:22 UTC
(In reply to Heiko Tietze from comment #6)
> Disabling the action when requirements are not fulfilled (see bug 62851) is
> the correct way to go. While this behavior is common (and IMHO easy to
> grasp), we could show a warning like "Name has been assigned to another
> slide" (or page).

I agree that disabled action is also easy to grasp, but a warning will provide better understanding, user would now what really happen. 

> I would rather change Calc to not interrupt the workflow (as done in bug
> 128521).


+1 for your propose just like tdf#128521, it would reduce action since an another dialog required another action button (e.g. "OK"). My Nautilus 3.26.x (Ubuntu 18.04) has similar approach.
Comment 8 Heiko Tietze 2019-12-05 08:05:58 UTC
We discussed the topic in the design meeting. Three options are feasible: background of the edit field becomes red (as known from Calc, conditional formatting with wrong range values). some text, a tooltip and an icon.
The last two are most common: set_message_type(weld::EntryMessageType::Error) adds a tiny icon to the input and the tooltip should explain why the button is disabled.
Comment 9 Commit Notification 2020-02-17 08:32:46 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/a4f5c8d38e307bb37f08e8f6ef3cfc9ffac84304

Resolves tdf#129032 - Missing warning when renaming page

It will be available in 7.0.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 10 Rizal Muttaqin 2020-03-21 12:27:02 UTC
I've found this same issue happens in Impress, should I file a new bug report?
Comment 11 Heiko Tietze 2020-03-21 16:06:04 UTC
(In reply to Rizal Muttaqin from comment #10)
> I've found this same issue happens in Impress, should I file a new bug
> report?

Are you sure it's not fixed with the patch? IIRC I double checked Impress since the patch affects cui/... And checking again now the tooltip shows up for both Draw and Impress.
Comment 12 Rizal Muttaqin 2020-03-21 22:18:51 UTC
(In reply to Heiko Tietze from comment #11)
> (In reply to Rizal Muttaqin from comment #10)
> > I've found this same issue happens in Impress, should I file a new bug
> > report?
> 
> Are you sure it's not fixed with the patch? IIRC I double checked Impress
> since the patch affects cui/... And checking again now the tooltip shows up
> for both Draw and Impress.

Ah sorry I forgot if we implement the tooltip. But this made me aware another issue, the tooltip is not visible if the cursor is not near the  window dialog e.g when renaming the slide/page, the cursor left in the slides pane. Should we go with a text below the box?
Comment 13 Heiko Tietze 2020-03-22 07:16:39 UTC
(In reply to Rizal Muttaqin from comment #12)
> Should we go with a text below the box?

Current solution is the best. You edit the field and any key stroke has an effect. So users are aware of the reason, though not exactly and therefore can get further info per tooltip.
Comment 14 Rizal Muttaqin 2020-03-22 09:29:19 UTC
(In reply to Heiko Tietze from comment #13)

> Current solution is the best. You edit the field and any key stroke has an
> effect. So users are aware of the reason, though not exactly and therefore
> can get further info per tooltip.

Make sense, though I prefer more visible warning just like the illegal char case (tdf#128521). Let's it as is.
Comment 15 Commit Notification 2021-02-01 22:32:03 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0108ed5cefdf259f5374d6c6aaf7ae14fea16181

related: tdf#129032: uitest: check ok button is disabled

It will be available in 7.2.0.

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

Affected users are encouraged to test the fix and report feedback.