When the application is passed an invalid style option, we should fall
back to the style provided by the platform theme, not to the first
available style.
Change-Id: I59e25b00d4a32221dea7c960d0f4e0068247b2dd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
To match correctly (only) .h files, a regex needs to end in \.h$
Some of them missed the \, one missed the $.
(The last also had a legitimate .* before its misunescaped .)
One pair matched _p.h and _pch.h, which could be combined.
Change-Id: I7539a28eb7017cd0f1b36c72e05108e03a68a952
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
We need to delete the style returned from QStyleFactory::create()
ourselves, so put them into a QScopedPointer.
The alternative would have been to create this once, as a member
of tst_QWidget, but this is the minimal approach that ensures
behavior just as the old code, but without the leak.
Change-Id: I527f1031c57be6f05942f4acc057e7dae1af2571
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As found by UBSan:
qstandardgestures.cpp:511:67: runtime error: downcast of address 0x7ffc9beb1b90 which does not point to an object of type 'QTouchEvent'
0x7ffc9beb1b90: note: object is of type 'QPlatformSurfaceEvent'
fc 7f 00 00 08 93 b1 6f f5 2a 00 00 00 00 00 00 00 00 00 00 d9 00 ec 9b 00 00 00 00 49 01 c1 5e
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QPlatformSurfaceEvent'
#0 0x2af55edfa66a in QTapAndHoldGestureRecognizer::recognize(QGesture*, QObject*, QEvent*) qstandardgestures.cpp:511
#1 0x2af55ee3d9bb in QGestureManager::filterEventThroughContexts(QMultiMap<QObject*, Qt::GestureType> const&, QEvent*) qgesturemanager.cpp:276
#2 0x2af55ee4565b in QGestureManager::filterEvent(QWidget*, QEvent*) qgesturemanager.cpp:512
#3 0x2af55ee53945 in QGestureManager::filterEvent(QObject*, QEvent*) qgesturemanager.cpp:556
#4 0x2af55ea1b83a in QApplication::notify(QObject*, QEvent*) qapplication.cpp:3053
#5 0x2af573949d0f in QCoreApplication::notifyInternal2(QObject*, QEvent*) qcoreapplication.cpp:988
#6 0x2af56982ff94 in QCoreApplication::sendEvent(QObject*, QEvent*) qcoreapplication.h:231
#7 0x2af56982ff94 in QWindowPrivate::create(bool) qwindow.cpp:435
#8 0x2af55ecd10fe in QWidgetPrivate::create_sys(unsigned long long, bool, bool) qwidget.cpp:1471
#9 0x2af55ecc770e in QWidget::create(unsigned long long, bool, bool) qwidget.cpp:1333
#10 0x2af55ed80618 in QWidget::setVisible(bool) qwidget.cpp:8156
#11 0x4feec4 in tst_QWidget::touchEventsForGesturePendingWidgets() tst_qwidget.cpp:9824
qstandardgestures.cpp:512:67: runtime error: downcast of address 0x7ffc9beb1b90 which does not point to an object of type 'QMouseEvent'
0x7ffc9beb1b90: note: object is of type 'QPlatformSurfaceEvent'
fc 7f 00 00 08 93 b1 6f f5 2a 00 00 00 00 00 00 00 00 00 00 d9 00 ec 9b 00 00 00 00 49 01 c1 5e
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QPlatformSurfaceEvent'
#0 0x2af55edfaa19 in QTapAndHoldGestureRecognizer::recognize(QGesture*, QObject*, QEvent*) qstandardgestures.cpp:512
[... skipping common lines ...]
qstandardgestures.cpp:514:95: runtime error: downcast of address 0x
0x7ffc9beb1b90: note: object is of type 'QPlatformSurfaceEvent'
fc 7f 00 00 08 93 b1 6f f5 2a 00 00 00 00 00 00 00 00 00 00 d9 00 ec 9b 00 00 00 0
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QPlatformSurfaceEvent'
#0 0x2af55edfa966 in QTapAndHoldGestureRecognizer::recognize(QGesture*, QObject*, QEvent*) qstandardgestures.cpp:514
[... skipping common lines ...]
The problem is that the casts are done outside the switch that
determines the event's type, so for any given event object, at least
any two of the casts are invalid.
This could actually be a real problem, because it's trivial for a
compiler to prove that these three lines unconditionally invoke UB, so
it has all the right in the world to decide to drop the complete rest
of the function, using this line of reasoning:
1. The only way for these three casts not to be UB is if event ==
nullptr.
2. If event == nullptr, then event->type() invokes UB, so event cannot
be nullptr.
3. The only way both can be true is if this code path is never
taken. I can thus assume that
object == state && event->type() == QEvent::Timer
is always true, drop the check and execute the if block
unconditionally (I need to call QEvent::type(), to satisfy the
as-if-rule, but I needn't check its return value).
Fix by moving the casts where they belong: into each case of the
switch, where the type of the event has been checked to match the
target type of the cast.
Change-Id: I3aee8e213dc19d2f51636bcc5221cc92b3142e58
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Found by UBSan:
qwidget.cpp:5228:62: runtime error: downcast of address 0x61b00003d480 which does not point to an object of type 'QWidget'
0x61b00003d480: note: object is of type 'QMainWindowLayout'
bc 00 00 75 90 2e 2a 78 4f 2b 00 00 40 c1 02 00 f0 60 00 00 78 2f 2a 78 4f 2b 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QMainWindowLayout'
#0 0x2b4f70efb1c2 in sendResizeEvents qwidget.cpp:5228
#1 0x2b4f70f65f7f in QWidget::grab(QRect const&) qwidget.cpp:5252
#2 0x6b1746 in tst_QWidget::render_task188133() tst_qwidget.cpp:6615
Fix by performing the cast only after the test for isWidgetType() has
succeeded.
Change-Id: I061a60ef35bcb5fbefb9bc7b84706c9dd5afd207
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Found by UBSan:
tst_qapplication.cpp:1754:48: runtime error: member access within address 0x7ffda11f2220 which does not point to an object of type 'SpontaneousEvent'
0x7ffda11f2220: note: object is of type 'QMouseEvent'
The code attempted to model the layout of a QEvent with another class
that allows public access to the memory location that (hopefully)
corresponds to QEvent::spont, gaining access by casting a QEvent
object to that specifically-crafted class.
Fix by the using the existing QSpontaneKeyEvent::setSpontaneous()
call, which, despite its name, works for all QEvent subclasses, and
which has already been fixed to not invoke UB (in bc087db).
Change-Id: I7db8b8a8a823f7d61ab17375142d19dc3874fea5
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
The Q_AUTOTEST_EXPORT is defined in all cases. So usage as #if
defined(Q_AUTOTEST_EXPORT) was wrong.
Change-Id: Ia1c1526ad08fdfa35ca773d7c62f8bbba39a6d38
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Regression from 2d2d9078, which assumed the code in QBackingStore::beginPaint
would apply to macOS as well, but QHighDpiScaling::isActive() is only active
when Qt does the high DPI scaling, so we never hit the resize() code-path.
Adds backingStore() accessor to go from QPlatformBackingStore to QBackingStore.
Change-Id: I5de2ade74e731df445ea22e0f49b2a121e678efe
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Adds two formats that does not have optimized code-paths in qdrawhelper
to ensure the generic path has coverage.
This has already uncovered one bug fixed before this patch could go in.
Change-Id: I0e0a1a873555b27f6438f69a76982b8e06263dcf
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Implements behavior for the --verbose switch already specified
but never implemented. Without this switch you would have to rebuild
qdbusxml2cpp to see error output. Using -V will now produce error output such as:
dbus.parser: unknown token "" "Characters"
dbus.parser: Invalid D-BUS interface name 'com.qt-project.dbus' found while parsing introspection
dbus.parser: unknown token "" "Characters"
dbus.parser: skipping unknown element "method"
dbus.parser: xml error "Opening and ending tag mismatch." doc "..."
Task-number: QTBUG-34126
Change-Id: Ie5b7ec78007ddc305b1e7ddbffb1436920721c9c
Reviewed-by: Rolf Eike Beer <eb@emlix.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We've observed that on machines with SELinux installed but disabled, the
behavior of readdir() changes slightly. In the case of tst_qdir's
entryList QDir::Hidden test case, the listing of the directory contents
returns DT_UNKNOWN for the files and (broken) symlink(s) that are
present. When SELinux is enabled, we do see DT_REG and DT_LNK. Our
fallback to DT_UNKNOWN however resets merely the knownFlags, it does not
reset entryFlags, as all the other cases do.
The bug comes when QDirIteratorPrivate::advance() re-uses the
QFileSystemMetaData instance across iterations, and this way we get the
entryFlags values from a previous iteration (with != DT_UNKNOWN) into
the evaluation of an entry with DT_UNKNOWN.
The more conservative approach to fixing this is here by assuming that
QFileSystemMetaData is not designed for re-use and re-initialize it
explicitly in the iteration.
Change-Id: I875856f5ee63a7072d172033e90d02cf41bcab20
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
We want the coordinates for a mouse event to be the
position at the time of event generation, not the
current position.
This is a followup to 39be577c which fixed this for
some cases. This commit replaces all usages of
[NSEvent mouseLocation] with code that gets the location
from the event.
Change-Id: I691a46a61ce65e2b33335453b5b22de01f76d767
Task-id: QTBUG-54399
Task-id: QTBUG-37926
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The check for Q_... macros used a regex that didn't allow digits; it
thus failed to match Q_DECLARE_SHARED_NOT_MOVABLE_UNTIL_QT6().
Change-Id: I3f9339349aa21e2fea04a7f53d9d8e0903e4c65b
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
QDateTimeEdit ignores the time-spec of its date-time value, using its
own time-spec instead; mostly, this works because it first conforms
the value to its own time-spec. However, during construction, before
doing this, it set up its display data, which could leave it with a
different time (rather than a different representation of the given
time) than it was asked to use.
Moved the updateTimeSpec() calls to immediately after setting value in
QDateTimeEditPrivate::init() to ensure correct handling. Added test.
Task-number: QTBUG-54781
Change-Id: I3b07c10997abb858fc0b40558bff96e3fdabbd83
Reviewed-by: Jesus Fernandez <jesus.fernandez@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
The Windows Intel drivers reject shader sources without
a version directive in 3.2+ compatibility profiles. This
is odd but can be worked around by adding #version 110
(which should be the default...)
Change-Id: I1ccac41b80121e6423d4f8964d03dda52a433296
Task-number: QTBUG-55733
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
1. QSslSocketBackendPrivate::transmit was ignoring 'readBufferMaxSize';
as a result, we can have a user trying to set read buffer's size
to a small value (and more important - reading slowly in a small
chunks from this socket), but SSL itself socket reading 'too fast',
potentially growing its internal buffer to a huge size. This also
results in auto-tests failing - whenever we're trying to limit read
rate in some test.
2. Update qsslsocket auto-test.
Task-number: QTBUG-43388
Task-number: QTBUG-55170
Change-Id: Iedece26df0ac5b3b7cad62cc8c98aedc28e7ca5b
Reviewed-by: Richard J. Moore <rich@kde.org>
To make NVidia EGLStreams work on the desktop, we need to use eglGetPlatformDisplayEXT
instead of eglGetDisplay. Therefore, let's try that first if we have the extension.
Change-Id: Id420fb46d5bc5345faa5cbb066584b0859d50417
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
When color fonts are loaded from data, the font returned will
be a DirectWrite engine even the hinting preference does not
require it. This would cause a crash as we unconditionally cast
the pointer to QWindowsFontEngine*.
Using GDI and the unique family name hack to load the font from
data works fine, but we need to make sure we reference count
the font resource in this case, so we have to implement the
setUniqueFamilyName() logic in the DirectWrite engine as well
for this specific case.
[ChangeLog][Windows] Fixed crash when loading color fonts from
data.
Task-number: QTBUG-55595
Change-Id: I05443e8a396105da68ac4872b48339130b86c7f6
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
In setMinAndMaxSize(), QLayout::removeItem() doesn't actually delete
the removed item. We have to do that ourselves (RAII not necessary,
since the spacer is owned by the layout until we remove it).
In distributeMultiCell(), allocate the QStyle subclass on the stack so
the compiler cleans it up properly on all exit paths (was:
unconditional leak).
Change-Id: I24f8f11af2bfc5abf78f9aab0139dcfe0187402b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
In sizeConstraints(), QLayout::takeAt(), as the name suggests, doesn't
actually delete the item. We have to do that ourselves.
Likewise, in replaceWidget(), QLayout::replaceWidget() also doesn't
delete the affected item, but returns it. That's spectacularly bad API
design, but the leak is easy to fix: just delete the return value.
Change-Id: I8dcbc59898949eabce766cda2c0edae2e1f2799e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Found by UBSan:
qlayout.cpp:612:50: runtime error: downcast of address 0x7ffcd4c39a70 which does not point to an object of type 'QWidget'
0x7ffcd4c39a70: note: object is of type 'QObject'
00 00 00 00 b0 43 4c 7b f5 2a 00 00 70 c9 28 02 00 00 00 00 08 93 9a 77 f5 2a 00 00 00 00 c3 d4
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QObject'
#0 0x2af56f189960 in QLayout::widgetEvent(QEvent*) qlayout.cpp:612
#1 0x2af56f037660 in QApplicationPrivate::notify_helper(QObject*, QEvent*) qapplication.cpp:3732
#2 0x2af56f06ae5b in QApplication::notify(QObject*, QEvent*) qapplication.cpp:3704
#3 0x2af57989e383 in QCoreApplication::notifyInternal2(QObject*, QEvent*) qcoreapplication.cpp:988
#4 0x2af5799c1696 in QCoreApplication::sendEvent(QObject*, QEvent*) qcoreapplication.h:231
#5 0x2af5799c1696 in QObjectPrivate::setParent_helper(QObject*) qobject.cpp:2043
#6 0x2af5799c4823 in QObject::~QObject() qobject.cpp:1095
#7 0x2af56f2d205d in QWidget::~QWidget() qwidget.cpp:1549
#8 0x2af56f9c1366 in QFrame::~QFrame() qframe.cpp:262
#9 0x2af56f9e76cb in QLabel::~QLabel() qlabel.cpp:247
#10 0x458077 in tst_QStyleSheetStyle::emptyStyleSheet() tst_qstylesheetstyle.cpp:1400
Fix by not casting at all (or, to be precise, casting implicitly up
instead of explicitly down).
Change-Id: Ic19fd29e0cabd1aee5b1c93ca4c0fc70bc7a5927
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Found by UBSan:
qstackedlayout.cpp:261:98: runtime error: downcast of address 0x60400003cd10 which does not point to an object of type 'QtFriendlyLayoutWidget'
0x60400003cd10: note: object is of type 'QWidget'
0e 00 80 76 70 0b 06 3f d6 2a 00 00 00 99 00 00 50 61 00 00 20 0d 06 3f d6 2a 00 00 00 00 be be
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QWidget'
#0 0x2ad637b8f58f in qt_wasDeleted qstackedlayout.cpp:261
#1 0x2ad637b8f58f in QStackedLayout::takeAt(int) qstackedlayout.cpp:285
#2 0x2ad637b4afcb in QLayout::removeWidget(QWidget*) qlayout.cpp:1369
#3 0x413534 in tst_QStackedLayout::testCase() tst_qstackedlayout.cpp:155
Caused by using a struct to get access to QWidgetPrivate::wasDeleted
using a cast. That cast is invalid, of course, so simply use
QWidgetPrivate::get().
Caveat: we need a const version of that function, but that didn't
exist, yet, so added one.
Change-Id: I27d449b90be7e2072646d950c676b500ef698349
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The default should be false, meaning the application will prefer to
use a native menubar if the platform supports it. The application
author can set it to true if he wants to always use a Qt-rendered
menubar instead; or, he can call QMenuBar::setNativeMenuBar().
Qt and its plugins should not override the author's wishes.
Instead, if the platform plugin cannot create a native menubar
for whatever reason, createPlatformMenuBar() will return null,
and QMenuBar will fall back to using a Qt menubar instead.
The application can check the result via QMenuBar::isNativeMenuBar().
QMdiArea when maximized inside a QMainWindow with an empty title
does not replace the main window's title if we are using native menus.
This behavior turned out to be the same on Unity as it is on macOS,
so the autotest needed adjustment to expect that behavior whenever
the menubar is native, not only on certain platforms.
tst_QMenuBar::allowActiveAndDisabled() tests a standalone QMenuBar.
In f92f78094 it was disabled on macOS, but on Ubuntu it passes as
long as we force it to be a non-native menubar, so it should pass
that way on macOS too. Removed unused variable RESET to fix warning.
Task-number: QTBUG-54793
Change-Id: I716e40da709f96331cbbf25213bd7bc153e4dbe2
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
A check "just in case" -- we don't want leaks nor crashes
due to double deletions, and so on.
Change-Id: I24f1a486f0d438595bbe352ab780b07c5d53acbd
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Following f6cb8b1af8, take
advantage of the nullptr return case of QGraphicsItem
::toGraphicsObject() by not looking up nullptr in the
QList and the two QHashes. They don't contain nullptrs.
Change-Id: Ic1cfbb4c60061577a09348ef78fdc573f95ad9a8
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Found by UBSan:
qcolordialog.cpp:86:5: runtime error: downcast of address 0x7ffdf50c1ec0 which does not point to an object of type 'QColorDialog'
0x7ffdf50c1ec0: note: object is of type 'QDialog'
fd 7f 00 00 d8 6e c7 23 b7 2a 00 00 50 c1 af 01 00 00 00 00 b0 70 c7 23 b7 2a 00 00 00 00 1a 1e
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QDialog'
#0 0x2ab720e4ec97 in QColorDialogPrivate::q_func() const qcolordialog.cpp:86
#1 0x2ab720e4ec97 in QColorDialogPrivate::canBeNativeDialog() const qcolordialog.cpp:1865
#2 0x2ab720e84ed6 in QDialog::setVisible(bool) qdialog.cpp:696
#3 0x2ab720e6c1fa in QDialog::~QDialog() qdialog.cpp:357
#4 0x2ab720e2b276 in QColorDialog::~QColorDialog() qcolordialog.cpp:2187
#5 0x2ab720e5e2c6 in QColorDialog::getColor(QColor const&, QWidget*, QString const&, QFlags<QColorDialog::ColorDialogOption>) qcolordialog.cpp:2148
#6 0x2ab720e5e473 in QColorDialog::getRgba(unsigned int, bool*, QWidget*) qcolordialog.cpp:2176
#7 0x407180 in tst_QColorDialog::testGetRgba() tst_qcolordialog.cpp:118
qfiledialog_p.h:112:5: runtime error: downcast of address 0x7ffd6858cc60 which does not point to an object of type 'QFileDialog'
0x7ffd6858cc60: note: object is of type 'QDialog'
a1 2b 00 00 d8 1e 5e 0c a1 2b 00 00 b0 af 01 20 a1 2b 00 00 b0 20 5e 0c a1 2b 00 00 00 00 46 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QDialog'
#0 0x2ba10980a9e7 in QFileDialogPrivate::q_func() const qfiledialog_p.h:112
#1 0x2ba10980a9e7 in QFileDialogPrivate::canBeNativeDialog() const qfiledialog.cpp:695
#2 0x2ba1097efe36 in QDialog::setVisible(bool) qdialog.cpp:696
#3 0x2ba1097d715a in QDialog::~QDialog() qdialog.cpp:357
#4 0x2ba109854c4b in QFileDialog::~QFileDialog() qfiledialog.cpp:380
#5 0x4179dc in tst_QFiledialog::init() tst_qfiledialog.cpp:175
Fix by replacing Q_Q with the the equivalent expression for QDialog.
We can't re-use QDialogPrivate::q_func() here, since that is private,
and probably should stay like that.
Also fix an invalid member call in
QColorDialogPrivate::canBeNativeDialog():
qcolordialog.cpp:2050:5: runtime error: member call on address 0x7ffdf50c1ec0 which does not point to an object of type 'QColorDialog'
0x7ffdf50c1ec0: note: object is of type 'QDialog'
fd 7f 00 00 d8 6e c7 23 b7 2a 00 00 50 c1 af 01 00 00 00 00 b0 70 c7 23 b7 2a 00 00 00 00 1a 1e
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QDialog'
#0 0x2ab720e4e5ea in QColorDialog::options() const qcolordialog.cpp:2050
#1 0x2ab720e4e8c8 in QColorDialogPrivate::canBeNativeDialog() const qcolordialog.cpp:1870
#2 0x2ab720e84ed6 in QDialog::setVisible(bool) qdialog.cpp:696
#3 0x2ab720e6c1fa in QDialog::~QDialog() qdialog.cpp:357
#4 0x2ab720e2b276 in QColorDialog::~QColorDialog() qcolordialog.cpp:2187
#5 0x2ab720e5e2c6 in QColorDialog::getColor(QColor const&, QWidget*, QString const&, QFlags<QColorDialog::ColorDialogOption>) qcolordialog.cpp:2148
#6 0x2ab720e5e473 in QColorDialog::getRgba(unsigned int, bool*, QWidget*) qcolordialog.cpp:2176
#7 0x407180 in tst_QColorDialog::testGetRgba() tst_qcolordialog.cpp:118
by accessing the data member directly instead of through the Public API.
Fix the same code in QFileDialog, even though the autotest coverage is
too limited for UBSan to point that one out explicitly.
This commit amends abe8b4ab9b, in which
it should have been included in the first place...
Change-Id: Iff0538eba61d2381359f0b61f35918d643f7aa0c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Found by UBSan, which was so shocked that it crashed:
#6 <signal handler called>
#7 __dynamic_cast () at ../../../../gcc/libstdc++-v3/libsupc++/dyncast.cc:50
#8 0x00002b9278fa1c3b in __ubsan::checkDynamicType(void*, void*, unsigned long) () from /opt/gcc/trunk/lib64/libubsan.so.0
#9 0x00002b9278fa10c3 in HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned long, unsigned long, __ubsan::ReportOptions) () from /opt/gcc/trunk/lib64/libubsan.so.0
#10 0x00002b9278fa1783 in __ubsan_handle_dynamic_type_cache_miss () from /opt/gcc/trunk/lib64/libubsan.so.0
#11 0x00002b926c08ab8d in QApplication::notify(QObject*, QEvent*) () at /home/marc/Qt/qt5/qtbase/src/widgets/kernel/qapplication.cpp:3120
(full backtrace originates in tst_QWidget::testDeletionInEventHandlers(),
testing key events).
Fix is simple: just perform the cast before delivering the event.
Change-Id: Ic26e36f47ef57e980c0dba00900927ff39fe6392
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We checked if we had seen the interface by looking into seenInterfaces
and seenIndexes, but we never updated those variables with what we saw
in this block.
This fixes the reporting of PPP interfaces as well as TUN/TAP virtual
interfaces.
Change-Id: I33dc971f005a4848bb8ffffd1476830b8482b808
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Unify generic and ARGB32PM versions for fetchTransformed, the main
benefit of the specialized version is the simplified fetch, but we can
also get that by ensuring the method can be inlined.
At the same time move runtime inline of fetchPixel in
fetchTransformedBilinear to compile time using a similar model.
Change-Id: I0c1ed2ea4d4a3fb1b6dd3973823c0925101ed18e
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Writing to solid overwrites part of the gradient input messing up later
lines. In particular repeating gradients tended to be broken.
Tested by lancelot (once the baseline is correct).
Change-Id: I64222048ba67b0424b44822f09ddc947973145a6
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
The test function tries to create a file inside the application bundle.
Change-Id: Ia429b42b102d5e98f20694058fa2633e3c7de30a
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Windows of type Qt::ToolTip should not prevent closing the
application when checking for the last window.
Task-number: QTBUG-55523
Change-Id: I47c51abe79bf6c857aba229960de95e1a23efb10
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
Hide the tooltip when a window is requested to close in addition
to focus/activation change. This fixes the tooltip blocking
the shutdown of a Qt Quick Controls application.
Task-number: QTBUG-55523
Change-Id: I09d10fc162ce125075b03c534412b488974d12b9
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
This macro is used similarly to the \image command; it wraps the image
in a div with class attribute 'border' that allows additional styling
in CSS.
Change-Id: I94271074378d79f0e52f1f5a4715a1f84e0254dc
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
In change db2764db34, we introduced
the requirement of having specific OpenType tables available
to certain fonts. Before, we would not require OpenType support
to use a font for Myanmar text, for instance, since this was
not listed as one of the languages requiring OpenType support.
This patch simply brings back the limitation that fonts are only
disqualified by missing tables if the language is one of the
ones we know to require OpenType.
Change-Id: I6f1ee2c8a068f9e183a36e24967f331dae96c14b
Task-number: QTBUG-55569
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
There is no need to switch to the current directory, when there is no
process support. This also fixes running the test on sandboxed target
platforms.
Change-Id: I25fabb8b22d3510062a012884eb1eaab682901d3
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The stretch, once it is passed to the font engine, is assumed to
be the horizontal scale needed to match the requested stretch
for the given font. When loading from data in QRawFont, there
is no way to specify this stretch; the scale should always be 1.
The effect of this was that when DirectWrite was backing a font
loaded through QRawFont directly from data, then the glyph images
would be scaled to 0xHEIGHT before they were returned, thus
they would be empty.
This was a regression caused by
ec7fee968f.
Task-number: QTBUG-56091
Change-Id: I38e76e0e8f6809262474922946752b2ad0d6209b
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
