Bug 141097 - LibreOffice doesn't close when opened through API on Sybase PowerBuilder
Summary: LibreOffice doesn't close when opened through API on Sybase PowerBuilder
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.5.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Michael Warner
URL:
Whiteboard: target:7.3.0 target:7.2.1
Keywords:
: 139023 141513 143966 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-03-18 11:04 UTC by Makrea
Modified: 2021-12-08 16:01 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Exceptions shown on Procdump using File->Close or X Button (84.78 KB, image/png)
2021-03-18 11:06 UTC, Makrea
Details
Dump created by the monitoring done with Procdump (557.95 KB, application/x-7z-compressed)
2021-03-18 11:07 UTC, Makrea
Details
Backtrace_LO_7.1.2.1_x64_windbg_x64 (22.86 KB, text/plain)
2021-03-29 10:11 UTC, Makrea
Details
LO_backtrace_notes (62.86 KB, image/png)
2021-03-29 10:21 UTC, Makrea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Makrea 2021-03-18 11:04:04 UTC
Description:
Using LibreOffice Writer version 7.0.5.2 x64 when opened through API on Sybase PowerBuilder the document that was opened cannot be closed.

Closing using File->Close doesn't work.
Closing using X Button also doesn't work.

This problem doesn't happen on LibreOffice version 6.3.5.2 x64 release.

NOTE:
I inform that the version dropdown here in bugzilla doesn't list 7.0.5.2 release.
Because of that I selected 7.0.4.2 release but my version is 7.0.5.2 release.

Version: 7.0.5.2 (x64)
Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: pt-PT (pt_PT); Interface: pt-PT
Calc: threaded

Steps to Reproduce:
1.Using API with Sybase Powerbuilder open a document on LibreOffice Writer.
2.Close the document using File->Close
3.Close the document using X Button of the window

Actual Results:
1.Closing on File->Close doesn't close the document
2.Closing on X Button of the window doesn't close the document.


Expected Results:
Should close the document.


Reproducible: Always


User Profile Reset: No



Additional Info:
I've monitored this LibreOffice behavior using Procdump v10.0.
See the attached image for more information.

Also attached goes the actual dump that is created by Procdump.

This problem doesn't happen on LibreOffice version 6.3.5.2 x64 release.
Comment 1 Makrea 2021-03-18 11:06:29 UTC
Created attachment 170547 [details]
Exceptions shown on Procdump using File->Close or X Button

Exceptions shown on Procdump using File->Close or X Button
Comment 2 Makrea 2021-03-18 11:07:39 UTC
Created attachment 170548 [details]
Dump created by the monitoring done with Procdump

Dump created by the monitoring done with Procdump
Comment 3 Makrea 2021-03-18 11:20:34 UTC
The behavior is reproducible invoking LibreOffice 7.0.5.2 through API using Sybase Powerbuilder IDE or invoking LibreOffice 7.0.5.2 through API using the executable version of the deployed application.

The exceptions thrown are these:

Exception: E06D7363.?AVTerminationVetoException@frame@star@sun@com@@
Exception: 406D1388


As mentioned before LibreOffice 6.3.5.2 doesn't has this behavior.
Comment 4 Julien Nabet 2021-03-18 19:08:15 UTC
I suppose someone on Windows could use the procdump.
For those on Linux perhaps a backtrace retried with Windbg could help:
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:_How_to_get_a_backtrace

About TerminationVetoException, I found this:
     31     If a XTerminateListener use this exception for a veto against
     32     the termination of the office, he will be the new "owner" of it.
     33     After his own operation will be finished, he MUST try to terminate the
     34     office again. Any other veto listener can intercept that again or office
     35     will die really.
     36 
     37     Since LibreOffice 5.3:
     38     Throwing this exception will only prevent *termination*.
     39     Exiting LibreOffice will close all the windows, but the process will keep running.
See https://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/frame/TerminationVetoException.idl?r=6d9f07d5

