Bug 124916 - LibreOffice Calc keyboard stops working after "Delete cell" dialogue window
Summary: LibreOffice Calc keyboard stops working after "Delete cell" dialogue window
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.2.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-23 14:37 UTC by Branko
Modified: 2020-03-13 12:14 UTC (History)
1 user (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 Branko 2019-04-23 14:37:52 UTC
Description:
EDITING

In LibreOffice Calc when I get into a deleting dialogue, e.g. when deleting a single cell or a selection of unsequential columns with ctrl -, my keyboard stops working. To get it back I need to defocus the LibreoOffice Calc window and then refocus it back.

This also happens when opening the About in Help.

Not much of a hassle (once I figured out how to get it back) but should be fixed.

Installation details: Version: 6.2.2.2 Build ID: 6.2.2-2 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; running on Manjaro based on Arch.


Steps to Reproduce:
1. click on a cell in Calc
2. press ctrl - to open delete cell dialogue
3. press Ok

Actual Results:
Calc is refocused but keyboard stops working. To get it back I need to defocus the Calc window and then refocus it back.


Expected Results:
Calc is refocused and keyboard should work.


Reproducible: Sometimes


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
Version: 6.2.2.2
Build ID: 6.2.2-4
CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: kde5; 
Locale: en-US (mk_MK.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 b. 2019-04-28 05:06:50 UTC
no repro with ver: 

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 35d9a2618dc0116378ab795a7b9277d248c5afd4
CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-05_04:55:04
Locale: de-DE (de_DE); UI-Language: en-US
Calc: *unthreaded*

*threaded* not tested, above ver. is known buggy in threaded, all subsequent known for crashing, 

reg. 

b.
Comment 2 Buovjaga 2019-08-14 17:04:42 UTC
You were running the kde5 backend with early 6.2.x versions, where it had still some nasty bugs. Please tell us how it behaves now with an up-to-date version

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Comment 3 QA Administrators 2020-02-11 03:30:21 UTC Comment hidden (obsolete)
Comment 4 QA Administrators 2020-03-13 03:09:42 UTC Comment hidden (obsolete)
Comment 5 Branko 2020-03-13 11:12:12 UTC Comment hidden (obsolete)
Comment 6 Buovjaga 2020-03-13 11:18:18 UTC
(In reply to Branko from comment #5)
> Hi guys,
> 
>    Sorry for keeping you waiting - the bug is indeed resolved with the new
> version.
>    There are some new issues I will report in a separate comment.
>    It would be much easier to report and discuss bugs if you moved to GitHub
> and GitLab, please consider it in the future.

From my experience it would not be easier. I am curious how exactly do you consider it would be easier.
Comment 7 Branko 2020-03-13 11:34:21 UTC
(In reply to Buovjaga from comment #6)
> (In reply to Branko from comment #5)
> > Hi guys,
> > 
> >    Sorry for keeping you waiting - the bug is indeed resolved with the new
> > version.
> >    There are some new issues I will report in a separate comment.
> >    It would be much easier to report and discuss bugs if you moved to GitHub
> > and GitLab, please consider it in the future.
> 
> From my experience it would not be easier. I am curious how exactly do you
> consider it would be easier.

Let me say that I don't want to diss the setup you have running. On my side, I'm not used to using bugzilla. On the other hand, I've discussed some issues for free software tools hosted on GitHub and I found the experience very smooth, e.g. https://github.com/spyder-ide/spyder/issues

Here are some points I find better off of the top of my head:
- comment writing is much cleaner:
   - there's no quotation of the comment you are replying to in the start of the text you're entering (like when I'm writing this)
   - markdown is supported and allows inserting `code`, and images as printscreens, as well as nested lists (like this one),
   - you can +1 other comments or use emojis
- no need to log-in to bugzilla, or a project based webservice - I'm always logged in on GitHub/GitLab so I don't have to remmember/reset my password like I did today : )
- searching for issues allows for tags

I'm not sure if bugzilla offers any of these, but again people are more or less used to working on GitHub/GitLab, and having a different forum for different projects get's time to get accustomed to. This ultimately hurts issues reporting and the project.

Maybe this discussion should be in a different thread? : )
Comment 8 Buovjaga 2020-03-13 12:14:35 UTC
(In reply to Branko from comment #7)
> (In reply to Buovjaga from comment #6)
> > (In reply to Branko from comment #5)
> > > Hi guys,
> > > 
> > >    Sorry for keeping you waiting - the bug is indeed resolved with the new
> > > version.
> > >    There are some new issues I will report in a separate comment.
> > >    It would be much easier to report and discuss bugs if you moved to GitHub
> > > and GitLab, please consider it in the future.
> > 
> > From my experience it would not be easier. I am curious how exactly do you
> > consider it would be easier.
> 
> Let me say that I don't want to diss the setup you have running. On my side,
> I'm not used to using bugzilla. On the other hand, I've discussed some
> issues for free software tools hosted on GitHub and I found the experience
> very smooth, e.g. https://github.com/spyder-ide/spyder/issues
> 
> Here are some points I find better off of the top of my head:
> - comment writing is much cleaner:
>    - there's no quotation of the comment you are replying to in the start of
> the text you're entering (like when I'm writing this)

I don't get this: you don't have to quote in Bugzilla if you don't want to. Likewise, you *can* quote in GitHub, if you want to by clicking the "meatballs" element in the top right corner of a message.

>    - markdown is supported and allows inserting `code`, and images as
> printscreens, as well as nested lists (like this one),

The next version of Bugzilla (already live at https://bugzilla.mozilla.org ) has markdown support. Inline images will also be supported through an extension.

>    - you can +1 other comments or use emojis

Emojis work in the nextgen Bugzilla. 

+1/reactions don't provide any value. If someone leaves such a comment now, we hide it with a tag like me-too or no-value.

Discussion in a Bugzilla upstream ticket seems to be along the same lines: https://bugzilla.mozilla.org/show_bug.cgi?id=1421401 "I'd like us to get away from voting because it implies that design decisions are up for popular vote."

> - no need to log-in to bugzilla, or a project based webservice - I'm always
> logged in on GitHub/GitLab so I don't have to remmember/reset my password
> like I did today : )

We would never use a hosted service like Github in any case. In theory, it would be a self-hosted GitLab, but your existing gitlab.com account would be useless.

Popular hosted services have the advantage of a smooth authentication experience, but a monoculture has many disadvantages.

The next version of Bugzilla will support our single sign-on service, so we will have a rather good coverage across all TDF web applications. You can log into the wiki, gerrit code review etc. all with a single account.

> - searching for issues allows for tags

The search of GitHub/-Lab is inferior compared to Bugzilla. "Tags" in Bugzilla are called keywords. There is also the whiteboard field for completely freeform metadata. Bugzilla's advanced search interface provides a very finegrained way to filter reports. This is absolutely crucial for quality assurance. We also make extensive use of the Bugzilla API to provide automated reports etc.

> I'm not sure if bugzilla offers any of these, but again people are more or
> less used to working on GitHub/GitLab, and having a different forum for
> different projects get's time to get accustomed to. This ultimately hurts
> issues reporting and the project.

This is again about the advantages and disadvantages of a monoculture.