- 31 May, 2019 7 kayıt (commit)
-
-
Katarina Behrens yazdı
This just stops the bleeding (crash) in a special case when screen number argument of SalFrame::ShowFullScreen is -1 (meaning 'fullscreen spanning all available displays') It doesn't yet extend the fullscreen window over all screens, this will be done in a follow-up fix Change-Id: I2cf48096a1fe1ec33c943f10acb41c59585b325f Reviewed-on: https://gerrit.libreoffice.org/71965 Tested-by: Jenkins Reviewed-by:
Katarina Behrens <Katarina.Behrens@cib.de> (cherry picked from commit 758c44f6) Reviewed-on: https://gerrit.libreoffice.org/73256Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
Michael Stahl yazdı
Followup to 58f121ef; OConnection must not be held by rtl::Reference as that creates a cycle. (regression from 497e40ad) Change-Id: Ibd56d335e3e2631c5a57ea435f1035e89868a5a6 Reviewed-on: https://gerrit.libreoffice.org/73155 Tested-by: Jenkins Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> (cherry picked from commit 6bd751f9) Reviewed-on: https://gerrit.libreoffice.org/73243Reviewed-by:
-
Michael Stahl yazdı
Followup to 96ae2a33; more overridden acquire() creating cycles in dbaccess. (regression from 2660d24a) Reviewed-on: https://gerrit.libreoffice.org/73158Reviewed-by:
Noel Grandin <noel.grandin@collabora.co.uk>
-
Grzegorz Araminowicz yazdı
Solved by adding additional shape filling whole diagram. MS PowerPoint does the same when converting SmartArt to shapes. Background shape is also copied when loading from drawingML fallback, appearently there is no background information. Corrected SmartArt import tests, so that they are aware of extra shape. Change-Id: I6154f8e1b34e5867ab582d6fc54459c7c93edbac Reviewed-on: https://gerrit.libreoffice.org/72012 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/73250
-
Michael Weghorn yazdı
kde5 plugin on Wayland still shows too many issues, like e.g. tdf#123654 and was barely tested, so don't use it by default in libreoffice-6-2 branch, but prefer gtk3. This does not affect the X11 case. This reverts commit 3e447810. Change-Id: I7f74a6b5f377f65b81cf5ae189e8672bdce82c95 Reviewed-on: https://gerrit.libreoffice.org/73193 Tested-by: Jenkins Reviewed-by:
Jan-Marek Glogowski <glogow@fbihome.de> Reviewed-by:
Michael Weghorn <m.weghorn@posteo.de>
-
Tamás Zolnai yazdı
Revert of: 2903c5f5 Reverting this commit does not lead to the original bug to come back, so we can revert it without a problem. Change-Id: I244a6b9451c47e1094db8a77c71b6696e0c464cc Reviewed-on: https://gerrit.libreoffice.org/73139Reviewed-by:
Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by:
Andras Timar <andras.timar@collabora.com>
-
Tamás Zolnai yazdı
Revert the commit caused this regression: 0fc41c53 The original issue does not come back with reverting this commit. Reviewed-on: https://gerrit.libreoffice.org/72679 Tested-by: Jenkins Reviewed-by:
Xisco Faulí <xiscofauli@libreoffice.org> Tested-by:
-
- 30 May, 2019 3 kayıt (commit)
-
-
Mark Hung yazdı
Have video fit to the media object size on the slide, allow more complicated interactions. --- This also backports the relevant part from commit bbe1ede0 ("tdf#124027: use ID of the embedded window and fix position of overlay") namely to make translation gtk3-specific, to fix a regression, as mentioned in its commmit message: > 2) the position of the embedded window for video overlay has already > been translated relative to the top-left corner of the slide (see > bugfix of tdf#42873 how) in gen, gtk and kde5 vclplugs. So let's limit > translating it 2nd time only to gtk3 vclplug which for some reason > behaves differently > (regression from 18138417) Reviewed-on: https://gerrit.libreoffice.org/67978 Tested-by: Jenkins Reviewed-by:
Caolán McNamara <caolanm@redhat.com> Tested-by:
Mark Hung <marklh9@gmail.com>
-
Julien Nabet yazdı
See https://bugs.documentfoundation.org/show_bug.cgi?id=56738#c3 Change-Id: I8dbab3fe76b2c2d83cbb07509fabe9f784664c03 Reviewed-on: https://gerrit.libreoffice.org/73088 (cherry picked from commit fd01ddd3) Reviewed-on: https://gerrit.libreoffice.org/73157 Tested-by: Jenkins Reviewed-by:
-
Jan-Marek Glogowski yazdı
You can't tab into the menu bar, but if you add a corner widget, it will be enlisted in the parent's focus chain! Interestingly the menu bar even is considered to have the focus, if the widget is focused, and will handle key events, but this can probably be considered consistent. So this just denies the button any focus, as this is a mouse-only widget, and clicking it will close the document window. Change-Id: I3c48d85ca56b6a54daf01f444dddc736e7ebb8e7 Reviewed-on: https://gerrit.libreoffice.org/73186 Tested-by: Jenkins Reviewed-by:
-
- 29 May, 2019 4 kayıt (commit)
-
-
Xisco Fauli yazdı
Same problem as in 96ae2a33 Regression from 497e40ad Change-Id: I00e7bf3559e688e7fbc5429ace2b5c18221c9890 Reviewed-on: https://gerrit.libreoffice.org/73146Reviewed-by:
-
Miklos Vajna yazdı
This is similar to e8d5b8be (tdf#113714 vcl menu bar window: avoid flicker, 2019-05-20), except that was for the menu bar window, and this is for the floating window opening from that one. (cherry picked from commit c04169c5) Change-Id: Ib24f4999ad3e8cbbecc058368e9d112e106e9178 Reviewed-on: https://gerrit.libreoffice.org/72726 Tested-by: Jenkins Reviewed-by:
Tomaž Vajngerl <quikee@gmail.com>
-
Miklos Vajna yazdı
Windows (by default) and gtk3 paints its own background, but e.g. the Linux gen backend does not; so make sure that we not only copy from the buffer, but also initialize it. This restores the gradient background of the main menu with the Linux gen backend. (cherry picked from commit a2da909a) Change-Id: I5ce8cc734f64bc1d57d343caf22071e6aa63a69f Reviewed-on: https://gerrit.libreoffice.org/72685Tested-by:
-
Miklos Vajna yazdı
Regression from commit 458a827e (further refactor Menu to use RenderContext, 2015-05-15), if we do full paint instead of incremental paint, then need to ensure that an intermediate state is not painted. Paint happens at idle time by default on Windows (OpenGL) and also on Linux (gtk3), but some other backends like Windows GDI had flicker, this fixes the problem. (cherry picked from commit e8d5b8be) Change-Id: I530166cea93513aec4648dd0a385359f4b998b6f Reviewed-on: https://gerrit.libreoffice.org/72673 Tested-by: Jenkins Reviewed-by:
-
- 28 May, 2019 1 kayıt (commit)
-
-
Caolán McNamara yazdı
and if there is no videosink then give up Change-Id: I6b60e7be1e77dbf5c4c277ccf47a4d121f3cd6a5 Reviewed-on: https://gerrit.libreoffice.org/72871Reviewed-by:
-
- 27 May, 2019 2 kayıt (commit)
-
-
Cor Nouws yazdı
This reverts commit 2b0cb3cf. As per tdf#125371 there are changes in existing documents in cells that are re-calculated on file-open. IMO this needs to be fixed before this patch can be re-applied. As such there is no question on the changed settings in the Options. Change-Id: Ib748cc520d4d475097cd5fd7e5500456b34f0789 Reviewed-on: https://gerrit.libreoffice.org/72860 Tested-by: Jenkins Reviewed-by:
-
Caolán McNamara yazdı
like SfxHintId::ScAccCursorChanged does Change-Id: I75ab2da866a345d817e39536ac966d3edf24b90a Reviewed-on: https://gerrit.libreoffice.org/72980 Tested-by: Jenkins Reviewed-by:
-
- 24 May, 2019 6 kayıt (commit)
-
-
Jan-Marek Glogowski yazdı
The parameter value for '--accept' is no UNO-Url, but uses a similar syntax. This was wrongly changed in commit d78f29ab ("tdf#100836 "Starting the LibreOffice Software With Parameters" help update"). So this changes the parameter value back to {accept-string}, documents its syntax and adds some common examples. Includes commit a82eed1e ("Fix typo in help: 'urb' => 'urp") (cherry picked from commit a82eed1e) Reviewed-on: https://gerrit.libreoffice.org/72859Reviewed-by:
Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins (cherry picked from commit a4066c77) Change-Id: If8159b1d982c54e3dca6d27a1c400d2450ff2d1e Reviewed-on: https://gerrit.libreoffice.org/72882Reviewed-by:
-
DaeHyun Sung yazdı
Modified Line Break Rule (Korean: 금칙 처리, 漢字hanja: 禁飭處理) I modifed Forbidden Characters(Korean: 금칙 문자, 漢字hanja: 禁飭文字) on LibreOffice Korean locale data xml. Reference1: HWP Guide - 금칙문자(Forbidden Characters) http://help.hancom.com/hoffice/webhelp/9.0/ko_kr/hshow/tool/forbid.htm Reference2: OOXML ISO/IEC 29500–1:2016(E) Korean * Cannot start a line: !%),.:;?]}¢°'"′″℃〉》」』】〕！％），．：；？］｝￠ (Unicode character values: U+0021, U+0025, U+0029, U+002C, U+002E, U+003A, U+003B, U+003F, U+005D, U+007D, U+00A2, U+00B0, U+2019, U+201D, U+2032, U+2033, U+2103, U+3009, U+300B, U+300D, U+300F, U+3011, U+3015, U+FF01, U+FF05, U+FF09, U+FF0C, U+FF0E, U+FF1A, U+FF1B, U+FF1F, U+FF3D, U+FF5D and U+FFE0, respectively) * Cannot end a line: $([\{£¥'"〈《「『【〔＄（［｛￡￥￦ (Unicode character values: U+0024, U+0028, U+005B, U+005C, U+007B, U+00A3, U+00A5, U+2018, U+201C, U+3008, U+300A, U+300C, U+300E, U+3010, U+3014, U+FF04, U+FF08, U+FF3B, U+FF5B, U+FFE1, U+FFE5, and U+FFE6, respectively) Change-Id: I32077b241f930cc912d0c365fc46c1cd046c59a6 Reviewed-on: https://gerrit.libreoffice.org/72492 Tested-by: Jenkins Reviewed-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com>
-
László Németh yazdı
also with the paragraph mark, not leaving an empty paragraph at the original place of the moved text. Note: as desktop version of MSO does, but its online version leaves empty paragraphs interestingly. Change-Id: I03dda8997df3efbc82e936bd31a3813323e6b5ab Reviewed-on: https://gerrit.libreoffice.org/71382Reviewed-by:
László Németh <nemeth@numbertext.org> Tested-by:
-
Jan-Marek Glogowski yazdı
Actually really evaluate some of the formating provided by the QInputMethodEvent::TextFormat attribute and not blindly underline all of the text. This evaluates the same formating that the gtk3 backend evaluates from pango, so the result should be somehow on par. Couldn't find a way to test the red strike-out text. Don't know how often I typed hyoujunnsutairu to test this bug, which - according to Google - translates to "standard style". Reviewed-on: https://gerrit.libreoffice.org/71783 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
As discussed in ESC call of 2019-02-21, enable kde5 for the Jenkins CI builds to detect build issues *before* the changes get merged. Reviewed-on: https://gerrit.libreoffice.org/68165 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
The utility constructor using 'StockImage::Yes' was only introduced in master commit 0f104bf3 and is therefore not available in libreoffice-6-2 branch. Build was therefore broken by commit f10c1c64 ("tdf#123549 Qt5 implement Qt5Menu::ShowCloseButton"), which first went unnoticed since qt5/kde5 wasn't enabled for CI builds on branch libreoffice-6-2. (This will be changed by https://gerrit.libreoffice.org/#/c/72741/ .) Also, add a missing include that lead to kde5-enabled CI builds failing [1], which I couldn't reproduce locally ("shell/source/backends/kde5be/kde5backend.cxx:190:5: error: ‘unique_ptr’ is not a member of ‘std’"). And fix more issues showing up in [2] and follow-up builds of the change that enables kde5 on the 6.2 branch [3]. [1] https://ci.libreoffice.org/job/gerrit_62/1535/ [2] https://ci.libreoffice.org/job/gerrit_62/1540/ [3] https://gerrit.libreoffice.org/#/c/72741/ Change-Id: I6a39a99114d15808b790242c96d0204916a0cc40 Reviewed-on: https://gerrit.libreoffice.org/72779Reviewed-by:
-
- 23 May, 2019 9 kayıt (commit)
-
-
Caolán McNamara yazdı
see also tdf#40457, tdf#115032 Change-Id: I505c3dfaf8f0a23e525db015f52a881b22016d11 Reviewed-on: https://gerrit.libreoffice.org/72847Reviewed-by:
-
Katarina Behrens yazdı
after many trials and errors what LibO apparently expects here is the ID of QWindow parent of [embedded] system child window (the rest of the original commit bbe1ede0 is not relevant for LibO 6.2) Change-Id: Ie4c6d14a50959c0fdd04e745918d4889c9da45ec Reviewed-on: https://gerrit.libreoffice.org/72458 Tested-by: Jenkins Reviewed-by:
-
Christian Lohmaier yazdı
Change-Id: I363a02d7115ea54bb4aedb38071a249e145ee471 Reviewed-on: https://gerrit.libreoffice.org/72742 Tested-by: Jenkins Reviewed-by:
Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit ae03c889) Reviewed-on: https://gerrit.libreoffice.org/72829Reviewed-by:
-
Michael Stahl yazdı
The remaining problem is that with the previous commit, the layout stops at some point and everything is crammed into the next-to-last page, with the following symptom: warn:legacy.osl:7667:7667:sw/source/core/layout/tabfrm.cxx:2642: debug assertion: <SwTabFrame::MakeAll()> - format of table lowers suppressed by fix i44910 This is apparently because of some very funny recursion that goes in circles until it formats some part of the "outer" table again. 0 SwTabFrame::MakeAll(OutputDevice*) (this=0x82b0280) at tabfrm.cxx:2642 ^ mpUpper -> 928 - top-level SwTabFrame and m_pFollow of 905 1 SwFrame::PrepareMake(OutputDevice*) (this=0x82b0280) at calcmove.cxx:372 2 SwFrame::Calc(OutputDevice*) const (this=0x82b0280) at trvlfrm.cxx:1790 3 SwFrame::PrepareMake(OutputDevice*) (this=0x6c06ba0) at calcmove.cxx:247 4 SwFrame::Calc(OutputDevice*) const (this=0x6c06ba0) at trvlfrm.cxx:1790 5 SwFrame::PrepareMake(OutputDevice*) (this=0x82aebf0) at calcmove.cxx:247 6 SwFrame::Calc(OutputDevice*) const (this=0x82aebf0) at trvlfrm.cxx:1790 7 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:247 8 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790 ^ m_pFollow->mpNext -> 332 - again! it's now m_pFollow->mpNext 9 SwTabFrame::MakeAll(OutputDevice*) (this=0x6d64570) at tabfrm.cxx:2544 ^ 303 - nested SwTabFrame, used to precede 332 but has now split and its m_pFollow precedes 332 10 SwFrame::PrepareMake(OutputDevice*) (this=0x6d674e0) at calcmove.cxx:313 11 SwFrame::Calc(OutputDevice*) const (this=0x6d674e0) at trvlfrm.cxx:1790 ^ 332 - SwTextFrame originally inside 991, but moved under top-level SwTabFrame 928 at this point 12 SwContentFrame::CalcLowers(SwLayoutFrame*, SwLayoutFrame const*, long, bool) (pLay=0x6dccbf0, pDontLeave=0x6ed6e30, nBottom=9223372036854775807, bSkipRowSpanCells=true) at tabfrm.cxx:1479 ^ m_pLower -> 991 - SwRowFrame 13 lcl_RecalcRow(SwRowFrame*, long) (pRow=0x6dccbf0, nBottom=9223372036854775807) at tabfrm.cxx:1614 14 lcl_RecalcTable(SwTabFrame&, SwLayoutFrame*, SwLayNotify&) (rTab=..., pFirstRow=0x6dccbf0, rNotify=...) at tabfrm.cxx:1691 15 SwTabFrame::MakeAll(OutputDevice*) (this=0x6ed6e30) at tabfrm.cxx:2082 ^ m_pFollow -> 905 - top-level SwTabFrame 16 SwTabFrame::MakeAll(OutputDevice*) (this=0x381d3e0) at tabfrm.cxx:2504 17 SwFrame::PrepareMake(OutputDevice*) (this=0x381d3e0) at calcmove.cxx:372 18 SwFrame::Calc(OutputDevice*) const (this=0x381d3e0) at trvlfrm.cxx:1790 ^ 866 - top-level SwTabFrame 19 SwLayAction::FormatLayoutTab(SwTabFrame*, bool) (this=0x7fff95aa3f20, pTab=0x381d3e0, bAddRect=true) at layact.cxx:1483 20 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6cfedc0, bAddRect=true) at layact.cxx:1375 21 SwLayAction::FormatLayout(OutputDevice*, SwLayoutFrame*, bool) (this=0x7fff95aa3f20, pLay=0x6e23fd0, bAddRect=true) at layact.cxx:1380 The first attempt was to add a TextFrameLockGuard around the pFrame->MakeAll() call in PrepareMake(), with corresponding test in SwTabFrame::MakeAll() ... but a similar problem still occurred, just now on page 18 instead of page 12. Another idea is to prevent PrepareMake() from formatting the SwTableFrame's follow *again*; it was already formatted by SwTabFrame::MakeAll() anyway, just before it calls pNxt->Calc(). With this, we get 23 pages for the bugdoc, same as before that commit: (regression from 18765b9f) Change-Id: I71e3f92b5f19b800626a008527fa75d08641e8de Reviewed-on: https://gerrit.libreoffice.org/72799Reviewed-by:
-
Caolán McNamara yazdı
Change-Id: I8d5bb318674311b1e21c6fdf487d69609af344a5 Reviewed-on: https://gerrit.libreoffice.org/72725 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
This is some copypasta, apply the same fix. Change-Id: I096594f6d54fef68e63c982c2963499d24af6d15 Reviewed-on: https://gerrit.libreoffice.org/72798 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
The problem is that with the change in SwFlowFrame::MoveBwd(), a SwTextFrame in a table may move backwards during MakeAll(); if the next frame of the moved frame, and the "this" frame in PrepareMake(), is a SwTabFrame, then the pFrame->FindNext() will return not this SwTabFrame, but the first SwTextFrame *inside* the SwTabFrame - hence the iteration will never meet the "pFrame == this" termination condition and the SwTabFrame remains unformatted; this warning is printed: warn:legacy.osl:6874:6874:sw/source/core/layout/calcmove.cxx:296: :-( Layout unstable (this not found). (regression from 18765b9f) Change-Id: I68207ba9cf68cd5abe51d647cb757176261eda40 Reviewed-on: https://gerrit.libreoffice.org/72797 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
at paragraph deletion, because it's more annoying, than helpful. Note: ODT file saving copies the page break into the deleted paragraph, but not the DOCX export. See also commit 22639148 "tdf#54819 change tracking: keep paragraph style after full deletion" Reviewed-on: https://gerrit.libreoffice.org/72611 Tested-by: Jenkins Reviewed-by:
-
Jim Raykowski yazdı
...and keep the 'More Characters...' button as first focused Change-Id: Iab4cb00aaed9250f0cc7f35f27af48eb326f2a48 Reviewed-on: https://gerrit.libreoffice.org/71834 Tested-by: Jenkins Reviewed-by:
Jim Raykowski <raykowj@gmail.com> (cherry picked from commit caa6de6c) Reviewed-on: https://gerrit.libreoffice.org/72772Reviewed-by:
-
- 22 May, 2019 8 kayıt (commit)
-
-
Michael Stahl yazdı
Fixes CVE-2019-5435. It looks like this is not a problem on 32-bit Windows because fortunately we don't use /LARGEADDRESSAWARE flag to set IMAGE_FILE_LARGE_ADDRESS_AWARE... but on 32-bit Linux the user-space VM is 3GB so an exploit might be possible. Apparently there's no code in LO that uses the CURLU_URLENCODE flag. The other one, CVE-2019-5436, doesn't matter because we disable tftp. Change-Id: I0d4f087befa5a3c4fb21ec36761dad68932425d9 Reviewed-on: https://gerrit.libreoffice.org/72732 Tested-by: Jenkins Reviewed-by:
-
László Németh yazdı
at paragraph join, because file saving or changing to Hide Changes mode don't affect this. Also adding page breaks to every paragraph of a deletion is much more annoying, than helpful. See also commit 1bbbe57d "change tracking: show layout changes at paragraph join" Reviewed-on: https://gerrit.libreoffice.org/72469 Tested-by: Jenkins Reviewed-by:
-
Julien Nabet yazdı
Regression from https://cgit.freedesktop.org/libreoffice/core/commit/?id=3208fcb3a36d75d6290d9c548430682f153b09db Change-Id: I8f85f0a5838df87671ecb9bdb5751b7ec43c09ea Reviewed-on: https://gerrit.libreoffice.org/72701 (cherry picked from commit ff251f4a) Reviewed-on: https://gerrit.libreoffice.org/72777Reviewed-by:
Julien Nabet <serval2412@yahoo.fr> Tested-by:
-
Michael Weghorn yazdı
Since 'QObject' and the 'Q_OBJECT' macro are used, the corresponding header needs to be included. Without the include and forward-declaration given here, the compiler doesn't know about 'QObject' and 'QAction' which are used further below, unless another header that takes care of this is included before 'QtMenu.hxx'. The error could be provoked e.g. by moving the '#include <Qt5Menu.hxx>' in front of all other includes in 'vcl/qt5/Qt5Frame.cxx'. Change-Id: I76c15eb445cbe26774d6e4177e12c93658daf0ad Reviewed-on: https://gerrit.libreoffice.org/65130 Tested-by: Jenkins Reviewed-by:
-
Michael Weghorn yazdı
As the Qt documentation for 'QFileDialog::supportedSchemes' says, setting supported schemes to a non-empty list restricts the available options: "Setting this property allows to restrict the type of URLs the user will be able to select. It is a way for the application to declare the protocols it will support to fetch the file content. An empty list means that no restriction is applied (the default)." The call to 'QFileDialog::setSupportedSchemes' was copied over from the gtk3_kde5 VCL plugin in commit 6196b729, where it had been added by commit f1b60bd6 "Support opening of (some) remote URLs through the KDE file dialog". Since only either all schemes (if nothing explicitly set) or a whitelist of supported locations seems to be possible (s.a. the Phabricator changes referenced in the commit message of commit f1b60bd6), add the "" scheme that makes removable devices shown -- while there doesn't seem to be an official documentation on the available schemes, at least not in KFileWidget's API documentation [1]. A quick test with all new available options after removing the call to 'QFileDialog::setSupportedSchemes' altogether indicated that opening and saving files there doesn't work reliably in all cases, so rather excplicitly add the "" scheme rather than claiming support for all schemes (including e.g. "timeline", "search", "remote", "trash"). [1] https://api.kde.org/frameworks/kio/html/classKFileWidget.html Change-Id: I89dc37d0f06d280e5dd599f90768c13e8edb915b Reviewed-on: https://gerrit.libreoffice.org/71320 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
... and also convert KDE5FilePicker. And Qt5Frame. The UNO methods in Qt5FilePicker/KDE5FilePicker have to ensure that the thread actually owns SolarMutex, because if RunInMainThread() is called without that it will deadlock. Change-Id: Ie4d2f494ac81c799ec7c9a3acb3a9b0f77bb6361 Reviewed-on: https://gerrit.libreoffice.org/68357 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
This prints a warning "Cannot create children for a parent that is in a different thread"; let's fix it before it causes another hard to debug crash. 0 check_parent_thread(QObject*, QThreadData*, QThreadData*) (parent=parent@entry=0xe88ca0, parentThreadData=<optimized out>, currentThreadData=<optimized out>) at kernel/qobject.cpp:781 1 check_parent_thread (currentThreadData=<optimized out>, parentThreadData=<optimized out>, parent=0xe88ca0) at kernel/qobject.cpp:822 2 QObject::QObject(QObject*) (this=0x9ed2e80, parent=0xe88ca0) at kernel/qobject.cpp:810 3 Adwaita::GenericData::GenericData(QObject*, QWidget*, int) () at /usr/lib64/qt5/plugins/styles/adwaita.so 4 Adwaita::WidgetStateEngine::registerWidget(QWidget*, QFlags<Adwaita::AnimationMode>) () at /usr/lib64/qt5/plugins/styles/adwaita.so 5 Adwaita::Animations::registerWidget(QWidget*) const () at /usr/lib64/qt5/plugins/styles/adwaita.so 6 Adwaita::Style::polish(QWidget*) () at /usr/lib64/qt5/plugins/styles/adwaita.so 7 QWidget::event(QEvent*) () at /lib64/libQt5Widgets.so.5 8 Qt5Widget::event(QEvent*) (this=0x7321790, pEvent=0x7f90c27d3750) at vcl/qt5/Qt5Widget.cxx:416 9 QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5 10 QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5 11 QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x7321790, event=0x7f90c27d3750) at kernel/qcoreapplication.cpp:1047 12 QWidget::ensurePolished() const () at /lib64/libQt5Widgets.so.5 13 QWidget::setVisible(bool) () at /lib64/libQt5Widgets.so.5 14 Qt5Frame::SetModal(bool) (this=0x9f411b0, bModal=true) at vcl/qt5/Qt5Frame.cxx:482 Change-Id: Ib6b4d1ee859dfce650422a6c7860abf2eb2686f1 Reviewed-on: https://gerrit.libreoffice.org/68356 Tested-by: Jenkins Reviewed-by:
-
Michael Stahl yazdı
During QFileDialog dtor, QSocketNotifier::setEnabled(false) is called, but it doesn't do anything other than print a stupid warning and so it's still registered and later it receives events after it's dead. 0 QSocketNotifier::setEnabled(bool) (this=this@entry=0x991c058, enable=enable@entry=false) at kernel/qsocketnotifier.cpp:240 1 QInotifyFileSystemWatcherEngine::~QInotifyFileSystemWatcherEngine() (this=0x991c030, __in_chrg=<optimized out>) at io/qfilesystemwatcher_inotify.cpp:260 2 QInotifyFileSystemWatcherEngine::~QInotifyFileSystemWatcherEngine() (this=0x991c030, __in_chrg=<optimized out>) at io/qfilesystemwatcher_inotify.cpp:258 3 QObjectPrivate::deleteChildren() (this=this@entry=0x991c240) at kernel/qobject.cpp:1997 4 QObject::~QObject() (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:1025 5 QFileSystemWatcher::~QFileSystemWatcher() (this=0x9641b60, __in_chrg=<optimized out>) at io/qfilesystemwatcher.cpp:277 6 QObjectPrivate::deleteChildren() (this=this@entry=0x2a30130) at kernel/qobject.cpp:1997 7 QObject::~QObject() (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:1025 8 QThread::~QThread() (this=0x2a079b8, __in_chrg=<optimized out>) at thread/qmutex.h:217 9 () at /lib64/libQt5Widgets.so.5 10 QScopedPointerDeleter<QObjectData>::cleanup(QObjectData*) (pointer=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:52 11 QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer() (this=0x98aa4d8, __in_chrg=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:107 12 QObject::~QObject() (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:884 13 QFileSystemModel::~QFileSystemModel() () at /lib64/libQt5Widgets.so.5 14 QObjectPrivate::deleteChildren() (this=0x97bab00) at kernel/qobject.cpp:1997 15 QWidget::~QWidget() () at /lib64/libQt5Widgets.so.5 16 QFileDialog::~QFileDialog() () at /lib64/libQt5Widgets.so.5 17 std::default_delete<QFileDialog>::operator()(QFileDialog*) const (this=0x9770f90, __ptr=0x926e970) at /usr/include/c++/8/bits/unique_ptr.h:81 18 std::unique_ptr<QFileDialog, std::default_delete<QFileDialog> >::~unique_ptr() (this=0x9770f90, __in_chrg=<optimized out>) at /usr/include/c++/8/bits/unique_ptr.h:274 19 Qt5FilePicker::~Qt5FilePicker() (this=0x9770ed0, __in_chrg=<optimized out>) at vcl/qt5/Qt5FilePicker.cxx:155 Change-Id: Iddfa3d44de59e1760e20a389566d9e6815ab26f7 Reviewed-on: https://gerrit.libreoffice.org/68355 Tested-by: Jenkins Reviewed-by:
-
