GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2021-10-24T16:38:27Zhttps://gitlab.gnome.org/GNOME/epiphany/-/issues/1505Epiphany doesn't show PDF as response to a POST2021-10-24T16:38:27ZGhost UserEpiphany doesn't show PDF as response to a POSTHello!
I'm not experienced with PHP. I've created a [HTML form](https://flapflap.eu/form.html) which uses a HTTP POST to a [PHP Script](https://flapflap.eu/work.php) and returns a PDF. This works fine with Firefox, Chrome, cURL and Midor...Hello!
I'm not experienced with PHP. I've created a [HTML form](https://flapflap.eu/form.html) which uses a HTTP POST to a [PHP Script](https://flapflap.eu/work.php) and returns a PDF. This works fine with Firefox, Chrome, cURL and Midori (WebKit2). It also works fine, when I copy the cURL command from the Web Inspector and execute it manually with `--output some.pdf`. But Epiphany waits forever when I fill the first name and press the button labeled "PDF".
This is the PHP, using [TCPPDF](https://tcpdf.org/):
```php
<?php
if (isset($_POST['pdf_button'])) {
header('Content-Type: application/pdf');
require_once('tcpdf/tcpdf.php');
// create new PDF document
$pdf = new TCPDF(PDF_PAGE_ORIENTATION, PDF_UNIT, PDF_PAGE_FORMAT, true, 'UTF-8', false);
// set document information
$pdf->SetCreator(PDF_CREATOR);
$pdf->SetAuthor('Foo Bar');
$pdf->SetTitle('Check');
$pdf->SetSubject('TCPDF Tutorial');
$pdf->SetKeywords('tcpdf, oepnv');
// remove default header/footer
$pdf->setPrintHeader(false);
$pdf->setPrintFooter(false);
// set default monospaced font
$pdf->SetDefaultMonospacedFont(PDF_FONT_MONOSPACED);
// set margins
$pdf->SetMargins(PDF_MARGIN_LEFT, PDF_MARGIN_TOP, PDF_MARGIN_RIGHT);
// set auto page breaks
$pdf->SetAutoPageBreak(TRUE, PDF_MARGIN_BOTTOM);
// set image scale factor
$pdf->setImageScale(PDF_IMAGE_SCALE_RATIO);
// set some language-dependent strings (optional)
if (@file_exists(dirname(__FILE__).'/lang/eng.php')) {
require_once(dirname(__FILE__).'/lang/eng.php');
$pdf->setLanguageArray($l);
}
// set font
$pdf->SetFont('dejavusans', '', 14, '', true);
// add a page
$pdf->AddPage();
$pdf->Text(20, 20, 'TEST');
// set style for barcode
$style = array(
'border' => 2,
'vpadding' => 'auto',
'hpadding' => 'auto',
'fgcolor' => array(0,0,0),
'bgcolor' => false, //array(255,255,255)
'module_width' => 1, // width of a single module in points
'module_height' => 1 // height of a single module in points
);
// QRCODE,Q : QR-CODE Better error correction
$pdf->write2DBarcode('Hello WebKit', 'QRCODE,Q', 20, 50, 50, 50, $style, 'N');
// $pdf->write2DBarcode($first_name, 'QRCODE,Q', 20, 50, 50, 50, $style, 'N');
$pdf->Text(20, 40, 'ÖPNV Ticket');
//Close and output PDF document
$pdf->Output('pdf_ticket.pdf', 'D'); // I for inline
} else {
echo 'Hello ' . htmlspecialchars($_POST["first_name"]) . ' ' . htmlspecialchars($_POST["last_name"]) . '!'; // dot is concatenation operator
}
?>
```
The supposed "cURL" Epiphany seems to use:
```
curl 'https://flapflap.eu/work.php' \
-X 'POST' \
-H 'Referer: https://flapflap.eu/form.html' \
-H 'Origin: https://flapflap.eu' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
-H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15' \
--data 'first_name=Foo&last_name=&pdf_button=PDF' --output test.pdf
```
Now to the interesting part. Epiphany somewhat struggles with the MIME-TYPE, it only shows this in the terminal output:
```
(epiphany:9465): epiphany-WARNING **: 16:54:21.259: PDF file:///tmp/work.php has invalid MIME type: text/html
```
`$ cat /tmp/work.php` reveals:
```
Hello !
```
This looks like the result of the else branch. I should mention, that Nautilus is holding a FTP connection to my website, but I cannot imagine a connection between the FTP and the issue. Requesting a PDF with a plain HTTP GET works fine.
Thank youhttps://gitlab.gnome.org/GNOME/gimp/-/issues/6730About GIMP, link color2023-02-15T04:48:26ZTameoAbout GIMP, link colorThe link text `Visit the GIMP website` in the `Help > About GIMP` window is hard to read.
The blue link color "clashes" with the gray background color.
![gimp-2.10_2021-04-13_10-35-32](/uploads/689971ce77d4379ab76f8d7374e37494/gimp-2.1...The link text `Visit the GIMP website` in the `Help > About GIMP` window is hard to read.
The blue link color "clashes" with the gray background color.
![gimp-2.10_2021-04-13_10-35-32](/uploads/689971ce77d4379ab76f8d7374e37494/gimp-2.10_2021-04-13_10-35-32.png)
System:
Windows 10 20042.10.26https://gitlab.gnome.org/GNOME/evince/-/issues/1587PDF with one single whitespace as Title shows blank in Recent View2021-06-26T22:22:46ZNelson BenPDF with one single whitespace as Title shows blank in Recent ViewThis [pdf file](https://media.techtarget.com/tss/static/books/wiley/masteringEJB3/downloads/MasteringEJB4thEd.pdf)(10.4MB) shows no text under its thumbnail in Recent View, screenshot below:
![Captura_de_pantalla_de_2021-04-12_21-43-28]...This [pdf file](https://media.techtarget.com/tss/static/books/wiley/masteringEJB3/downloads/MasteringEJB4thEd.pdf)(10.4MB) shows no text under its thumbnail in Recent View, screenshot below:
![Captura_de_pantalla_de_2021-04-12_21-43-28](/uploads/65fc0cd0ad70801f80e6ff82e2457d69/Captura_de_pantalla_de_2021-04-12_21-43-28.png)
It seems problem is related to Title of PDF being an empty string, as seen in the Properties dialog, screenshot below:
![Captura_de_pantalla_de_2021-04-12_21-43-51](/uploads/f03484e078e78d8d9c2d727878590287/Captura_de_pantalla_de_2021-04-12_21-43-51.png)
My guess would be that code is checking presence of title like `title != NULL` while it should also add a check for non empty string e.g. ` title != NULL && title[0] != '\0'`https://gitlab.gnome.org/GNOME/nautilus/-/issues/1826Awkward Samba connection dialog2022-12-27T02:46:51ZTobias BernardAwkward Samba connection dialogWhile connecting to a Samba share, there's a weird non-modal message dialog:
![image](/uploads/6a335b466b0136f32aace2261d902da4/image.png)
This is weird for a number of reasons:
- Non-modal message dialogs make no sense
- Dialogs are n...While connecting to a Samba share, there's a weird non-modal message dialog:
![image](/uploads/6a335b466b0136f32aace2261d902da4/image.png)
This is weird for a number of reasons:
- Non-modal message dialogs make no sense
- Dialogs are not a good way to indicate ongoing processes
- It's a part of navigation so it should be inline in the window, similar to any other loading viewhttps://gitlab.gnome.org/GNOME/gvfs/-/issues/561AFC root volume not exposed2021-04-14T10:48:14ZcrviAFC root volume not exposedversion: `1.46.2`
Connecting an iPad causes the `'afc://40-char-uuid:3/'` to be displayed and mounted in nautilus as `"Documents on X's iPad"`. `gphoto2://` interface is also exposed. But the root volume `'afc://40-char-uuid:1/'` is not...version: `1.46.2`
Connecting an iPad causes the `'afc://40-char-uuid:3/'` to be displayed and mounted in nautilus as `"Documents on X's iPad"`. `gphoto2://` interface is also exposed. But the root volume `'afc://40-char-uuid:1/'` is not exposed ( meaning no `GVolume` / `GMount` notification is received ).
Typing `'afc://40-char-uuid:1/'` manually in the URL bar works fine though. But, the app ( rhythmbox ) cannot see them.https://gitlab.gnome.org/GNOME/pitivi/-/issues/2557Changing rate of a aac clip with a muted layer leads to crash2021-11-03T00:21:39ZFabián OrccónChanging rate of a aac clip with a muted layer leads to crash1. Import an asset with containing an aac encoded stream.
```
# Note: You can generate one with:
gst-launch-1.0 audiotestsrc num-buffers=1000 ! audioconvert ! avenc_aac ! mp4mux ! filesink location=test.mp4
```
2. Add this asset as a cli...1. Import an asset with containing an aac encoded stream.
```
# Note: You can generate one with:
gst-launch-1.0 audiotestsrc num-buffers=1000 ! audioconvert ! avenc_aac ! mp4mux ! filesink location=test.mp4
```
2. Add this asset as a clip to the first layer.
3. Mute the layer by clicking the speaker button.
4. Change the rate property of the clip.
A dialog will appear telling:
```
Sorry, something didn't work right.
Pitivi detected a serious backend problem and could no recover from it (...)
```https://gitlab.gnome.org/GNOME/gimp/-/issues/6723Unable to open any and all DDS files2021-04-14T17:51:03ZNightressa LamoreuxUnable to open any and all DDS files- GIMP version: 2.10.24
- Package: Gimp.org
- Operating System: Windows
I've had zero issues up until recently with opening dds files with gimp. About a week or so ago is started popping up with "Warning: DDSD_PITCH is not set! Unexpect...- GIMP version: 2.10.24
- Package: Gimp.org
- Operating System: Windows
I've had zero issues up until recently with opening dds files with gimp. About a week or so ago is started popping up with "Warning: DDSD_PITCH is not set! Unexpected EOF. opening 'C:\Users\~~~\Desktop\--c0801f0001_fac_d.dds' failed: DDS image plug-in could not open image" [](https://i.imgur.com/IHxawue.png)
Is the bug reproducible?: Always even after fresh reinstall
Reproduction steps:
1. open gimp
2. open dds file
3. error
…
Expected result: Open the dds and let me do what I wanted
Actual result: Error and doesn't load the file2.10.26https://gitlab.gnome.org/GNOME/pitivi/-/issues/2556preview playback, and rendering, are blocked if the highest layer with conten...2021-11-03T00:19:18ZLaine Stumppreview playback, and rendering, are blocked if the highest layer with content has audio muted.If the audio is muted on the highest layer with content at the current marker position, clicking on the play button in the preview window will change the play button into a pause button, but playing will be paused. This includes the case...If the audio is muted on the highest layer with content at the current marker position, clicking on the play button in the preview window will change the play button into a pause button, but playing will be paused. This includes the case where there is just a single layer.
Similarly, having audio muted in the highest layer leads to an error right at the start of rendering.
If a lower layer has audio muted, neither of these problems occurs.
Muting the video for a layer doesn't have this effect, only the audio.
(I encountered this behavior with org.pitivi.Pitivi//master as well as with org.pitivi.Pitivi//stable)https://gitlab.gnome.org/GNOME/nautilus/-/issues/1825Extracting password protected archives on Xorg exits nautilus2021-04-22T11:45:48ZIgnacy KuchcińskiExtracting password protected archives on Xorg exits nautilus# Affected version
- Nightly flatpak: Yes
- Other: Arch Linux nautilus 40.0
# Steps to reproduce
1. Extract password protected archive of any type from nautilus with either "Extract Here" or "Extract..." options in right click menu on X...# Affected version
- Nightly flatpak: Yes
- Other: Arch Linux nautilus 40.0
# Steps to reproduce
1. Extract password protected archive of any type from nautilus with either "Extract Here" or "Extract..." options in right click menu on Xorg session.
# Current behavior
Nautilus exits with either of these errors:
```
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
nautilus: ../../src/xcb_io.c:163: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
```
```
[xcb] Unknown sequence number while processing reply
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
nautilus: ../../src/xcb_io.c:641: _XReply: Assertion `!xcb_xlib_threads_sequence_lost' failed.
```
```
Xlib: sequence lost (0x1525e > 0x526e) in reply type 0x1c!
(org.gnome.NautilusDevel:2): Gdk-WARNING **: 14:10:39.413: The program 'org.gnome.NautilusDevel' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 21112 error_code 2 request_code 18 (core protocol) minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
```
```
(org.gnome.NautilusDevel:2): Gdk-WARNING **: 14:12:56.893: The program 'org.gnome.NautilusDevel' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadImplementation (server does not implement operation)'.
(Details: serial 29908 error_code 17 request_code 20 (core protocol) minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
```
```
(org.gnome.Nautilus:86396): Gdk-ERROR **: 14:27:39.819: The program 'org.gnome.Nautilus' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadIDChoice (invalid resource ID chosen for this connection)'.
(Details: serial 68182 error_code 14 request_code 53 (core protocol) minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
(org.gnome.Nautilus:86396): Gdk-ERROR **: 14:27:39.819: The program 'org.gnome.Nautilus' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 68192 error_code 9 request_code 139 (RENDER) minor_code 4)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap (core dumped)
```
```
Gdk-Message: 14:10:57.855: org.gnome.NautilusDevel: Fatal IO error 11 (Resource temporarily unavailable) on X server :99.0.
```
```
Gdk-Message: 14:11:46.387: org.gnome.NautilusDevel: Fatal IO error 0 (Success) on X server :99.0.
```
# Expected behavior
Nautilus doesn't exit and proceeds to ask for a password for the archive, just like it correctly does on wayland session.
# Additional information
gnome-autoar log obtained with G_MESSAGES_DEBUG=all printed before one of the errors above:
```
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: autoar_common_get_basename_remove_extension: test.zip => test
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: autoar_extractor_run: Step 0 Begin
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: autoar_extractor_step_scan_toplevel: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_open_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_open_cb: ARCHIVE_OK
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_read_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_read_cb: 1321
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_read_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_read_cb: 0
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_seek_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_seek_cb: 1321
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_seek_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_seek_cb: 1321
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_seek_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_seek_cb: 1321
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.119: libarchive_read_seek_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_seek_cb: 0
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_read_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_read_cb: 1321
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_seek_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_seek_cb: 1321
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_seek_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_seek_cb: 1199
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_read_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_read_cb: 122
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_seek_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_seek_cb: 1321
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_seek_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_seek_cb: 0
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_read_cb: called
** (org.gnome.Nautilus:85957): DEBUG: 14:17:24.120: libarchive_read_read_cb: 1321
```
stack trace obtained with gdb:
```
#0 0x00007fa67e9ffd98 in g_log_writer_default () at /usr/lib/libglib-2.0.so.0
#1 0x00007fa67e9fbb69 in g_log_structured_array () at /usr/lib/libglib-2.0.so.0
#2 0x00007fa67e9fbd71 in g_log_structured_standard () at /usr/lib/libglib-2.0.so.0
#3 0x00007fa67e19da17 in () at /usr/lib/libgdk-3.so.0
#4 0x00007fa67d301aa5 in _XError () at /usr/lib/libX11.so.6
#5 0x00007fa67d2fe6f8 in () at /usr/lib/libX11.so.6
#6 0x00007fa67d2fe795 in () at /usr/lib/libX11.so.6
#7 0x00007fa67d2ff1ea in _XEventsQueued () at /usr/lib/libX11.so.6
#8 0x00007fa67d2f0a92 in XPending () at /usr/lib/libX11.so.6
#9 0x00007fa67e199446 in () at /usr/lib/libgdk-3.so.0
#10 0x00007fa67e9f5342 in g_main_context_check () at /usr/lib/libglib-2.0.so.0
#11 0x00007fa67ea48a8b in () at /usr/lib/libglib-2.0.so.0
#12 0x00007fa67e9f2781 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#13 0x00007fa67de1c22e in g_application_run () at /usr/lib/libgio-2.0.so.0
#14 0x000055d01b2b60fa in main ()
```
<!-- Ignore the text under this line. -->Ondrej HolyOndrej Holyhttps://gitlab.gnome.org/GNOME/gimp/-/issues/6713Bug in printer (French Windows10)2022-09-28T14:11:34ZMichel MénardBug in printer (French Windows10)Hello
My Windows 10 is in French.
And when I want to print in Gimp, I am missing part of the window.![BugPrintGimp2.10.24](/uploads/6949596c4798a9d3438e666688335545/BugPrintGimp2.10.24.png)Hello
My Windows 10 is in French.
And when I want to print in Gimp, I am missing part of the window.![BugPrintGimp2.10.24](/uploads/6949596c4798a9d3438e666688335545/BugPrintGimp2.10.24.png)https://gitlab.gnome.org/GNOME/nautilus/-/issues/1824App chooser is useless while sandboxed2022-06-26T20:46:07ZEshaghApp chooser is useless while sandboxed# Affected version
- Nightly flatpak: Yes
version: nautilus-3.38.2
I tried it in GNOME Builder
ubuntu 20.04, The default Nautilus is not a problem
# Steps to reproduce
1. run nautilus
2. Select a PDF
3. Select "Open with" option
4. S...# Affected version
- Nightly flatpak: Yes
version: nautilus-3.38.2
I tried it in GNOME Builder
ubuntu 20.04, The default Nautilus is not a problem
# Steps to reproduce
1. run nautilus
2. Select a PDF
3. Select "Open with" option
4. Select "Show more" option
# Current behavior
<!-- Describe the current behavior. -->
The problem is obvious in the image
![Screenshot_from_2021-04-10_09-18-03](/uploads/f1c82351f7725535a8137245643fc9c8/Screenshot_from_2021-04-10_09-18-03.png)
# Expected behavior
<!-- Describe the expected behavior. -->
# Additional informationhttps://gitlab.gnome.org/GNOME/gvfs/-/issues/560webdav ignores status code in propfind response when querying info2021-04-14T07:49:26ZTim Schumacherwebdav ignores status code in propfind response when querying infoWhen running just query_info on a nonexistent file (for example through `ls`), the file is handled as if it was existent, but it appears to just return placeholder data (according to `ls -l`: 0 bytes, created in January of 1970, etc.).
...When running just query_info on a nonexistent file (for example through `ls`), the file is handled as if it was existent, but it appears to just return placeholder data (according to `ls -l`: 0 bytes, created in January of 1970, etc.).
Trying to read from the file or deleting/moving it will correctly cause a "file not found" error.
As far as I can replicate using curl, the server does appear to send the proper 404 error when accessing that file (indents added for readability):
```
$ curl -u user:password -i -X PROPFIND https://webdav.example.com/file_that_does_not_exist
HTTP/2 207
server: nginx/1.18.0 (Ubuntu)
date: Sat, 10 Apr 2021 12:53:30 GMT
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/file_that_does_not_exist</D:href>
<D:propstat>
<D:prop>
</D:prop>
<D:status>HTTP/0.0 404 Not Found</D:status>
</D:propstat>
</D:response>
</D:multistatus>
```
When running gvfs-dav with debug output enabled, this shows up when trying to access the file:
```
dav: backend_dbus_handler org.gtk.vfs.Mount:QueryInfo (pid=1384)
dav: Queued new job 0x55a7a0dba530 (GVfsJobQueryInfo)
dav: Query info /file_that_does_not_exist
dav: send_reply(0x55a7a0dba530), failed=0 ()
```
When trying to delete said file (which produces the "expected" outcome), this appears:
```
dav: backend_dbus_handler org.gtk.vfs.Mount:QueryInfo (pid=1384)
dav: Queued new job 0x55a7a0dba5d0 (GVfsJobQueryInfo)
dav: Query info /file_that_does_not_exist
dav: send_reply(0x55a7a0dba5d0), failed=0 ()
dav: backend_dbus_handler org.gtk.vfs.Mount:QueryInfo (pid=1384)
dav: Queued new job 0x55a7a0dba490 (GVfsJobQueryInfo)
dav: Query info /file_that_does_not_exist
dav: send_reply(0x55a7a0dba490), failed=0 ()
dav: backend_dbus_handler org.gtk.vfs.Mount:Delete (pid=1384)
dav: Queued new job 0x55a7a0dc8150 (GVfsJobDelete)
dav: send_reply(0x55a7a0dc8150), failed=1 (Not Found)
```https://gitlab.gnome.org/GNOME/gimp/-/issues/6708Bug saving xcf2022-09-28T14:18:20ZFranyBoston27Bug saving xcf### Environment/Versions
- GIMP version:2.10.24-2.10.22-2.10.20
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->Installer from gimp.org
- Operating System: <!--...### Environment/Versions
- GIMP version:2.10.24-2.10.22-2.10.20
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->Installer from gimp.org
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) -->Windows 10 Pro
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->Hello everybody. I wanted to point out a bug, also quite annoying. In the latest versions of GIMP saving the xcf file gives an error, saying it does not have permission to rename the temporary file. To understand if it was a problem with the file I did a test: I installed version 2.10.24 but the error was still there and so to go down to 2.10.20; then I downloaded the development (2.99.4) and the error was no longer present, same thing with the stable 2.10.14 ... All with the exact same file ... If you solve the problem with a 2.10.25 it won't it would be bad. Attach image with error. (I checked the security options and I put "Everyone" as entity but nothing has changed, and in any case it could not be seen that changing version backwards or forwards with the development, the problem is solved)
![Error](/uploads/65f39eb8d741ec13030fd9304b16cf6e/Error.png)
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)-->Alaways
Reproduction steps:
1. Open xcf
2. Save this
3. Error
…
Expected result:
Actual result:
### Additional information
If you have a backtrace for a crash or a warning, paste it here.https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4075Shell crashed while dragging window to workspace switcher2021-04-24T11:05:39ZFelipe Borgesfelipeborges@gnome.orgShell crashed while dragging window to workspace switcher<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Fedora Sil...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Fedora Silverblue (34.20210405.n.0 (2021-04-05T08:10:21Z)
* GNOME Shell 40.0
* Wayland
-->
### Bug summary
I dragged a Firefox window to the workspace switcher, attempting to move it to another workspace. The session crashed.
### Steps to reproduce
1. Have at least 3 workspaces in place
2. Dragged Firefox from the first workspace to the third one (in the workspace switcher)
3. See the crash.
### What happened
Shell crashed.
### Relevant logs, screenshots, screencasts etc.
[backtrace.txt](/uploads/c85fd1b6bef868fd5d3f41d8c6404049/backtrace.txt)
I also see this in the journal
```
[feborges@t580 ~]$ journalctl -n 50 --since "1 hour ago" | grep gnome-shell
Apr 09 14:41:03 t580 gnome-shell[1778]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Apr 09 14:41:03 t580 gnome-shell[1778]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Apr 09 14:41:03 t580 gnome-shell[1778]: meta_monitor_manager_get_logical_monitor_from_number: assertion '(unsigned int) number < g_list_length (manager->logical_monitors)' failed
Apr 09 14:41:03 t580 gnome-shell[1778]: meta_workspace_get_work_area_for_monitor: assertion 'logical_monitor != NULL' failed
Apr 09 14:41:05 t580 systemd[1083]: Started Application launched by gnome-shell.
Apr 09 14:41:05 t580 systemd[1083]: Started Application launched by gnome-shell.
```
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gimp/-/issues/6702GIMP not loading raw files from darktable2024-01-11T23:48:55ZNeverestGIMP not loading raw files from darktable### Environment/Versions
- GIMP version:GIMP 2.10.24 (revision 2)
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->Chocolatey package
- Operating System: <!--[Wi...### Environment/Versions
- GIMP version:GIMP 2.10.24 (revision 2)
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)-->Chocolatey package
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows 64-bit
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
<!--Please describe your issue with details.
Add screenshot or other files if needed.(write it after the > symbol)-->Whenever I try to open a raw file it opens darktable, but when I close it and it tries to load on GIMP, I get a window with two errors. Tried with NEF, dng, ARW, RW2, CR2.
![image](/uploads/b5616c3cc4d00590b8f99e62b06605f5/image.png)
![image](/uploads/caf01c740360b3a1b9e39c1740e72e52/image.png)
![image](/uploads/93ad18d95a648e40d8930b143fa953ff/image.png)
![image](/uploads/f62093b2773a8de5f0a17bf9ef2611d1/image.png)
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
1. Open GIMP
2. Try to open a raw file using darktable
3. Close darktable and see the error
…
Expected result:Open a raw file to edit.
Actual result:Cant open them.
### Additional information
If you have a backtrace for a crash or a warning, paste it here.https://gitlab.gnome.org/GNOME/gimp/-/issues/6701The procedure entry point g_memdup2 could not be located2022-09-28T14:19:56ZHans Peter BetzlerThe procedure entry point g_memdup2 could not be located![The_procedure_entry_point_g_memdup2_could_not_be_located](/uploads/43ab16ea1077c0191505a708d78ab1ff/The_procedure_entry_point_g_memdup2_could_not_be_located.jpg)![The_procedure_entry_point_g_memdup2_could_not_be_located](/uploads/43ab16ea1077c0191505a708d78ab1ff/The_procedure_entry_point_g_memdup2_could_not_be_located.jpg)https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/60Indefinite SelectionRead() requests cannot be cancelled/aborted2021-07-28T15:25:40ZPascal NowackIndefinite SelectionRead() requests cannot be cancelled/abortedCurrently, if a remote desktop client doesn't provide the clipboard content (in time), mutter will abort the `SelectionTransfer()`. This works fine.
But if an application on the server side, doesn't provide the clipboard content (at al...Currently, if a remote desktop client doesn't provide the clipboard content (in time), mutter will abort the `SelectionTransfer()`. This works fine.
But if an application on the server side, doesn't provide the clipboard content (at all), mutter doesn't abort that request too.
Instead, gnome-remote-desktop waits indefinitely for content on the pipe. Since this action happens on the main thread in g-r-d, stopping the remote desktop session won't work.
The only way to get rid of this situation is by killing g-r-d.
To reproduce the situation:
1. Connect with a RDP client to g-r-d (since the RDP backend can handle images via the clipboard)
2. Run libreoffice (writer) on the server side
3. Insert in libreoffice (writer) some graph.
4. Copy that graph
5. Try to paste it on the client side
g-r-d will now try to fetch the image content via `SelectionRead()`, but libreoffice (writer) won't (bug in lo) provide that image.
The effect is that g-r-d will indefinitely hang in `len = read (fd, buffer, G_N_ELEMENTS (buffer));` (in g-r-d (`grd-session.c`)).
To get rid of this situation, the `read()` call needs to be stopped somehow. mutter could maybe run some timeout source to close the fd at some point. Not sure though how situations should then be handled where the application already provided some data (len is then > 0).
I also don't know whether libreoffice already wrote some data, since `len` is in my backtrackes always optimized out.
At the same time, I am thinking what g-r-d could do. Having another thread that runs a GSource to cancel such requests upon timeout or disconnection doesn't sound nice, but if the remote desktop client disconnects, g-r-d should also be able to stop the `SelectionRead()` request.
Affects obviously mutter-40 and g-r-d-40, since we implemented clipboard support for GNOME 40.
CC: @jadahl
<details>
<summary>g-r-d backtrace</summary>
```
Thread 1 (LWP 2032 "gnome-remote-de"):
#0 0x00007fe3128fa87c in read () at /usr/lib/libpthread.so.0
#1 0x000055ee29ac2ecc in read (__nbytes=1024, __buf=0x7ffff3d39480, __fd=77) at /usr/include/bits/unistd.h:47
len = <optimized out>
buffer = "\000\000\000\000\000\000\000\000\000\265\212Y\"\355\216\027P\225\323\363\377\177\000\000K\367\376\022\343\177\000\000q`\376\022\343\177\000\000\260n\002,\356U\000\000P\225\323\363\377\177\000\000\001\000\000\000\000\000\000\000:\367\376\022\343\177\000\000\331\363\375\022\343\177\000\000P\225\323\363\377\177\000\000\212&\n\302\317", '\000' <repeats 11 times>, "\030\225\323\363\377\177\000\000\340\226\323\363\377\177\000\000\004\000\000\000\000\000\000\000p\224\000\374\342\177\000\000\000\265\212Y\"\355\216\027\320\346\065,\356U\000\000 \000\000\334\342\177\000\000p\032\000\334\342\177\000\000X\000\000\000\000\000\000\000X\000\000\000\000\000\000\000`\032\000\334\342\177\000\000p\000\000\000\000\000\000\000"...
priv = <optimized out>
error = 0x0
fd_variant = 0x55ee2b9516c0
fd_list = 0x55ee2c04ccb0
fd_idx = 0
fd = 77
mime_type_string = <optimized out>
data = 0x55ee2b9a5760
#2 grd_session_selection_read (session=<optimized out>, mime_type=mime_type@entry=GRD_MIME_TYPE_IMAGE_PNG, size=size@entry=0x7ffff3d398fc) at ../gnome-remote-desktop/src/grd-session.c:364
len = <optimized out>
buffer = "\000\000\000\000\000\000\000\000\000\265\212Y\"\355\216\027P\225\323\363\377\177\000\000K\367\376\022\343\177\000\000q`\376\022\343\177\000\000\260n\002,\356U\000\000P\225\323\363\377\177\000\000\001\000\000\000\000\000\000\000:\367\376\022\343\177\000\000\331\363\375\022\343\177\000\000P\225\323\363\377\177\000\000\212&\n\302\317", '\000' <repeats 11 times>, "\030\225\323\363\377\177\000\000\340\226\323\363\377\177\000\000\004\000\000\000\000\000\000\000p\224\000\374\342\177\000\000\000\265\212Y\"\355\216\027\320\346\065,\356U\000\000 \000\000\334\342\177\000\000p\032\000\334\342\177\000\000X\000\000\000\000\000\000\000X\000\000\000\000\000\000\000`\032\000\334\342\177\000\000p\000\000\000\000\000\000\000"...
priv = <optimized out>
error = 0x0
fd_variant = 0x55ee2b9516c0
fd_list = 0x55ee2c04ccb0
fd_idx = 0
fd = 77
mime_type_string = <optimized out>
data = 0x55ee2b9a5760
#3 0x000055ee29ac785f in grd_clipboard_request_server_content_for_mime_type (clipboard=clipboard@entry=0x55ee2b91eb80, mime_type=mime_type@entry=GRD_MIME_TYPE_IMAGE_PNG, size=size@entry=0x7ffff3d398fc) at ../gnome-remote-desktop/src/grd-clipboard.c:92
priv = 0x55ee2b91eb60
data = <optimized out>
#4 0x000055ee29ac79f0 in request_server_format_data (user_data=0x7fe2dc001a40, user_data@entry=<error reading variable: value has been optimized out>) at ../gnome-remote-desktop/src/grd-clipboard-rdp.c:1074
request_context = 0x7fe2dc001a40
clipboard_rdp = 0x55ee2b91eb80
clipboard = 0x55ee2b91eb80
cliprdr_context = 0x55ee2c316d90
format_data_response = {msgType = 0, msgFlags = 0, dataLen = 0, requestedFormatData = 0x0}
mime_type = GRD_MIME_TYPE_IMAGE_PNG
src_format_id = 0
dst_format_id = 53265
src_data = 0x0
dst_data = 0x0
src_size = 0
dst_size = 0
success = <optimized out>
#5 0x00007fe312f92f44 in g_timeout_dispatch (source=0x7fe2dc001ae0, callback=<optimized out>, user_data=<optimized out>) at ../glib/glib/gmain.c:4877
timeout_source = 0x7fe2dc001ae0
again = <optimized out>
#6 0x00007fe312f9273b in g_main_dispatch (context=0x55ee2b920a20) at ../glib/glib/gmain.c:3325
dispatch = 0x7fe312f92f30 <g_timeout_dispatch>
prev_source = 0x0
begin_time_nsec = 892314305504
was_in_call = <optimized out>
user_data = 0x7fe2dc001a40
callback = 0x55ee29ac78b8 <request_server_format_data>
cb_funcs = 0x7fe3130703a0 <g_source_callback_funcs>
cb_data = 0x7fe2dc001960
need_destroy = <optimized out>
source = 0x7fe2dc001ae0
current = 0x55ee2b90fa00
i = 0
#7 g_main_context_dispatch (context=0x55ee2b920a20) at ../glib/glib/gmain.c:4043
#8 0x00007fe312fe53b1 in g_main_context_iterate.constprop.0 (context=context@entry=0x55ee2b920a20, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:4119
max_priority = 2147483647
timeout = -1
some_ready = 1
nfds = 4
allocated_nfds = 4
fds = 0x7fe30000ba30
begin_time_nsec = 892313981028
#9 0x00007fe312f910d9 in g_main_context_iteration (context=context@entry=0x55ee2b920a20, may_block=may_block@entry=1) at ../glib/glib/gmain.c:4184
retval = <optimized out>
#10 0x00007fe312e533c6 in g_application_run (application=application@entry=0x55ee2b91e950, argc=-204236060, argv=<optimized out>) at ../glib/gio/gapplication.c:2559
arguments = 0x55ee2b9529d0
status = 0
context = 0x55ee2b920a20
acquired_context = <optimized out>
__func__ = "g_application_run"
#11 0x000055ee29abf243 in main (argc=<optimized out>, argv=<optimized out>) at ../gnome-remote-desktop/src/grd-daemon.c:381
settings = <optimized out>
print_version = 0
rdp_port = -1
vnc_port = -1
entries = {{long_name = 0x55ee29add7a2 "version", short_name = 0 '\000', flags = 0, arg = G_OPTION_ARG_NONE, arg_data = 0x7ffff3d39b64, description = 0x55ee29add79c "Print version", arg_description = 0x0}, {long_name = 0x55ee29add7aa "rdp-port", short_name = 0 '\000', flags = 0, arg = G_OPTION_ARG_INT, arg_data = 0x7ffff3d39b60, description = 0x55ee29add7b3 "RDP port", arg_description = 0x0}, {long_name = 0x55ee29add7bc "vnc-port", short_name = 0 '\000', flags = 0, arg = G_OPTION_ARG_INT, arg_data = 0x7ffff3d39b5c, description = 0x55ee29add7c5 "VNC port", arg_description = 0x0}, {long_name = 0x0, short_name = 0 '\000', flags = 0, arg = G_OPTION_ARG_NONE, arg_data = 0x0, description = 0x0, arg_description = 0x0}}
context = 0x55ee2b9182e0
app = 0x55ee2b91e950
error = 0x0
(gdb)
```
</details>https://gitlab.gnome.org/GNOME/swell-foop/-/issues/22Cannot run from Activities2021-04-08T06:39:13ZJan TojnarCannot run from ActivitiesTesting GNOME 40 update on NixOS, when I try to launch Swell Foop using the Shell's Activities, it does not open and the following is logged to journal:
```
org.gnome.SwellFoop[1982]: Unknown option --gapplication-service
dbus-daemon[93...Testing GNOME 40 update on NixOS, when I try to launch Swell Foop using the Shell's Activities, it does not open and the following is logged to journal:
```
org.gnome.SwellFoop[1982]: Unknown option --gapplication-service
dbus-daemon[938]: [session uid=1000 pid=938] Activated service 'org.gnome.SwellFoop' failed: Process org.gnome.SwellFoop exited with status 1
```
Launching it using command (without `--gapplication-service`) works.
Version: 40.0GNOME 40Robert RothRobert Rothhttps://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4056Unable to select window with tab or arrow key in Overview in 40, 412022-04-14T02:07:29ZElliott ShugermanUnable to select window with tab or arrow key in Overview in 40, 41It used to be that <kbd>Tab</kbd> could be used to select a window from the Overview. This feature seems to be absent from GNOME 40. Could it make a comeback? It was a really nice way to switch windows :smiley: ! I'd think it's important...It used to be that <kbd>Tab</kbd> could be used to select a window from the Overview. This feature seems to be absent from GNOME 40. Could it make a comeback? It was a really nice way to switch windows :smiley: ! I'd think it's important for accessibility too, though I don't know much about that.https://gitlab.gnome.org/GNOME/gimp/-/issues/6695Wrong Tab After jpg Export because of "Show preview" feature2021-04-30T23:10:47ZAkoviaWrong Tab After jpg Export because of "Show preview" feature### Environment/Versions
- GIMP version: 2.10.24
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> Arch
- Operating System: <!--[Windows? macOS? Linux? All?] (w...### Environment/Versions
- GIMP version: 2.10.24
- Package: <!--[flatpak? Installer from gimp.org? If another installer, tell us where from] (write it after the > symbol)--> Arch
- Operating System: <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Linux
<!--Note: bug reporters are expected to have verified the bug still exists
either in the last stable version of GIMP or on updated development code
(master branch).-->
### Description of the bug
If you have more than 1 image tab open and you export one of those images to jpg, and that image is not in the rightmost tab, the program will return you to the rightmost tab once the export is complete.
This is endlessly frustrating when trying to export images to multiple locations as it's easy to export the wrong image when moving quickly. Even when paying attention, you have to find the right tab to select to get back to the image you were working on to either continue to work, or to export again. This doesn't happen when exporting to png, and this was not the behavior for any image type before 2.10 IIRC.
### Reproduction
Is the bug reproducible? <!--[Always / Randomly / Happened only once ] (write it after the > symbol)--> Always
Reproduction steps:
1. Open multiple images in separate tabs.
2. Select any image in any tab other than the rightmost tab.
3. Export that image to jpg.
4. Once fully exported, you should now be looking at the image in the rightmost tab. Not the image you were working on.
Expected result:
Be returned to the image you exported.
Actual result:
Returned to a different, unrelated image unless you were working in the rightmost tab.
### Additional information
I tried this at work on a Windows machine and didn't experience the issue.2.99.8