This patch makes an icon display in image entries with broken links to
make it easier to find images with broken links.
Change-Id: I470c9959e169d4cc53a44e0a64e88af35e671db0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161045
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
This change just adds the flag "SfxChildWindowFlags::NEVERHIDE"
to the info passed around so that the dialogs are not treated as
invisible when executing SfxWorkWindow::ShowChildren_Impl.
Change-Id: I35f0be94132cee438b3be9f4b4217208617a1e77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160660
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
which naturally requires the data to achieve
Change-Id: If23e7dbd009f3d8e60422ec4d485b459d5721c8f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161135
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
There are some CrashReports in 7.6 which have
DeleteItemOnIdle on the stack, but there is nothing
reproducable. So I took a look...
I first thought it's a MCGR regression, due to classes
on the stack. But the Item involved is just random, can
happen with any Item.
Then I thought it may have to do with ITEM refactorings,
but it happens with DeleteItemOnIdle involved, so also
not the case. I already saw DeleteItemOnIdle when doing
these and qualified as 'hack' in the way. already
It is only on Windows and DeleteItemOnIdle is involved.
This again (took a deeper look now) is an old hack to
keep an SfxPoolItem 'alive' for some 'time'. For that,
it triggers an async reschedule which then deletes the
Item when being called. If the Item will be used after
that is pure coincidence - seems to work in most cases.
It seems as if for Windows the timing slightly changed
for some scenarios, so a reschedule is too early. This
can happen with this hack anytime.
DeleteItemOnIdle is used in scenarios where SfxPoolItem*
is e.g. returned, but is *not* anchored, so e.g. not
member of an SfxItemSet. Or in short: Lifetime is not
safe.
DeleteItemOnIdle exists since 1st import, but was
changed to AsyncEvent ca. 4 months ago (see
57145acf9e), so that may
have caused it. It is possible that these errors happen
on Windows since then. Before something more complicated
was used to delete it late, but surely also not really
safe.
Due to ITEM refactor I have the knowledge/tooling to
solve this. It will not be a 1-5 lines fix, but it is
a hack and in the way for further ITEM refactor anyways.
What we have nowadays is a SfxPoolItemHolder -> it's
like an SfxItemSet for a single Item. It safely holds/
controls the lifetime of an SfxPoolItem. It is already
used in quite some places. It helps to solve many hacks,
also the ones putting Items directly to the Pool - due
to there never was an alternative for that. In principle
the ItemPool/ItemSet/Item paradigm was never complete
without SfxPoolItemHolder.
Thus I started to fix that (and remove that hack for
good, sooo many changes over the years, sigh), but as
said is not straightforward. Will have to change
retvals of involved stuff to SfxPoolItemHolder - it's
just two pointers and designed to be copied (one is a
Pool, needed to cleanup when destructing).
CopyConstruct/destroy just counts the RefCnt up/down,
so cheap.
1st version compiling, let's check on gerrit...
Corrected one error in QueryState for securitypage, also
added some security features/asserts.
Change-Id: Ida49fd35ca88ead84b11d93e18b978cb9e395090
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161083
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This reverts commit be86c8f243.
Reason for revert: To many regressions.
Change-Id: Id3fb8dc5d4edb84c0008b7834a80887aaa7d9f83
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161154
Tested-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
This reverts commit 4f1b3c16f5.
Reason for revert: To many regressions.
Change-Id: I7352bb3c192d5e6c72e95c387ee551764007e97b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161152
Tested-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
As sberg mentioned in previous change this might be responsible
for heap-use-after-free problems. I took a look and it seems
to be possible that the timer calls back while deletion of the
helper is in progress, so I try now to first stop the timer
and then delete so that it cannot trigger. Will see if that
works - if not I might have to use another lock...
Change-Id: I1ae27d9ed890f352904cab18c3292b449659a3ce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161128
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
* Update helpcontent2 from branch 'master'
to 05f08bd00aadd36088254d7fe062507fea113de8
- tdf#156156: add Manage Changes sidebar decks help button's HID
and document how to get to it from the sidebar and the tabbed UI.
Change-Id: Ibeab9e20ea4f8684b8d0a8a535b30c3122e4df70
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/161101
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
seen with Red Hat Developer Toolset 10
https: //github.com/CollaboraOnline/online/issues/6893#issuecomment-1866342284
Change-Id: I4a0e8ad028126dded678e971a6261d6725a6b06c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161129
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
...which needs to call update_service.exe with "install" (resp. "uninstall") and
needs to create (resp. delete) a registry entry containing the issuer and name
of the certificate with which the updater.exe is signed (which is required by
one of the many sanity and security checks performed by update_service.exe
before it will actually do an automatic update). (The issuer and name of the
certificate are for now hardcoded to the values used by TDF when signing its
Windows builds.)
(gid_Customaction_uninstall_updateservice needs to run rather early, when
update_service.exe has not yet been removed, so I rather randomly picked
"MigrateFeatureStates" as the point where to run it.)
Change-Id: I6e0f62ec3e51d74d4a526a490badc7c14ebe99ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161125
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...at least for debug purposes?
Change-Id: I02fc410109353ca3d421a6b8e0e1848df05cf479
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161126
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Insert a chart, user #1 select it, user #2 select it. User #1 double click
it, double click again the legend to get dialog to edit it. User #2 delete
chart, User #1 'ok'
#0 0x00007f5365797d59 in osl::Mutex::acquire (this=<optimized out>) at include/osl/mutex.hxx:63
#1 osl::ClearableGuard<osl::Mutex>::ClearableGuard (t=..., this=0x7ffc7ffcccf0) at include/osl/mutex.hxx:182
#2 apphelper::LifeTimeGuard::LifeTimeGuard (rManager=..., this=0x7ffc7ffcccf0) at chart2/source/inc/LifeTime.hxx:175
#3 chart::ChartModel::lockControllers (this=0x0) at chart2/source/model/main/ChartModel.cxx:415
#4 0x00007f53658375ab in chart::ControllerLockGuardUNO::ControllerLockGuardUNO (this=this@entry=0x7ffc7ffcce80, xModel=...)
at chart2/source/tools/ControllerLockGuard.cxx:34
#5 0x00007f5364df5f34 in chart::ChartController::executeDlg_ObjectProperties_withoutUndoGuard (this=<optimized out>, rObjectCID=..., bSuccessOnUnchanged=<optimized out>)
at chart2/source/controller/main/ChartController_Properties.cxx:797
#6 0x00007f5364df7a5e in chart::ChartController::executeDlg_ObjectProperties (this=0x7f535401f310, rSelectedObjectCID=...)
at chart2/source/controller/main/ChartController_Properties.cxx:707
#7 0x00007f5364e0f497 in chart::ChartController::execute_MouseButtonUp (this=<optimized out>, rMEvt=...) at chart2/source/controller/main/ChartController_Window.cxx:924
#8 0x00007f53760d61dc in (anonymous namespace)::LOKPostAsyncEvent (pEv=0x55e2f1b93db0) at sfx2/source/view/lokhelper.cxx:893
#9 0x00007f53760d0977 in LokChartHelper::postMouseEvent (this=<optimized out>, nType=1, nX=<optimized out>, nY=<optimized out>, nCount=2, nButtons=1, nModifier=0, fScaleX=0.083333333333333329,
fScaleY=0.083333333333333329) at sfx2/source/view/lokcharthelper.cxx:294
just hold a reference to the chart the dialog operates on
Change-Id: I3b05d1fc12e4df899c1a996f1029f9d3d62e87ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161099
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
* Update translations from branch 'master'
to 4eb96d17e8d53f48a7709ae657534cc451c7e4c8
- update translations for master/24.2.0 RC1
and force-fix errors using pocheck
Change-Id: I3a90b2320a21d218eeef7bdb8168b4e634304f78
- Updated Slovenian translation
Change-Id: I4abd1636021dabc93c91f1c51d3f8b0aadbb320b
... at the end of text"
This reverts lpranam's 7.2.0 regressive
commit 3233db0913.
The character after a hyperlink should not offer
to CTRL-click or jump to the hyperlink target.
make CppunitTest_sw_uiwriter9 CPPUNIT_TEST_NAME=testTdf158785
Change-Id: I3f5398cc3a4f29ddf1c50764c311046713d39439
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161042
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
User can specify which sheets to export e.g. '2-5,7'
exports sheets 2,3,4,5,7.
Note: this is different from exporting pages as one
sheet may contain several pages worth of content.
Also fix a bug where exporting only a selected sheet
causes the next sheet to be exported. e.g.:
Sheet 1 is empty, Sheet 2 has content. Exporting Sheet 1
results in Sheet 2's content being exported
Signed-off-by: NickWingate <nick.wingate@collabora.com>
Change-Id: Iecd42188ddbbbcd70eb37bec80783e29e3cb5b19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156255
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159686
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
When DisableActiveContent is set, provide now non-functional areas
meaningful error messages / popup dialogs.
Change-Id: I34bffee10fb0ba5c0194193f3d3d81b93d7dbd26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160923
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
In the LOK case for example, where there is no reportbuilder, there
were a lot of bogus warning messages at startup, confimgr complained
that there were translations for non existing configuration nodes,
all belonged to reportbuilder.
Change-Id: I7f9cef3206bddd9e333b97ee966fb950fbb352d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160887
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161048
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Update hex colors 0x000000, 0xFFFFFF, and 0xFF0000 with COL_BLACK, COL_WHITE,
and COL_LIGHTRED, respectively. See comment #30 for more details.
Change-Id: I82ff851d8c19f9ef4aeeb01bff313160da615222
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160452
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@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>
If you try hard enough, it's possible to request an "add conditional
format" dialog in one view and have the dialog pop up in an other view.
This is related to cool#7853 but it focuses on the wider problem.
What happens is that sometimes we do want to execute an uno command in
an async way, e.g. one dialog opening an other dialog in its response
handler: making sure the dialog is not manually / synchronously spinning
the main loop while it's running is wanted. Also fixing each & every
async command dispatch manually would be a lot of work.
Fix the problem by remembering the current view in SfxHintPoster::Post()
as it posts events to the main loop and restoring that view if necessary
in SfxHintPoster::DoEvent_Impl().
Other comments:
- An alternative would be to just dispatch all these UNO commands
synchronously, but see above, there are cases where we want to stay
async, a nested main loop would be worse.
- An even more general fix would be to handle all calls to
Application::PostUserEvent(), but vcl doesn't know what is the
current view and would have trouble switching to that view (only sfx2
and higher up knows that), so do this only at a SfxHintPoster::Post()
level, this is already meant to fix all async uno commands.
- There was a single case in sd/ where we tried to dispatch an async
event while switching views, so switch to a sync command dispatch
there to avoid the problem. CppunitTest_sd_tiledrendering would hang
without this and would emit a warning in SfxHintPoster::Post().
- Restore the sc/ code to do its async dispatch as it used to, so now
CppunitTest_sc_tiledrendering's testOpenURL is a test case that covers
this change.
Change-Id: I765e618f55caad791aa1fe7569a32bcc31622525
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161071
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The Gtk API has no direct equivalent for the selectable
and expandable states, but sets them on the AT-SPI layer
whenever a value for the selected/expanded states is
explicitly set.
Therefore, only explicitly set values for these
if the selectable/expandable state is present,
to avoid the expandable/selectable state being
set on AT-SPI layer when it shouldn't.
Change-Id: Ib0cf2095d4834869856bf786e662115f6a328e13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161046
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
While importing the properties NumberingRules and NumberingStyleName
interfere with each other. Avoid overwriting NumberingRules with an
invalid NumberingStyleName.
Regression from 588ff9a228
Change-Id: I706ea514da43faae0fdb9a2c0d4f5b1928ef55f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160967
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
the fake keystroke is to make tooltips go away before menus which
used to be a problem versions of gtk3 < 3.24 that resultsed in no
menus appearing. Our min is still 3.18 so technically we need to retain
that until bumping past that as baseline.
Change-Id: I94aa309665c50c8ca310285d1e691030f443934a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161080
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Until tdf#76007 is fixed, of course.
Change-Id: Iad7fb0de679e024a8cebdd005ac5a66af3ace163
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161078
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
It would fail to negate SAL_MIN_INT32.
Change-Id: Ia5d34fc31917cabee2a1b130ef69c91b202592fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161063
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When DisableActiveContent is set, embedded active content is
disabled (e.g. OLE). Therefore the existing ui insertion bits don't
function either. Disable them with a warning pop-up hinting "Active
content is disabled."
Change-Id: I14984684f22df6aff81af79d5a15589b5cae75fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161055
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
there was the possibility of constructing an OOoEmbeddedObjectFactory
or OleEmbeddedObjectFactory directly instead of
UNOEmbeddedObjectCreator.
So disable all createInstance calls for them too. Securing there won't
be active embedded objects.
Change-Id: Ib47ad920d4951790c12d1a8587505cab2f1e126d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160921
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
