1. 21 Oct, 2020 2 commits
  2. 20 Oct, 2020 2 commits
  3. 02 Oct, 2020 1 commit
  4. 21 Sep, 2020 1 commit
  5. 18 Sep, 2020 1 commit
  6. 16 Sep, 2020 1 commit
  7. 17 Jul, 2020 1 commit
  8. 16 Jul, 2020 1 commit
  9. 30 Jun, 2020 2 commits
  10. 04 Jun, 2020 1 commit
  11. 28 May, 2020 1 commit
  12. 08 May, 2020 3 commits
  13. 07 May, 2020 2 commits
  14. 06 May, 2020 2 commits
  15. 04 May, 2020 1 commit
  16. 28 Apr, 2020 1 commit
  17. 30 Mar, 2020 1 commit
  18. 27 Mar, 2020 1 commit
  19. 19 Mar, 2020 1 commit
  20. 18 Mar, 2020 1 commit
  21. 02 Dec, 2019 1 commit
  22. 01 Dec, 2019 1 commit
    • flypig's avatar
      [qtbase] Check alternative connections when connecting. Contributes to JB#47349 · 22410ac3
      flypig authored
      QNetworkAccessManager keeps track of a single connected session (e.g.
      Wifi, mobile data) at a time. If the currently tracked session
      disconnects, it checks whether any other network configuration is
      online, and if so, it switches to make this the current session.
      
      However, if the currently tracked session changes to the Connecting
      state, QNetworkAccessManager will claim the network is inaccessible,
      even if other configurations are online, and will refuse to switch to a
      different session until the current session state changes from
      Connecting to either Connected or Disconnected.
      
      Unfortunately, occassionally Wifi connections will move into the
      Connecting state and potentially not switch to the Connected or
      Disconnected state for some time, which can block connectivity for apps
      using QNetworkAccessManager to maintain connections (it's not clear
      whether this is because the connection actually gets stuck, or because
      the state change signals get lost somewhere; the result is the
      same).
      
      This change makes QNetworkAccessManager switch connection in case the
      current session moves to the Connecting state while another online
      configuration is available to use instead.
      22410ac3
  23. 26 Sep, 2019 1 commit
  24. 16 Aug, 2019 1 commit
  25. 12 Jul, 2019 4 commits
  26. 11 Jul, 2019 1 commit
  27. 01 Jul, 2019 1 commit
  28. 28 Jun, 2019 2 commits
    • flypig's avatar
      Ensure stateChanged signal connect matches disconnect · fcd0c681
      flypig authored
      A change to the connect signal introduced a lambda function, rather than
      calling stateChanged directly, so that the disconnect no longer matched
      the connect. This potentially prevented the disconnect from being
      applied correctly.
      
      This change matches the connect and disconnect up again.
      fcd0c681
    • flypig's avatar
      [qtbase] Ignore Connecting states received after session has closed. Contributes to JB#46185 · 20a249c5
      flypig authored
      QNetworkManager keeps track of a single connected session (e.g. Wifi,
      mobile data) at a time. If the currently tracked session disconnects, it
      relies on receiving a status update from the session in order to trigger
      it to move to a different connection.
      
      As part of this, it also relies on the signals it connects to from the
      QNetworkSession being queued, because QueuedConnection sends its
      closed() signal before it sends its Disconnected stateChanged() signal.
      QNetworkManager disconnects the signals on receiving the closed()
      signal, but still needs to receive the Disconnected stateChanged()
      signal in order to trigger a switch to a different connection.
      
      Unfortunately, QNetworkSession can also send out Connecting
      stateChanged() signals after the closed() signal, and these are handled
      badly by QNetworkSession. The problemmatic sequence is:
      
      1. QNetworkManager receives a closed() signal and disconnects from the
      QNetworkSession.
      2. QNetworkManager receives a Connecting stateChanged() signal and sets
      itself to offline, but doesn't switch to another connection.
      3. QNetworkManager never receives any other signals from the now
      disconnected QNetworkSession, and so never changes state again and
      remains offline indefinitely.
      
      The only way to get out stage 3 is to go completely offline (e.g. turn
      off both Wifi and mobile data), because QNetworkManager also listens
      separately for offline/online signals. In contrast, disconnecting and
      reconnecting Wifi connections, or mobile data, without ever going fully
      offline, never gets out of state 3.
      
      This change forces QNetworkManager to ignore Connecting stateChanged()
      signals if they occur when there is no active QNetworkSession, so that
      stage 2 never happens.
      20a249c5
  29. 23 May, 2019 1 commit