- 03 Haz, 2019 2 kayıt (commit)
-
-
Grzegorz Araminowicz yazdı
up to maximal size of primFontSz constraint. Do not override text size changed by user. Change-Id: If7ea6bbb96cb839831d877edc274a1b0eefdaf21 Reviewed-on: https://gerrit.libreoffice.org/73050 Tested-by: Jenkins Reviewed-by:
Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/73251
-
Caolán McNamara yazdı
Change-Id: I570af8f19468730aad714425492f69d05c0a0cf3 Reviewed-on: https://gerrit.libreoffice.org/72853 Tested-by: Jenkins Reviewed-by:
Adolfo Jayme Barrientos <fitojb@ubuntu.com>
-
- 01 Haz, 2019 4 kayıt (commit)
-
-
Katarina Behrens yazdı
such as PI() or TRUE() Change-Id: I1243e6d6da7ac884d93d5d46058d94eb35f848ab Reviewed-on: https://gerrit.libreoffice.org/73242 Tested-by: Jenkins Reviewed-by:
Eike Rathke <erack@redhat.com> (cherry picked from commit ad2acdfa) Reviewed-on: https://gerrit.libreoffice.org/73295
-
Takeshi Abe yazdı
... installed on Windows. Change-Id: I2a4d846265b69f0e46e4c711430689ce39d60fcd Reviewed-on: https://gerrit.libreoffice.org/73211Reviewed-by:
Michael Stahl <Michael.Stahl@cib.de> Tested-by:
Xisco Faulí <xiscofauli@libreoffice.org>
-
Christian Lohmaier yazdı
Sandboxing prevents access to files in user profile as well as to contents of the LibreOffice.app unless it is manually triggered by the user. Even a clicking a link pointing to the files on an automatically opened file is not enough, the user would have to copy'n'paste the target. As a workaround force online help when default browser is Safari and running on 10.14 or later. (other browsers don't seem to enforce sandboxing yet and continue to work) also fix error in the meta tag for the intermediate page (delay and URL are both part of the content attribute and not separate) Change-Id: I6cc50ec1b1928c2416fdfef4cf50e2196a8594ae Reviewed-on: https://gerrit.libreoffice.org/73163Tested-by:
Olivier Hallot <olivier.hallot@libreoffice.org> Reviewed-by:
Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit 44893662) Reviewed-on: https://gerrit.libreoffice.org/73245Reviewed-by:
-
Eike Rathke yazdı
... while temporarily interpreting from within the Function Wizard. Change-Id: I88e7e062989ed395accd50ed9bfe1b76b3b297ea Reviewed-on: https://gerrit.libreoffice.org/73290Reviewed-by:
-
- 31 May, 2019 8 kayıt (commit)
-
-
Katarina Behrens yazdı
Change-Id: I55b4ab8ec5059110525c5194e1133c65bbd07fec Reviewed-on: https://gerrit.libreoffice.org/73183 Tested-by: Jenkins Reviewed-by:
Katarina Behrens <Katarina.Behrens@cib.de> Reviewed-on: https://gerrit.libreoffice.org/73257Reviewed-by:
Thorsten Behrens <Thorsten.Behrens@CIB.de>
-
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:
-
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 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:
-
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:
-
- 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:
-
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:
-
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 1 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:
-