You can give a try at https://wiki.documentfoundation.org/QA/FirstSteps just to exclude corruption LO profile and skia parts.
Comment 5 Makrea 2021-03-19 11:32:15 UTC
Hi Julien Nabet.

Thanks for the feedback.

My understanding of the information you sent is that the process that invokes LO through API becomes the only one that can actually terminate LO.

Was this an intended change?
What is the use case that was needed to be met?
Is there any more detail about the changes that originates this current behavior?


--> Opening LO through API, import data into LO using it's API, and then user interacts with LO's GUI and eventually close LO through it's GUI in my opinion is a very frequent use case.


Best Regards.
Comment 6 Makrea 2021-03-19 12:09:56 UTC
"You can give a try at https://wiki.documentfoundation.org/QA/FirstSteps just to exclude corruption LO profile and skia parts."

Regarding this advice I did a reset of the user profile, some things changed about Skia, now is Vulkan, before was Raster.
I also disabled extensions.

Nevertheless the behavior that was described in this bug is unchanged.
It's not possible to close LO by it's GUI when LO is opened through it's API.

Best Regards
Comment 7 Makrea 2021-03-26 10:35:30 UTC
This bug is also present on 7.1.2.1 version.


Information:

Version: 7.1.2.1 (x64) / LibreOffice Community
Build ID: 094b4116e8de6d2085e9b65d26912d6eac4c74a9
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: pt-PT (pt_PT); UI: pt-PT
Calc: threaded


