1. 17 Nov, 2021 1 commit
  2. 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>
  3. 22 Oct, 2021 4 commits
  4. 04 Oct, 2021 1 commit
  5. 30 Sep, 2021 2 commits
  6. 29 Sep, 2021 2 commits
  7. 28 Sep, 2021 2 commits
  8. 27 Sep, 2021 1 commit
  9. 23 Sep, 2021 2 commits
  10. 10 Aug, 2021 1 commit
  11. 06 Aug, 2021 2 commits
  12. 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)
    • 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
      [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)
    • 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>
  13. 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>
  14. 06 Jul, 2021 1 commit
  15. 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
      [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>
  16. 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
      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>
  17. 09 Jun, 2021 1 commit
  18. 08 Jun, 2021 1 commit
  19. 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
      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>
  20. 18 May, 2021 1 commit
  21. 14 May, 2021 2 commits
  22. 10 May, 2021 5 commits
  23. 07 May, 2021 1 commit
  24. 12 Apr, 2021 1 commit
  25. 08 Apr, 2021 1 commit