Bug 428346 - Texts, combobox and checkboxes unexpectedly remain greyed out after I select "Yes" radio button
Summary: Texts, combobox and checkboxes unexpectedly remain greyed out after I select ...
Status: RESOLVED FIXED
Alias: None
Product: drkonqi
Classification: Applications
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-27 16:00 UTC by Patrick Silva
Modified: 2020-11-03 12:23 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
screen recording (1.04 MB, video/webm)
2020-10-27 16:00 UTC, Patrick Silva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Silva 2020-10-27 16:00:05 UTC
Created attachment 132798 [details]
screen recording

SUMMARY
They are no longer greyed out after I click "Next" and "Back" buttons.
Watch the attached screen recording please.

EXPECTED RESULT
Texts, combobox and checkboxes should not be greyed out when select "Yes"
radio button.

SOFTWARE/OS VERSIONS
Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.20.80
KDE Frameworks Version: 5.76.0
Qt Version: 5.15.0
Comment 1 Harald Sitter 2020-11-03 09:54:18 UTC
Looks like a qt5.15 regression
Comment 2 Bug Janitor Service 2020-11-03 10:23:31 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/drkonqi/-/merge_requests/7
Comment 3 Harald Sitter 2020-11-03 12:23:25 UTC
Git commit b21006b77635cdfceaacf6ff322f5f725d70f99b by Harald Sitter.
Committed on 03/11/2020 at 10:22.
Pushed by mlaurent into branch 'master'.

fix buttongroup state toggles

this was recently changed on the BugAwarenessPage and broke state
tracking as idPressed is emitted when pressing down, before the group
state actually switches. the yes/no group on that page was effectively
inverted as updateCheckBoxes was called before the property update and
thus when the user clicked Yes the internal state in the slot was still
No and vice versa.

the duplicates dialog similarly was wrong but it's much harder to
stumble over since the relevant UI elements are only visible when trying
to mark a bug duplicate to a closed bug or a "common" bug

use the idClicked signal instead, it's what the code originally used (as
the now deprecated buttonClicked)

M  +2    -2    src/bugzillaintegration/reportassistantpages_base.cpp
M  +2    -2    src/bugzillaintegration/reportassistantpages_bugzilla_duplicates.cpp

https://invent.kde.org/plasma/drkonqi/commit/b21006b77635cdfceaacf6ff322f5f725d70f99b