Best regards
Comment 8 Makrea 2021-03-29 10:10:11 UTC
(In reply to Julien Nabet from comment #4)
> I suppose someone on Windows could use the procdump.
> For those on Linux perhaps a backtrace retried with Windbg could help:
> https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:
> _How_to_get_a_backtrace
> 
> About TerminationVetoException, I found this:
>      31     If a XTerminateListener use this exception for a veto against
>      32     the termination of the office, he will be the new "owner" of it.
>      33     After his own operation will be finished, he MUST try to
> terminate the
>      34     office again. Any other veto listener can intercept that again
> or office
>      35     will die really.
>      36 
>      37     Since LibreOffice 5.3:
>      38     Throwing this exception will only prevent *termination*.
>      39     Exiting LibreOffice will close all the windows, but the process
> will keep running.
> See
> https://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/frame/
> TerminationVetoException.idl?r=6d9f07d5
> 
> You can give a try at https://wiki.documentfoundation.org/QA/FirstSteps just
> to exclude corruption LO profile and skia parts.

Hi Julien Nabet,

I recorded a backtrace with WinDBG.

Attached to this bug you will find a image with some written notes about what happened at every specific point in time and the backtrace file.

I think the Exception Analysis on the file will be useless because I think WinDBG analysed the break o soffice.bin on WinDBG because the reported bug doesn't crash LO and killing the soffice.bin process on task manager wouldn't make possible a !analyze -v execution.

Maybe I've done something wrong about the backtrace.
Feel free to suggest something.

I think looking to the notes on the image might be more interesting.

Best regards
Comment 9 Makrea 2021-03-29 10:11:49 UTC
Created attachment 170806 [details]
Backtrace_LO_7.1.2.1_x64_windbg_x64
Comment 10 Makrea 2021-03-29 10:21:34 UTC
Created attachment 170807 [details]
LO_backtrace_notes
Comment 11 kabilo 2021-03-31 06:34:35 UTC
similar problems in:
Bug 139023 - LO 7.0.4 cannot be terminated on win2012 in terminal server mode sometimes
Bug 140737 - Writer: Can not close the program window
Comment 12 Makrea 2021-03-31 10:43:35 UTC
(In reply to kabilo from comment #11)
> similar problems in:
> Bug 139023 - LO 7.0.4 cannot be terminated on win2012 in terminal server
> mode sometimes
> Bug 140737 - Writer: Can not close the program window

Thanks kabilo.
Replied on both bugs with questions and instructions to follow to further analyse the bugs that Knecker and you are having.
For me, my bug and yours are the same.

Best regards
Comment 13 Makrea 2021-04-05 10:59:13 UTC
Hi,

I compared the code of 7.1.2.2 vs 6.3.5.2 on the following file
libreoffice-7.1.2.2\extensions\source\ole\unoobjw.cxx
libreoffice-6.3.5.2\extensions\source\ole\unoobjw.cxx


And I see that:

1- there are some new includes on 7.1.2.2:
#include <com/sun/star/frame/TerminationVetoException.hpp>
#include <com/sun/star/frame/XTerminateListener.hpp>

2- this comment on line 105 explains the reported bug:
 // Always veto termination while an OLE object is active, except if it is an OLE object that
 // has asked us to quit.


This implementation of veto regarding OLE object is completely biased because you assume that the interaction will be completely done through OLE object, eg, create/open a odt/ott minimized or invisible, import data, save, close.
When in most use cases the OLE object will be used as well to create/open a odt/ott, import data, turn document visible, permit user interaction and then save on GUI and close by user interaction.

My suggestion is make this Veto behavior an option on the API or on LO's GUI.
Or, using other words, the veto that is being currently forced should be optional when using OLE object.

By default the new suggested option can implement this Veto behavior and I will change on my side to permit user interaction to close on GUI.
If there is already an UNO function regarding this suggestion please send me the link for me to read.


PS:
Maybe there is more code related to this bug on other code files.
This comparison that I made of unoobjw.cxx file appeared like the most relevant to me.


Best regards
Comment 14 Buovjaga 2021-04-19 12:56:56 UTC
*** Bug 141513 has been marked as a duplicate of this bug. ***
Comment 15 Buovjaga 2021-04-19 12:58:02 UTC
In bug 141513, Advantage Database is in use with API
Comment 16 Makrea 2021-04-19 17:38:27 UTC
(In reply to Buovjaga from comment #15)
> In bug 141513, Advantage Database is in use with API

Since that code that I analysed on https://bugs.documentfoundation.org/show_bug.cgi?id=141097#c13 was made all LO opened through API breaks closing on GUI so I'm not surprised by the existence of several bugs that are reported regarding this precise issue.
Comment 17 Makrea 2021-06-02 12:58:08 UTC
Removed keyword wantBacktrace.

Backtrace was given on 2021-03-29.

For what I see this bug is more than confirmed, it already has a duplicate, so I'm very disappointed that isn't being given the proper attention to this issue.
The usage of LO API to generate a document and turn document visible is only done by 3 or 4 people worldwide?!

Best Regards
Comment 18 Algarvi0 2021-07-05 08:48:44 UTC Comment hidden (me-too)
Comment 19 Michael Warner 2021-07-06 04:01:19 UTC
@Makrea, I am not very familiar with OLE or LO's interaction with it, so please forgive if I am asking a bad question. However, in the comment you quoted, the words "is active" stood out to me:

// Always veto termination while an OLE object is active

In the use case you provide, it sounds like you don't need to interact with OLE any more once the document is open. Is there any way you can de-activate or end the OLE session at that point?
Comment 20 Makrea 2021-07-06 13:45:23 UTC
(In reply to Michael Warner from comment #19)
> @Makrea, I am not very familiar with OLE or LO's interaction with it, so
> please forgive if I am asking a bad question. However, in the comment you
> quoted, the words "is active" stood out to me:
> 
> // Always veto termination while an OLE object is active
> 
> In the use case you provide, it sounds like you don't need to interact with
> OLE any more once the document is open. Is there any way you can de-activate
> or end the OLE session at that point?

Hi Michael Warner,

> please forgive if I am asking a bad question

Feel free to ask all questions.
I'm more than available to see this issue solved once and for all.

> In the use case you provide, it sounds like you don't need to interact with
> OLE any more once the document is open.

That's true most of the times.
I'll give you some real world examples where that's not 100% true.
Say you have a template and you need to insert text and bookmarks.
On this occasion the OLE object that links to the LibreOffice instance will be used by means of UI and at a lower layer invokes API calls to LibreOffice.
To be more specific say a UI window that you double click to set a specific bookmark on a template at a specific insertion point.

Say now that the user wants to close and save the template. It can save but cannot close the template document because of the veto limitation that was inserted.
I asked on comment 5 what was the use case that needed to be met that caused this change. All I got was silence....

This is only one example I can give.
Another example is:
Say a Calc sheet and data is exported to cells.
The user can't close the sheet after export.

You will excuse me the sentence but here it goes.
This veto implementation was poorly designed and collides with all real word use cases that involves user interaction.

>Is there any way you can de-activate
> or end the OLE session at that point?

Maybe. But I feel that isn't a straightforward (point in time) action to be made because of user unpredictability .
I don't investigated that because my opinion is that this veto exception error originates from a 100% wrong approach to API LibreOffice usage.

Please see that, as it stands now, it completely disregards the possibility of real world user interaction with Libreoffice close by UI. Legitimate real world user actions.

So our course of action was all instances didn't update and this bug link was made publicly known to all users that updated, reported this issue, and then had to go back to a previous LibreOffice version.

I think I will give your question back to you.
On comment 13 (3 months ago) I already went somewhat on that course.

>By default the new suggested option can implement this Veto behavior and I >will change on my side to permit user interaction to close on GUI.
>If there is already an UNO function regarding this suggestion please send >me the link for me to read.

So, is there any way you can de-activate or end the OLE session at that point?

Best regards.
Comment 21 Michael Warner 2021-07-06 19:07:15 UTC
Thanks to Makrea's work in Comment 13, I can see that the VetoTermination code was added in this commit:

commit 89f883bd90a50587868a57397b6350ed9559a20f
Author: Tor Lillqvist <tml@collabora.com>
Date:   Mon Jun 10 15:41:28 2019 +0300

    Veto process exit while an OLE client is connected
    
    Change-Id: Iad9fc1742ae371a8a162edbc16998e9cb6895919
    Reviewed-on: https://gerrit.libreoffice.org/73763
    Tested-by: Jenkins
    Reviewed-by: Tor Lillqvist <tml@collabora.com>

Then, modified here:

commit 05e03911cd1f8a355b6410d3997cffc2c794a1e9
Author: Tor Lillqvist <tml@collabora.com>
Date:   Wed Aug 21 11:57:28 2019 +0300

@Tor, do you have any advice here?
Comment 22 Tor Lillqvist 2021-07-07 08:21:28 UTC
As far as I know the functionality my change was for is not needed any more, so if it is of benefit to revert it, be my guest.
Comment 23 Makrea 2021-07-07 09:11:02 UTC
I would like to thank Michael Warner and Tor Lillqvist for your input.
If you create a test build I can further validate it for you.

(I analysed the link you posted and it seems like it's the only files to be reverted.)

I would also like to thank kabilo for making the effort to find other similar and apparently related bugs that ultimately had the effect to strengthen this bug I posted.

Best regards.
Comment 24 QA Administrators 2021-07-08 03:44:00 UTC Comment hidden (obsolete)
Comment 25 Michael Warner 2021-07-16 13:12:25 UTC
Just to follow up in BZ as well, I submitted a patch for this last week here:
https://gerrit.libreoffice.org/c/core/+/118596

It's just waiting for review now.
Comment 26 Makrea 2021-07-17 16:37:07 UTC
(In reply to Michael Warner from comment #25)
> Just to follow up in BZ as well, I submitted a patch for this last week here:
> https://gerrit.libreoffice.org/c/core/+/118596
> 
> It's just waiting for review now.



Thanks for the feedback Michael!

Best regards.
Comment 27 Julien Nabet 2021-08-20 09:42:39 UTC
*** Bug 143966 has been marked as a duplicate of this bug. ***
Comment 28 Commit Notification 2021-08-20 09:43:51 UTC
Michael Warner committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/080e4550257a90597c241f83fd766b99c83ba6e8

tdf#141097 Revert "Veto process exit while an OLE client is connected"

It will be available in 7.3.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 29 Julien Nabet 2021-08-20 09:44:41 UTC
Just for the record, I pushed the commit so people may give it a try once a daily build will be available with the patch.
Comment 30 Makrea 2021-08-20 10:50:59 UTC
Hi Julien Nabet.

I will try the fix on the daily build and give feedback here.

Thanks!
Comment 31 Julien Nabet 2021-08-20 10:56:12 UTC
(In reply to Makrea from comment #30)
> Hi Julien Nabet.
> 
> I will try the fix on the daily build and give feedback here.
> 
> Thanks!

I just pushed the patch, the one to thank is Michael Warner! :-)
Comment 32 Xisco Faulí 2021-08-20 15:41:10 UTC
(In reply to Julien Nabet from comment #29)
> Just for the record, I pushed the commit so people may give it a try once a
> daily build will be available with the patch.

Hi Julien,
I'm wondering, should it be backported to 7.2 branch ?
Comment 33 Julien Nabet 2021-08-20 16:11:28 UTC
(In reply to Xisco Faulí from comment #32)
> (In reply to Julien Nabet from comment #29)
> > Just for the record, I pushed the commit so people may give it a try once a
> > daily build will be available with the patch.
> 
> Hi Julien,
> I'm wondering, should it be backported to 7.2 branch ?
I think it could be useful indeed but perhaps we should wait a confirmation it works well from Makrea ?
Comment 34 Makrea 2021-08-20 21:37:00 UTC
(In reply to Julien Nabet from comment #33)
> (In reply to Xisco Faulí from comment #32)
> > (In reply to Julien Nabet from comment #29)
> > > Just for the record, I pushed the commit so people may give it a try once a
> > > daily build will be available with the patch.
> > 
> > Hi Julien,
> > I'm wondering, should it be backported to 7.2 branch ?
> I think it could be useful indeed but perhaps we should wait a confirmation
> it works well from Makrea ?

Hi,

Wait a confirmation from me and maybe kabilo as well (if he is available to validate his use cases obviously).

Nevertheless i will update here with the results I get.

PS:
A backport to the 7.2 branch would be welcome if you see that it does not collide with anything else.

Best regards.
Comment 35 Makrea 2021-08-22 20:41:34 UTC
Hi,

It's impossible to tell if its solved because i'm unable to test properly.

The alpha DEV version doesn't behave like a normal LibreOffice release executable.

I uninstalled, on purpose, the 6.3.5.2 version, then installed the 7.3.0.0 alpha DEV version.

The DEV version, as it seems by design, doesn't create registry entries to the documents. So eg this entry on registry doesn't exist LibreOffice.WriterDocument.1 after install at HKEY_CLASSES_ROOT.

I know I could have the two versions installed simultaneously but then I would be in doubt which LO version intervened on what occasion. What version created the OLE object by API, etc.
Also it does not represent the typical use case. Real world users on production environment don't have two LO installed.

I also know I could inject the missing registry information but I don't think that would be a proper test. 

Maybe there is a way to force a full and normal installation using a alpha DEV version.

I'll wait your advice.
If your advice is to inject the missing registry information then i will do that.

Best regards.
Comment 36 Julien Nabet 2021-08-22 21:36:14 UTC
If https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/ is the debug version, I must recognize I don't know, since the other Windows daily builds are 32 bits one and Arm one.
Comment 37 Makrea 2021-08-23 01:49:57 UTC
(In reply to Julien Nabet from comment #36)
> If
> https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/
> is the debug version, I must recognize I don't know, since the other Windows
> daily builds are 32 bits one and Arm one.


Hi Julien,

The version that I installed corresponds to the link on your comment.

I guess I will have to either:
1- Install 6.3.5.2 or 7.2.0.0 production version and then export the registry info. And then uninstall, reboot, install 7.3.0.0 DEV version and then import the previously exported registry info (changing paths where needed) and see if it works.
2- Wait for a version (i'm guessing a release candidate version) that after installation has all registry info properly in place.

I will keep you updated about option number 1.

Best regards
Comment 38 Buovjaga 2021-08-23 06:53:57 UTC
(In reply to Julien Nabet from comment #36)
> If
> https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/
> is the debug version, I must recognize I don't know, since the other Windows
> daily builds are 32 bits one and Arm one.

No, that is not a debug build. TB39 is.

(In reply to Makrea from comment #37)
> 2- Wait for a version (i'm guessing a release candidate version) that after
> installation has all registry info properly in place.

Then you would have to wait for 6 months.
Comment 39 kabilo 2021-08-23 08:11:32 UTC
I tested the daily buid 7.3 and I have the same experience as Makrea. 
Would it be possible to backport to 7.2 and test it in 7.2.1?
Comment 40 Makrea 2021-08-23 14:49:01 UTC
(In reply to kabilo from comment #39)
> I tested the daily buid 7.3 and I have the same experience as Makrea. 
> Would it be possible to backport to 7.2 and test it in 7.2.1?

The backport to 7.2 looks like the best way to go at this point.


I will still be doing the test by injecting the missing registry information and let you know the results.
But that's not the most desired test environment.

Best regards.
Comment 41 Julien Nabet 2021-08-23 16:42:55 UTC
The backport on 7.2 is now waiting for review here:
https://gerrit.libreoffice.org/c/core/+/120877
Comment 42 Makrea 2021-08-23 19:09:19 UTC
(In reply to Julien Nabet from comment #41)
> The backport on 7.2 is now waiting for review here:
> https://gerrit.libreoffice.org/c/core/+/120877


Thanks Julien! :-)
Comment 43 Commit Notification 2021-08-25 13:58:23 UTC
Michael Warner committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/1e3f7a0370b13ba0da69385103f6419d55ff487b

tdf#141097 Revert "Veto process exit while an OLE client is connected"

It will be available in 7.2.1.

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 44 Makrea 2021-08-27 23:07:59 UTC
(In reply to Makrea from comment #40)
> I will still be doing the test by injecting the missing registry information
> and let you know the results.
> But that's not the most desired test environment.
> 
> Best regards.

Hi!

I have good news! :)

The technique of injecting missing registry information yielded results.

The injection comprised above 6500 lines on HKEY_CLASSES_ROOT registry hive based on 6.3.5.2 registry information (extracted from a clean virtual machine).

After injection, just by doing this, on a machine with LibreOfficeDev_7.3.0.0.alpha0_Win_x64.msi version installed I verified that becomes possible to create via API the most important LibreOffice related OLE objects directly related to the invocation of "com.sun.star.ServiceManager" and "com.sun.star.frame.Desktop". 
(This injection part would not be needed to be done on a release candidate version.)

So after this the generation of the ODT document based on a OTT template occurs, the bookmarks are detected, information is then inserted on those bookmarks (nothing new at this point :) ) and then I typed some text on the generated document and tried to close the LibreOffice GUI on the X button and it closed!

I'm fairly confident at this point that Michael Warner commit solves the issue that was reported.

I would like to thank your work regarding this issue and kabilo for his duplicate findings.

Any further information or tests that you need feel free to ask.

PS:
I'm not sure if DEV versions install to a "DEV" path.
If so be aware that for this test I explicitly changed on installation the suggested "DEV" path to it's production version path that would normally be this one: C:\Program Files\LibreOffice\
I've done this to be sure to match the extracted 6.3.5.2 version registry paths.

Best regards!
Comment 45 Michael Warner 2021-08-28 19:01:49 UTC
(In reply to Makrea from comment #44)
> I'm fairly confident at this point that Michael Warner commit solves the
> issue that was reported.

Happy to help! :-)

Given this confirmation, I will mark as Resolved Fixed.

> 
> I would like to thank your work regarding this issue and kabilo for his
> duplicate findings.


I would also like to thank Julien and everyone else involved in driving this to closure.
Comment 46 kabilo 2021-12-08 16:01:47 UTC
*** Bug 139023 has been marked as a duplicate of this bug. ***