summaryrefslogtreecommitdiff
path: root/desktop
AgeCommit message (Collapse)Author
2017-11-10Upgrade these SAL_WARNs to INFOPranav Kant
These are very common occurrences. Let's not flood the warning output. Also ressurrect some helpful looking commented out SAL_INFOs Change-Id: I3368fb46b27b72edd8ba1f52e2a145a661c40477
2017-11-09lokdialog: Compress invalidation callbacks in Callback flush handlerPranav Kant
Change-Id: Id76bde54395611f509a5d4be6bb2ac9b7f6ed1c0 Reviewed-on: https://gerrit.libreoffice.org/44474 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: pranavk <pranavk@collabora.co.uk>
2017-11-09lokdialog: Move getting dialog information in separate LOK callPranav Kant
Using outparameters to get the dialog information with the paintDialog call was quite confusing. Change-Id: Ief331b251dc66e66084b827ce5b025ba6c9ce7d2 Reviewed-on: https://gerrit.libreoffice.org/44473 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: pranavk <pranavk@collabora.co.uk>
2017-11-09lokdialog: Support painting parts of the dialogPranav Kant
Pass the dimensions of the region to the paintDialog call to paint only that much of the region in the dialog. The DIALOG_INVALIDATE callback also returns a 'rectangle' field now in the payload that tells the region of the dialog invalidated. It can be used in combination with the new paintDialog call then to paint only the invalidated region in the dialog. Change-Id: Iebb228865c71684e0f75dd01271b71ae41a0f906 Reviewed-on: https://gerrit.libreoffice.org/44472 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: pranavk <pranavk@collabora.co.uk>
2017-11-08sw lok: add Accept/Reject All tracked changes, tdf#101977Henry Castro
Change-Id: I04d747343e24cb498a621c965d034d0791411d83 Reviewed-on: https://gerrit.libreoffice.org/44311 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Henry Castro <hcastro@collabora.com>
2017-11-06loplugin:finalclasses in dbaccessNoel Grandin
Change-Id: I7cbc786407ee798950a7fdc98f43aee0845ff862 Reviewed-on: https://gerrit.libreoffice.org/44347 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-06Finally make DbusIpcThread terminateStephan Bergmann
...by directly calling shutdown(3) on the underlying socket, to make dbus_connection_read_write fall out of its internal poll(3) call blocked on POLLIN (upon which it returns false). (dbus_connection_close only calls close(3), so calling it from DbusIpcThread::close would merely decrement the socket file descriptor's reference count.) This removes the need for the sent- to-self "Close" command (whose processing turned out to be too brittle in parallel with closing the connection down, witness my previous three fruitless commits in this area). There appears to be no need to explicitly call dbus_bus_release_name, as the session bus apparently takes care of releasing the name as soon as the associated connection is closed. Also there should be no need to call dbus_connection_read_write_dispatch instead of just dbus_connection_read_write, and dbus_message_pop_message should probably be called in a loop, until all queued messages are processed. Change-Id: I13f30b6676a531f349e953329e910c1ff45ee53e
2017-11-06loplugin:constparams in various(2)Noel Grandin
Change-Id: I533a7eb724b15e168a28dc92cd5962a39bc96e7c Reviewed-on: https://gerrit.libreoffice.org/44313 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-05Remove GetNextSubset and create GetSubsetMapJulien Nabet
To avoid to store an iterator and simplify loops Change-Id: I9b160714125176841961a56905d81dcb876c68b6 Reviewed-on: https://gerrit.libreoffice.org/44326 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-11-04Related: tdf#113160 set parent of warning dialogs during loadCaolán McNamara
to the new window frame being constructed that (may) contain the progress bar, that way such modal dialogs affect the loading document window and not whatever window happens to be active Change-Id: I1c7d3185e47fa316eef003b80d18b31d341b79d6 Reviewed-on: https://gerrit.libreoffice.org/44269 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-11-04Make Windows error reporting more robustMike Kaganski
https://msdn.microsoft.com/en-us/library/ms679351 describes that "it is unsafe to take an arbitrary system error code returned from an API and use FORMAT_MESSAGE_FROM_SYSTEM without FORMAT_MESSAGE_IGNORE_INSERTS" Previously in case when an error string would contain inserts, function returned error, so the error message wasn't shown (at least it didn't crash, thanks to nullptr as the function's last argument). As the function may fail, we now pre-nullify the buffer pointer to avoid dereferencing uninitialized pointer later (though at least for some Windows versions, the function nullifies the pointer in case of FORMAT_MESSAGE_ALLOCATE_BUFFER, but there's no explicit guarantee of this). Also release of allocated buffer is changed to recommended use of HeapFree. The code that doesn't make use of OUString is left directly calling FormatMessage, to avoid introducing new dependencies. Where it makes sense, we now use WindowsErrorString from <comphelper/windowserrorstring.hxx> Change-Id: I834c08eb6d92987e7d3d01e2c36ec55e42aea848 Reviewed-on: https://gerrit.libreoffice.org/44206 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-11-04Following 42bfbc216474b4f60d5a5e52a88d95baded5191cJulien Nabet
as suggested by Stephan in comment of https://gerrit.libreoffice.org/#/c/44233/ Change-Id: Ia0a8c36441339628fd61ba862df73db11bbed302 Reviewed-on: https://gerrit.libreoffice.org/44276 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-11-03Replace remaining lists by deques (desktop)Julien Nabet
because of addToUnoRc and addToConfigmgrIni which use push_front (and no easy way to change this), I couldn't use vectors + use for range loops Change-Id: I15300122b449b3a5af7c6402a7ad4cd5a2000413 Reviewed-on: https://gerrit.libreoffice.org/44233 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-11-02improve constparam lopluginNoel Grandin
lots of little fixes to make the logic less pessimistic Change-Id: If368822984250b11b98c56f5890177a1402e8660 Reviewed-on: https://gerrit.libreoffice.org/44168 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-01Replace some lists by vectors in deployment/registry (desktop)Julien Nabet
Change-Id: I264a8b4d8fc90f647d5a6f1aef4a190353d494e5 Reviewed-on: https://gerrit.libreoffice.org/44143 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-01loplugin:constantparam in d*Noel Grandin
Change-Id: I65c395157d2b68a549a6fecf9abf1fd46446d960 Reviewed-on: https://gerrit.libreoffice.org/44109 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-30Replace some lists by vectors in desktopJulien Nabet
Change-Id: Ib1cd2278d1af651b96f07c8831382bba7f51aed6 Reviewed-on: https://gerrit.libreoffice.org/44037 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2017-10-28lokdialog: Tunnel dialog title to lokclient as outparamPranav Kant
Change-Id: I1beb5ab3f06debdca7ebf999af7ac879a41ea47e Reviewed-on: https://gerrit.libreoffice.org/43959 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: pranavk <pranavk@collabora.co.uk>
2017-10-27loplugin:includeform: desktop (Windows)Stephan Bergmann
Change-Id: I245c58a3d97eb0d60e7063e9c34c77d33739801d
2017-10-27...and one more fix for DbusIpcThread,Stephan Bergmann
switching back to a "Close" message-to-self without a response (as it had been before dc3ff192f3f048059cf149f416d0b237eb33b014 "Avoid further unwanted interference of DbusIpcThread::execute/close"). Especially on a first start of LO (where it restarts after creating the UserInstallation), it had been observed that DbusIpcThread::close was blocked waiting on a reply in dbus_connection_send_with_reply_and_block while DbusIpcThread::enable had already successfully (i.e., without emitting any of the SAL_WARNs) proceeded past sending the reply and was blocked on closeDone_.wait(). However that can happen---it should be clear by now that I don't understand anything at all about DBus. :( Change-Id: Id5f368a60b2d8dd8b7074308ac1ad6b6545131ff
2017-10-26vcl: make MapMode constructor explicitMichael Stahl
Insert constructor everywhere, except a couple places that apparently want to compare GetMapUnit(). Change-Id: I1910deb60562e5e949203435e827057f70a3f988
2017-10-25iOS, soffice not needed for iOSjan Iversen
Removed the IPC part of init for iOS. Lo_init() completes for iOS without errors. Change-Id: I7ce38758883bebea1de6ac149ba8768593c7cb78
2017-10-25Avoid further unwanted interference of DbusIpcThread::execute/closeStephan Bergmann
...after 38081c0884b64ed1132047973b4dccc42d548c89 "Avoid race between DbusIpcThread::close and DbusIpcThread::execute" Change-Id: I812f53525f4c2c051781321dac7096e3bf0d7054
2017-10-24Avoid race between DbusIpcThread::close and DbusIpcThread::executeStephan Bergmann
...that caused Flatpak'ed LO to sometimes not terminate properly after 243d743dae127fe11ecd7f807121da8815af8f01 "solenv/flatpak-manifest.in: incorporate upstream sandboxing improvements" had removed --socket=session-bus and thus introduced flatpak-dbus-proxy into the mix: > Oct 24 15:25:16 <sberg_> I'm not sure who's at fault there; on the LO side I > have a thread processing incoming dbus requests (DbusIpcThread::execute, > <https://opengrok.libreoffice.org/xref/core/desktop/source/app/officeipcthread.cxx#552>); > that thread is typically waiting within dbus_connection_read_write_dispatch > for new messages; if LO wants to close, it needs to get that thread out of > dbus_connection_read_write_dispatch, and the only way I found back then is > what's in DbusIpcThread::close (just following DbusIpcThread::execute), with > a big "this apparently needs a more DBus-y design anyway" testament to my > cluelesness re dbus; it calls dbus_bus_get_private to connect to itself, and > send a Close message that'll cause DbusIpcThread::execute to fall out of the > loop; the dbus_bus_get_private leads to a flatpak_proxy_incoming in the > proxy, which returns TRUE, and after that I see no further activity in the > proxy (but not sure what functions I should all put breakpoints on), and the > LO side is hung in dbus_bus_release_name a few lines futher down > Oct 24 15:26:20 <alexlarsson> sberg_: i ran this: > https://github.com/sgh/dbus-examples/blob/master/dbus-signal.c > Oct 24 15:26:27 <alexlarsson> sberg_: which calls dbus_bus_release_name > Oct 24 15:26:30 <alexlarsson> and it seems to work for me > Oct 24 15:26:39 <alexlarsson> If i --own-name=org.DBusTest.SignalTest > Oct 24 15:27:50 <sberg_> so maybe it's related to my unorthodox way of trying > to quit the dbus loop there; if anybody with a clue about dbus would be > willing to help me with the above, I'd be very grateful :) > Oct 24 15:28:06 <alexlarsson> I don't see how the proxy should affect it tho > Oct 24 15:28:11 <alexlarsson> other than maybe timing? > Oct 24 15:29:06 <sberg_> maybe; I think I've seen things actually succeed once > when I stepped through the proxy somewhat manually > Oct 24 15:31:01 <alexlarsson> sberg_: eeeentresting > Oct 24 15:31:07 <alexlarsson> sberg_: so, it does an own-call > Oct 24 15:31:13 <alexlarsson> sberg_: maybe that is what breaks? > Oct 24 15:31:33 <sberg_> yeah, that's my dumb speculation > Oct 24 15:34:38 <alexlarsson> So, you send the close from another thread, not > waiting for the reply > Oct 24 15:34:56 <alexlarsson> then you start working on the main connection > immediately > Oct 24 15:35:02 <alexlarsson> shouldn > Oct 24 15:35:25 <alexlarsson> shouldn't you grab the mutex after that? > Oct 24 15:36:35 <alexlarsson> This whole thing smells racy > Oct 24 15:38:18 <alexlarsson> My guess is that with regular dbus, the flush > call will schedule dbus daemon which sends back the message, waking up the > other thread before continuing > Oct 24 15:38:22 <sberg_> alexlarsson, ah, yeah, I see; apparently didn't > occur to me back then that I mustn't call dbus_bus_release_name when the > execute loop may still be busy > Oct 24 15:38:25 <alexlarsson> But now you have two context switches > Oct 24 15:38:37 <alexlarsson> so we continue before we get the reply > Oct 24 15:38:44 <alexlarsson> eh, not reply > Oct 24 15:38:46 <alexlarsson> the close message > Oct 24 15:38:52 <alexlarsson> and then you race > Oct 24 15:39:11 <alexlarsson> Honestly i don't remember the exact rules for > dbus threadedness > Oct 24 15:39:58 <sberg_> ...so looks like something that can be corrected on > the LO side after all; I'll give it a try > Oct 24 15:40:17 <alexlarsson> you're calling dbus_threads_init_default(), so > it should be nominally threadsafe > Oct 24 15:40:29 <alexlarsson> still, I imagine it can still deadlock > Oct 24 15:43:12 <alexlarsson> sberg_: i still don't see the exact deadlock > though > Oct 24 15:43:32 <alexlarsson> i imagine working on the separate private > connection is threadsafe > Oct 24 15:43:35 <alexlarsson> and we flush that > Oct 24 15:44:08 <alexlarsson> then we call dbus_bus_release_name, which i > imagine would block if the dbus thread is in read_write_dispatch > Oct 24 15:44:35 <alexlarsson> The question is, why is the close message not > delivered? > Oct 24 15:44:44 <alexlarsson> I mean, we flushed it... > Oct 24 15:45:48 <alexlarsson> sberg_: oh, i think i know > Oct 24 15:45:53 <alexlarsson> sberg_: release_name probably sent some message, > but then the other thread pop:ed the reply > Oct 24 15:46:04 <alexlarsson> sberg_: queue very long wait > Oct 24 15:51:53 <sberg_> alexlarsson, yeah, sounds plausible; thanks! > Oct 24 15:52:14 <sberg_> (now that I want to reproduce it, closing succeeds > cleanly every time I try, of course...) > Oct 24 15:54:48 <alexlarsson> sberg_: obviously > Oct 24 15:55:30 <alexlarsson> sberg_: that just makes the race theory more > valid tho > Oct 24 15:57:31 <sberg_> alexlarsson, yup, after stopping the unrelated > background LO build that had put the machine under full load, I see it hang > again in release_name, while the execute loop is still happily running too; > that nicely confirms your theory > Oct 24 15:58:28 <alexlarsson> sberg_: alternatively you could tell your users > to always build LO in the background > Oct 24 15:59:04 <sberg_> I'll try to put that into the release notes; lets > see... Change-Id: I2a8a58f9259d2854f42f4aa3db5bb232cf70845d
2017-10-24iOS, updated desktop/source/lib/init.cxxjan Iversen
InitVCL() needs to be called for iOS, even though it runs without desktop, since that function fills structures like mpDefInst Change-Id: Icebd4a4111881b46a8abc1e1988921a19e5e4527
2017-10-23loplugin:includeform: desktopStephan Bergmann
Change-Id: I2dacb21cd0c9618dadb49912e0f09c9ab576f9b0
2017-10-23overload std::hash for OUString and OStringNoel Grandin
no need to explicitly specify it anymore Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec Reviewed-on: https://gerrit.libreoffice.org/43567 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-22oss-fuzz: drop our own afl related hackeryCaolán McNamara
Change-Id: Ia6a498c07fffd1790ad433287ef4d1cf82085887 Reviewed-on: https://gerrit.libreoffice.org/43695 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-20tdf#113311 disable CppunitTest_libreofficekit_tiledrendering for nowMichael Stahl
Change-Id: I0f6e284d232388019bfa33f07a4afc864e0040a9
2017-10-20drmemory: fix small leakCaolán McNamara
Change-Id: Ib7f6beb52dc832ee570e21ac5ab65d25946b622f Reviewed-on: https://gerrit.libreoffice.org/43597 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-18set parent of extension file dialogCaolán McNamara
Change-Id: I9791fceb975ca9d0a0ca0ae61c0890826d06c564 Reviewed-on: https://gerrit.libreoffice.org/43510 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-18Resolves: tdf#112891 give restart dialog a parentCaolán McNamara
Change-Id: Iaeb0060f390035bb214b9d1d8d090e7b933c9f77 Reviewed-on: https://gerrit.libreoffice.org/43509 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-10-13Log found extension updatesJan-Marek Glogowski
The OSL_ASSERT doesn't make any sense, if you don't know what it compares. So simply log all found updates. Change-Id: I002b65cf4a658036916a217a89d0df7f0168ee70
2017-10-12EPUB export: add simple example to command line helpCor Nouws
Change-Id: Ia1a03f324e9b66dc36abadc326843b88b33ed249 Reviewed-on: https://gerrit.libreoffice.org/43348 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-10-05Rename and move SAL_U/W to o3tl::toU/WMike Kaganski
Previosly (since commit 9ac98e6e3488e434bf4864ecfb13a121784f640b) it was expected to gradually remove SAL_U/W usage in Windows code by replacing with reinterpret_cast or changing to some bettertypes. But as it's useful to make use of fact that LibreOffice and Windows use compatible representation of strings, this commit puts these functions to a better-suited o3tl, and recommends that the functions be consistently used throughout Windows-specific code to reflect the compatibility and keep the casts safe. Change-Id: I2f7c65606d0e2d0c01a00f08812bb4ab7659c5f6 Reviewed-on: https://gerrit.libreoffice.org/43150 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-10-04add << operator for css::uno::ExceptionNoel Grandin
Change-Id: Ia23dafd07133779144965682df3b7125a3214235 Reviewed-on: https://gerrit.libreoffice.org/43046 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2017-10-04Revert "check for unnecessary DLLPUBLIC annotations"Stephan Bergmann
This reverts commit a599eeab786ecbe1b5b6509e3c792e5c1ba31248, plus follow-up fa4431449d0306e8179f53a2a69c549800bd24bd "Avoid bogus loplugin:dllmacro 'unnecessary *DLLPUBLIC declaration ...'". See (abandoned) <https://gerrit.libreoffice.org/#/c/42983/> "loplugin:dllmacro: Handle implicit member functions" how this would have needed to be extended to give consistent results across Linux and macOS, but then would have started to remove DLLPUBLIC from entities that apparently need to at least have default type visibility on macOS and started to make tests fail.
2017-10-03Replace more reinterpret_cast with SAL_W/SAL_UMike Kaganski
Change-Id: Ia632e4083222ad9e7f17c2ad0d0825f189c700cc Reviewed-on: https://gerrit.libreoffice.org/43071 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-10-03lok: Fix declaration of ‘xContext’ shadows a global declaration.Jan Holesovsky
Change-Id: Iab3c142cd85ca54bf3c37a0710ce7da7a5d77a35
2017-10-03LOK: getSpellLanguages() is not necessary in comphelper in the end.Jan Holesovsky
Change-Id: If81cd3d4508ba3f44304a9ec9b643bf771e8930c
2017-10-03new loplugin:blockblockNoel Grandin
Change-Id: I7b68b70fa4c7234e8882f7627026959a596968fd Reviewed-on: https://gerrit.libreoffice.org/43025 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-03lok: use getCommandValues to obtain a list of languagesHenry Castro
Change-Id: I4a1f04b9dfe9e3ebbc174380db93c332e958ccfa Reviewed-on: https://gerrit.libreoffice.org/43060 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Henry Castro <hcastro@collabora.com>
2017-10-02lok - sc: row/column headers are updated fasterMarco Cecchetti
Now the computation of the row/column headers data exploits the cached row/col positions in HeightHelper/WidthHelper. That makes updating row/column headers at the bottom of the document as fast as at the top even for very big spreadsheets. Change-Id: I27381b520aaed68662e4d07c5879046d182c70e6 Reviewed-on: https://gerrit.libreoffice.org/40451 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Marco Cecchetti <mrcekets@gmail.com>
2017-10-02Removed duplicated includesAndrea Gelmini
Change-Id: I2f2c31e3605c1bff353b5749c593305c3fc7028f Reviewed-on: https://gerrit.libreoffice.org/43044 Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-10-02tdf#44497 run LicenseDialog with SolarMutex lockedJan-Marek Glogowski
Before commit 3840aede596e6fc24f7ed7df9100fb028134aac6 releasing an unlocked SolarMutex was simply ignored, but now it aborts. So run the LicenseDialog GUI code holding the SolarMutex, as required. Change-Id: Id9f5f6146cdfe2b21b68a2cdffc9dd4a527b551c Reviewed-on: https://gerrit.libreoffice.org/42951 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-10-02Change CB_DIALOG_INVALIDATE to CB_DIALOGPranav Kant
We can specify whether it is an invalidation or something else in the payload. Change-Id: I95c5fc0a0a88b5277eaa93c8d1f9b937bddce7b3
2017-10-02lokdialog: Mouse events for dialog floating child windowsPranav Kant
Change-Id: I06a081835d246f752e57f8cc289162ed31fc91d4
2017-10-02lokdialog: Support for rendering floating window dialog widgetsPranav Kant
Now gtktiledviewer can show floating window dialog widgets when user clicks any of such widget in the dialog. Change-Id: I13d756f236379bc8b2041ed41cb7b502f7fd9b24
2017-10-02lokdialog: Set up intial posting mouse events to dialogsPranav Kant
Events from the dialog in GTV are forwarded correctly, but the events are still not processed by the dialog in core. Change-Id: Ib95ac0a3cd23f6cc2763c21425a67402b15f2de2
2017-10-02lokdialog: Suppress duplicate callbacks in flush handlerPranav Kant
Change-Id: I94578b9e9c7fc2e6a9d14effe456d821768a0bcb
generated by cgit (git 2.34.1) at 2025-01-24 18:59:08 +0000