Skip to content
GitLab
  1. 17 Nov, 2021 1 commit
  3. 01 Nov, 2021 1 commit
    • Tor Arne Vestbø's avatar
      macOS: Compute NSWindow background color without checking styleMask · 1d5a2e92
      Tor Arne Vestbø authored and Volker Hilsheimer's avatar Volker Hilsheimer committed 
      The check for styleMask == NSWindowStyleMaskBorderless to decide whether
to clear the NSWindow background was broken, as NSWindowStyleMaskBorderless
has the value 0, but is only supposed to be compared to its companion
NSWindowStyleMaskTitled (with value 1). A window can perfectly well be
NSWindowStyleMaskBorderless and NSWindowStyleMaskMiniaturizable e.g.,
so by comparing directly to NSWindowStyleMaskBorderless instead of
masking to the first bit first we ended up making miniaturizable
windows non-translucent.

We now check the Qt::FramelessWindowHint directly, and also whether
the window is opaque. Ideally we'd have QWindow flags that could
plumb WA_NoSystemBackground from Qt Widgets, as well as a background
color property on QWindow to control the system background, but
in the meantime we'll have to use the FramelessWindowHint heuristic.

The QWidget docs have been updated to reflect this.

Task-number: QTBUG-95042
Change-Id: I0d40eecace60883c205ebb8c76cef1092cdf1144
(cherry picked from commit 2f6d572d

)
Reviewed-by: Volker Hilsheimer's avatarVolker Hilsheimer <volker.hilsheimer@qt.io>
      1d5a2e92
  5. 22 Oct, 2021 4 commits
  7. 04 Oct, 2021 1 commit
  9. 30 Sep, 2021 2 commits
  11. 29 Sep, 2021 2 commits
  13. 28 Sep, 2021 2 commits
  15. 27 Sep, 2021 1 commit
  17. 23 Sep, 2021 2 commits
  19. 10 Aug, 2021 1 commit
  21. 06 Aug, 2021 2 commits
  23. 05 Aug, 2021 3 commits
    • Mike Achtelik's avatar
      Android: Fix unnecessary clipboard data access · 47254826
      Mike Achtelik authored 
      

Android 12 introduced a notification which is shown to the user each
time the app accesses the clipboard via getPrimaryClip.
Currently this notification is triggered, even if we just want to check,
if some clipboard data exists.
So lets not get the actual data and instead use getPrimaryClipDescription
to check for the existence of the correct mime type in the clipboard.

Change-Id: I4800f5545ab46b7f6cade0ce9d78c04b50ae96cf
Reviewed-by: default avatarAssam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 5a7f4c1f)
      47254826
    • Marc Mutz's avatar
      QXpmHandler: fix re-entrancy bug in xpm_color_name · 419505ab
      Marc Mutz authored 
      

The xpm_color_name() function returned a pointer to a function-static
buffer. This is infamously non-reentrant, and an actual problem,
because we explicitly allow QImage operations (incl. saving to an
.xpm) from non-GUI-threads.

Fix by using the CSS pattern (Caller-Supplied Storage; also used in
the QAnyStringView(char32_t) and QAnyStringView(QStringBuilder) ctors)
to force the caller to allocate storage in its own stack frame. As a
consequence, we re-gain re-entrancy, but the returned pointer is now
only valid until the end of the full-expression, which isn't a problem,
as all callers immediately pass the result to a consumer (asprintf() or
QByteArray).

[ChangeLog][QtGui][QImage] Fixed a race condition when concurrently
writing .xpm files.

Change-Id: I36d7173d53839a52f5cdf58324474c1b32c71f33
Reviewed-by: default avatarMårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 73fabadc)
      419505ab
    • Timur Pocheptsov's avatar
      tst_QSslCertificate::verify - skip auto-test · 5fa5013d
      Timur Pocheptsov authored 
      

as a temporary fix for suddenly expired certificates situation (to
be regenerated).

Task-number: QTBUG-95429
Change-Id: I00ad11cfd8824eeeffa2991dfcda6a7899726953
Reviewed-by: default avatarMårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 8d0e4a2e

)
Reviewed-by: default avatarTimur Pocheptsov <timur.pocheptsov@qt.io>
      5fa5013d
  25. 12 Jul, 2021 1 commit
    • Tor Arne Vestbø's avatar
      macOS: Don't mangle QByteArray settings with @ prefix by decoding as UTF-8 · 1ea03973
      Tor Arne Vestbø authored 
      

QSettings encodes QVariants as @Type(data) strings. If that data contains
a null-byte, we write the string as UTF-8 encoded CFData. When reading it
back we look for a @ prefix, and then pass it as UTF-8 through stringToVariant.

The problem arises then the user writes raw QByteArrays with a @ prefix.
We can detect this situation by checking the result of stringToVariant,
and if it's just a simple conversion of the string into a QVariant, we
know that stringToVariant hit its fallback path due to not finding any
embedded variants.

If that's the case, we return the raw bytes as a QByteArray.

