Bug 2107722
Summary: | elementary-code not accepting a filename to save as | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | michael8rown | ||||
Component: | elementary-code | Assignee: | Fabio Valentini <decathorpe> | ||||
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 36 | CC: | decathorpe | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2022-08-17 10:12:20 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Sorry for the late response. Do you have any unofficial repositories enabled, i.e. my decathorpe/elementary-staging or decathorpe/elementary-nightly COPRs? Hi, no I do not have either of those COPRs enabled. Should I enable them? To be clear, I have no other unofficial repositories enabled, either. No COPRs at all. I enabled both staging and nightly COPRs, ran sudo dnf --refresh update which updated code from elementary-code-6.2.0-1.fc36.x86_64 to elementary-code-6.2.0+git220812.131014.5276b80f-1.fc36.x86_64, rebooted, same problem: SAVE and SAVE-AS still want to perform a search for the filename I am trying to enter. Oh, uhm, enabling those two repos is not something that I wanted you to do, as reversing the process of enabling and installing packages from these repos is not straightforward ... I just wanted to know if you had already enabled them, because that could have explained the problem. But either way, I can confirm that this bug happens to me as well. Weird that nobody noticed this before. Ok, after asking about this problem with elementary developers, looks like this is a somewhat known issue with the GTK4 file chooser, which appears to be broken when using the elementary theme. I'm afraid I can't fix that on the Fedora side (since I can't override the default GTK filechooser). |
Created attachment 1897481 [details] Screen recording showing what is happening when I try to save a file in Code Description of problem: I hit CTRL-S to save a document in io.elementary.code. A "Save" window opens with a Name field, but when I begin to enter a filename, the Save window functions like a search, as if it's searching for the filename I'm typing instead of saving the file. Version-Release number of selected component (if applicable): Code 6.2.0 How reproducible: Launch Code, enter some text, type CTRL-S or click on the "Save" icon at the top, and try to enter a filename to save. Alternatively, if you open an existing document and try to save the document under a new filename (either entering CTRL-SHIFT-S or clicking on the Save-As icon at the top), the same bug appears. Steps to Reproduce: 1. Launch io.elementary.code 2. Enter some text 3. Type CTRL-S or click on the "Save" icon at the top of the window. 4. Try to enter a filename into the Name field to save as Actual results: Instead of accepting input for a filename to save, the system begins to search for the filename I am entering. Expected results: When I enter a filename to save, I expect the system to accept the input and save the file I am creating under the filename I am entering. Additional info: This same bug occurs in GNOME Text Editor, but only after I install the Pantheon Desktop group from Fedora. If I uninstall Pantheon Desktop group and delete .cache, .config, and .local directories from my /home/[user] directory, then the expected SAVE AS behavior in GNOME Text Editor returns to normal and bug is gone. So this may be a larger Pantheon issue, but since I first experienced it in Code, I am repoting this bug here.