Commit 839cf255e2 used dispatch_sync()
but, unfortunately, libdispatch will not create a new thread for the
queue. dispatch_async_and_wait() also doesn't necessary run the queue
in a separate thread so use dispatch_async() and block and wait for
the libdispatch task to complete.
Change-Id: I8babad30caa8a188483ddf4f62bae35f5b888dc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163122
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Reusing the same instance will, in the following case, lead to a
crash. It appears that the CertificateChooser is getting disposed
somewhere as mpDialogImpl in its base class ends up being null:
1. Create an empty Writer document and add a digital signature
in the Digital Signatures dialog
2. File > Save As the document, check the "Encrypt with GPG key"
checkbox, press Encrypt, and crash in Dialog::ImplStartExecute()
Change-Id: I9aaa1bd449622e018b502d68c53d397255a1b61a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163065
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
This is another attempt to stop the crashing in libdispatch by
running fork() and exec() within a libdispatch task that will
run in a sequential queue in a non-main thread.
Change-Id: I3249510c14cc32f7f769b59289fe8380dd22ab68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163036
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Most, if not all, of the Linux certificate manager applications are
not available on macOS so create a separate list for macOS.
Also, fix uncloseable windows due to uncaught exceptions thrown by
XSystemShellExecute::execute(). Failure to catch such exceptions
would cause the document window to be uncloseable and the application
to be unquittable.
Change-Id: I9bc6dc9c6c9d054252b634874045cb066023214a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162887
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
This attempts to fix a particularly difficult to debug crash due to
memory corruption when gpgme tries to fork and exec a gpg command.
For more background, see the following bug comment:
https://bugs.documentfoundation.org/show_bug.cgi?id=152524#c39
This data section is only added in Mac Intel builds as it is a
controversial approach and I have not seen any reports of this bug
on Mac Silicon yet. So limit the fix only to Mac Intel in the hope
that this controversial approach will automatically phase itself
out when Apple eventually stops releasing new versions of macOS
for Mac Intel.
Note: the Objective C runtime doesn't appear to check the value of
this data section, but set it to 1 in case that changes in the future.
Change-Id: Ifac7893589a9183e092724297aff93eb3d58ab70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162634
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
* Update helpcontent2 from branch 'master'
to 5d2a29ee4f4556b0133e73ea429c9c1aaede0581
- tdf#159307 macOS uses Command+Option+F while other plafforms use Ctrl+H
Change-Id: Iee37805afba1aa712a45c213d1f9eeae4d01d923
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/162452
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
When exporting a document via this path, such as exporting to PDF
via the .uno:ExportToPDF command, any exceptions thrown while saving
the current document will leave the app in a blocked state if a
"PENDING" message has been sent.
The iOS app (and maybe the Android app) fails to set the URL to
save to so we need to set it to a temporary file.
Note: the iOS app is responsible for deleting the temporary file.
Also, enable building iOS with TLS=OPENSSL by default.
Signed-off-by: Patrick Luby <plubius@libreoffice.org>
Change-Id: Ibc070bed4e792bb0a481d2b900d12d214e3c519f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161692
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162125
Tested-by: Jenkins
I don't know why m_nEndNode is larger than the size of the node
array, but adjusting m_nEndNode to the last element in the node
array stops the crashing.
Change-Id: I425589457c6729b6689a7046f063154a2496e811
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162035
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
rather than waiting for `m_xDrawingArea` to get disposed, to prevent
unsafe use of the now potentially non-functional accessible until it
gets disposed with the VclDrawingArea
Change-Id: I5b8720ac4d5ed41cb1775b0142b17d198e9f036d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161903
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
The shortcut assumes that lost ownership notifications from the
system clipboard will happen elsewhere. They do under normal
conditions, but do not when some clipboard managers are running.
So, explicitly check ownership to catch such cases.
Change-Id: If54ca8c9908650c23c348e08231820ee7c2483e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161337
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
Problem: at least on macOS, swipe events are very
precise. So, when swiping at a slight angle off of
vertical, swipe events will include a small amount
of horizontal movement. Since horizontal swipe units
are measured in cell widths, these small amounts of
horizontal movement results in shifting many columns
to the right or left while swiping almost vertically.
So my hacky fix is to reduce the amount of horizontal
swipe events to roughly match the "visual distance"
of vertical swipe events.
The reduction factor is arbitrary but is set to
roughly the ratio of default cell width divided by
default cell height. This hacky fix isn't a perfect
fix, but hopefully it reduces the amount of
unexpected horizontal shifting while swiping
vertically to a tolerable amount for most users.
Note: the potential downside of doing this is that
some users might find horizontal swiping to be
slower than they are used to. If that becomes an
issue for enough users, the reduction factor may
need to be lowered to find a good balance point.
Lastly, fix the unbalanced rounding of delta X and Y
values due to using floor() for macOS native swipe
and scroll wheel events.
Change-Id: I8c0c9a3aa688e411c47ebb5e7500f3a50f6f673b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161278
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
When copying text from a Writer document and the
FLAVOR_LINK flavor is pasted, Writer will edit the
copied text in order to create a bookmark for DDE.
The problem is that many macOS clipboard managers
fetch *all* available flavors that are available in
the macOS general pasteboard instead of just one
flavor and this triggers the FLAVOR_LINK flavor's
unusual editing behavor in Writer every time the
user copies Writer text.
Users have reported in tdf#1515679 that on macOS,
Microsoft Writer, Excel, and PowerPoint do not
recognize this flavor like is done on Windows so,
in theory, we can just filter out this flavor when
adding flavors to the macOS general pasteboard.
With this change, the FLAVOR_LINK flavor will still
be visible when copying and pasting within a single
LibreOffice instance as well as when dragging from
LibreOffice to other applications.
Change-Id: Ia391398286fa8795ac65b4702a15caf59fb3ae70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161305
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
If the following .ppt document is opened in a debug build
and the document is left open for a minute or two without
changing any content, this destructor will be called on a
non-main thread with the mutex unlocked:
https://bugs.documentfoundation.org/attachment.cgi?id=46801
This hits an assert in VirtualDevice::ReleaseGraphics() so
explicitly lock the mutex and explicitly dispose and clear
the VirtualDevice instances variables.
Change-Id: I5d371a4e99fca4aae2b6edc8b53eca10cb143aef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161243
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
By default, the layout idle timer in the InterimWindowItem
class is set to TaskPriority::RESIZE. That is too high of
a priority as it appears that other timers are drawing
after the scrollbar has been redrawn.
As a result, when swiping, the content moves fluidly but
the scrollbar thumb does not move until after swiping
stops or pauses. Then, after a short lag, the scrollbar
thumb finally "jumps" to the expected position.
So, to fix this scrollbar "stickiness" when swiping,
setting the priority to TaskPriority::POST_PAINT causes
the scrollbar to be redrawn after any competing timers.
Change-Id: I8c0772fc40ddc690ee59c6267c1c50971f4ff238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161184
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
After fixing several flushing issues in tdf#155266, scrollbars
still will not redraw until swiping has ended or paused when
using Skia/Raster or Skia disabled. So, stop the delay by only
including NSEventMaskScrollWheel if the current event type is
not NSEventTypeScrollWheel.
Change-Id: I9348e5a38b4d0fedbf424b92a71eed25280fc21f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161075
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
When running on macOS with a Retina display, several BackendTest unit tests
also need a lower quality scaling level.
Change-Id: Ied7141af886357a846f5c4633703114c18dfabf9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160811
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Calling aBitmap.HasGreyPalette8Bit() hits an assert when
using Skia in a debug build so query the palette through
the bitmap read access object.
Change-Id: I12fad6783ec7d6df6c99db197aaa52fd4b01ed69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160684
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
When using Skia/Metal, the window content will flicker while
live resizing a window if we don't send a paint event.
Change-Id: Ib3edc497e26e6abfdfd17a34f9269a3eae090805
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160519
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
When scrolling on some Intel Macs either via dragging
the scrollbar thumb or via swiping the trackpad with two
fingers, final repaint of scrollbars doesn't appear to
get flushed to the screen. It appears that scrollbars
aren't updated and repainted until after a batch of
native scroll events have been dispatched. On slower
machines, this lag is long enough that any pending
forced flushes have already been done so when the timer
that repaints scrollbars finally fires, the repainted
scrollbars won't get flushed to the native window until
the next normal flush which may not occur until seconds
later.
Change-Id: Iadef6812cd2495a28347560caae81f604c908b51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160440
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
It appears that calling -[NSView display] overwhelms some Intel Macs
so only flush the graphics and skip immediate redisplay of the view.
Change-Id: I7a94a1ada35526c5eda1b793f872e206b4c833ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160399
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
When in live resize, the NSView's height may have changed before
the CGLayer has been resized. This causes the CGLayer's content
to be drawn just above or below the top left corner of the view
so translate the Y coordinate by any difference between the
NSView's height and the CGLayer's height.
Change-Id: Iac13fa8374977e098f8311c55e182ef5a5ebec30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160131
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
Round 2 of trying to fix macOS live resizing.
If this is a left mouse up event, dispatching this event
will trigger tdf#155092 to occur in the next mouse down
event. So do not dispatch this event and push it back onto
the front of the event queue so no more events will be
dispatched until live resizing ends. Surprisingly, live
resizing appears to end in the next mouse down event.
Also, reverted parts of commit 54da842381
and cleaned up the setting of ImplGetSVData()->mpWinData->mbIsLiveResize.
Change-Id: Ie93ed496e1f0e2a1711284ab205c6b245f71647c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159960
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
Apparently, the older, tracking rectangles selectors cause
unexpected window resizing upon the first mouse down after the
window has been manually resized so switch to the newer,
tracking areas selectors. Also, the NSTrackingInVisibleRect
option allows us to create one single tracking area that
resizes itself automatically over the lifetime of the view.
Note: for some unknown reason, both NSTrackingMouseMoved and
NSTrackingAssumeInside are necessary options for this fix
to work.
Change-Id: I1f771628d872166ff63a52990f671df053d144ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159845
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@neooffice.org>
Before commit 81994cb2b8,
RemoveBlendedStartColor(COL_BLACK, aAlpha) would darken
the bitmap when running a slideshow, printing, or exporting
to PDF. To get the same effect, the alpha mask must be
inverted, RemoveBlendedStartColor(COL_WHITE, aAlpha)
called, and the alpha mask uninverted.
Change-Id: I8e81b11aab05954c821f833f4a2fc77eec7b7701
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159742
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Patrick Luby