Change-Id: I4ac5c35d0a6890ebea983b9aca0a3a36b0143de2
Reviewed-by: default avatarThiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 3eac6079

)
Reviewed-by: default avatarQt Cherry-pick Bot <cherrypick_bot@qt-project.org>
      1ea03973
  27. 06 Jul, 2021 1 commit
  29. 29 Jun, 2021 1 commit
    • Marc Mutz's avatar
      QVarLengthArray: fix aliasing error in insert(it, n, v) · c5e45d73
      Marc Mutz authored 
      

Taking the copy after the resize is completely pointless: the copy is
there to ensure that `t`, being a reference potentially aliasing an
element in [begin(), end()[ before the resize(), isn't invalidated by
the resize(), so it must be taken before resize().

Add a comment so the next rewrite doesn't cause this to be mixed up
again.

[ChangeLog][QtCore][QVarLengthArray] Fixed an aliasing bug affecting
insertions of objects aliasing existing elements.

Change-Id: I26bc449fa99bf8d09a19147a12a69ac4314cc61d
Reviewed-by: default avatarGiuseppe D'Angelo <giuseppe.dangelo@kdab.com>
(cherry picked from commit 6e57e41f

)
Reviewed-by: default avatarQt CI Bot <qt_ci_bot@qt-project.org>
      c5e45d73
  31. 19 Jun, 2021 1 commit
    • Tor Arne Vestbø's avatar
      Enable glyph cache workaround for Apple M-family of GPUs · 4034daa1
      Tor Arne Vestbø authored 
      

Without the workaround, and when using a Core GL profile, we hit a code
path in QSGOpenGLDistanceFieldGlyphCache::resizeTexture() that produced
corrupt glyphs on M1 hardware.

We fix this by enabling the workaround, so that the user doesn't have to
set QT_ENABLE_GLYPH_CACHE_WORKAROUND themselves.

None-Core contexts do not have this problem, but the logic in
QOpenGLContext does not account for recreated contexts with different
formats, so we can't limit the workaround to Core formats only.

With the unified memory architecture of the M1 hardware, the workaround
should have limited negative effects.

In Qt 6 this is not a problem, since Qt Declarative effectively always
uses the workaround code-path, but it's worth recording the fact that
we need the workaround.

Fixes: QTBUG-89379
Change-Id: Icfd8b8b23c0dcda3fea8663d81d0e225134eec5e
Reviewed-by: default avatarEskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: default avatarLaszlo Agocs <laszlo.agocs@qt.io>
(cherry picked from commit aeeaa7d2

)
Reviewed-by: default avatarTor Arne Vestbø <tor.arne.vestbo@qt.io>
      4034daa1
  33. 09 Jun, 2021 1 commit
  35. 08 Jun, 2021 1 commit
  37. 01 Jun, 2021 1 commit
    • Giuseppe D'Angelo's avatar
      SQLite driver: fix crash when binding a QByteArray/QString · 07b690bc
      Giuseppe D'Angelo authored 
      

Passing SQLITE_STATIC to sqlite3_bind_*() means that ownership
of the data stays in the caller, i.e. SQLite itself doesn't make a copy;
such data must be therefore be kept valid until sqlite3_step() is called.

The code in the SQLite driver uses that option to avoid copying byte
array or string data. But, unlike what the comments in the code say, we
do NOT keep the QByteArray/QString alive long enough: they're contained
by a temporary QVariant object which gets destroyed at the end of the
loop that binds each argument.

Luckily the fix is simple: since that QVariant is just a copy of the
QVariants used as bound parameters, and these are held in a container
(which lives long enough), simply create a reference to the container's
elements rather than a copy. This ensures that the data is alive by
the time sqlite3_step() is called.

This problem doesn't normally appear because of implicit sharing of
QByteArray/QString. When the QVariant is copied, the inner element
is just a shallow copy. Getting the pointer to the data, and destroying
the QVariant, does not destroy the data (it's kept alive by the
QByteArray/QString inside the *copied-from* QVariant).

Of course there's a catch: if the *copied-from* QVariant contains a
QString created via fromRawData, then everything blows up. In this case,

1. the copied QVariant is created (which bumps the QString refcount)¹
2. the QString inside of it is accessed directly (via
QVariant::constData)
3. utf16() is called on that string, which detaches it (!)
4. the result of utf16() is passed to SQLite, with SQLITE_STATIC
5. the copied QVariant is destroyed; this destroys the inner QString,
which, being detached, deallocates the data too early.
6. sqlite3_step() is called, kaboom.

(The copied-from QVariant still has the string created by fromRawData.)

¹ Note that QString uses the Small QVariant Optimization, so the QString
object itself into the QVariant is copied, it's not just a *QVariant*
refcount increase.

Change-Id: Idcdb192809f1f8f79b4a901e1247f933eb06e854
Fixes: QTBUG-94070
Reviewed-by: default avatarAndy Shaw <andy.shaw@qt.io>
(cherry picked from commit 0f38259c

)
Reviewed-by: default avatarQt Cherry-pick Bot <cherrypick_bot@qt-project.org>
      07b690bc
  39. 18 May, 2021 1 commit
  41. 14 May, 2021 2 commits
  43. 10 May, 2021 5 commits
  45. 07 May, 2021 1 commit
  47. 12 Apr, 2021 1 commit
  49. 08 Apr, 2021 1 commit