1. 17 Sep, 2020 1 commit
  2. 04 Sep, 2020 1 commit
  3. 25 Jul, 2020 1 commit
  4. 19 Jul, 2020 1 commit
  5. 18 Jul, 2020 2 commits
  6. 17 Jul, 2020 1 commit
  7. 15 Jul, 2020 1 commit
  8. 13 Jul, 2020 2 commits
  9. 05 Jul, 2019 1 commit
    • Stefano Crocco's avatar
      Use QWebEngineDownloadItem::page() if possible · 30995139
      Stefano Crocco authored
      Summary:
      Starting from Qt 5.12.0, QWebEngineDownloadItem knows which page
      requested the download, so there's no more need to record calls to
      WebEnginePage::acceptNavigationRequest and use them to try to guess the
      correct page.
      
      WebEngineDownloadManager still keeps a list of all pages because,
      according to the documentation, QWebEngineDownloadItem::page() can
      return nullptr "if the download was not triggered by content in a page".
      If this happens, one of the pages (chosen arbitrarily) is used.
      
      Test Plan:
      Compile Konqueror using Qt 5.12.0 or later, try to download a file and check
      that it happens correctly
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Differential Revision: https://phabricator.kde.org/D22272
      30995139
  10. 06 Jan, 2019 1 commit
  11. 24 Jul, 2017 2 commits
    • David Faure's avatar
      GIT_SILENT coding style fixes for previous commit · 420318e9
      David Faure authored
      (cherry picked from commit 888fc319)
      420318e9
    • Stefano Crocco's avatar
      Fix download behavior when using webengine part · 77ee86e6
      Stefano Crocco authored
      With KHTML and KWebKitPart, clicking on a download link would make
      konqueror embed the downloaded file in the current view or in another
      tab or window according to the user settings.
      
      To have the same happen with WebEnginePart, the openUrlRequest signal
      must be emitted by the part in response to
      QWebEngineProfile::downloadRequested
      signal.
      
      To achieve this, a new class, WebEnginePartDownloadManager, is
      introduced. This class connects to QWebProfile::downloadRequested signal
      and to a new signal, navigationRequested, from each existing
      WebEnginePage.
      
      The navigationRequested signal (emitted by a web page's
      acceptNavigationRequest method) allows the download manager to associate
      each download request with a navigation request, and, consequently, with
      the WebEnginePage which requested the download (this is necessary
      because there's no way to associate the download request with a
      QWebEnginePage automatically). At this point, the openUrlRequest is
      emitted from the part corresponding to the page. Note that the download
      is not performed using QWebEngineDownloadItem (that is,
      QWebEngineDownloadItem::accept is not called).
      
      Sometimes, a download is requested without a corresponding call to
      acceptNavigationRequest: in this case, the signal is emitted from an
      arbitrary part, specifying to open the file in a new window.
      
      This process doesn't always work, expecially when downloads are started
      from javascript or by clicking on links forcing a download or specifying
      a _blank target. These issues need to be investigated further
      
      Differential Revision: https://phabricator.kde.org/D6781
      
      (cherry picked from commit c217801a)
      77ee86e6
  12. 23 Jul, 2017 2 commits
    • David Faure's avatar
      888fc319
    • Stefano Crocco's avatar
      Fix download behavior when using webengine part · c217801a
      Stefano Crocco authored
      With KHTML and KWebKitPart, clicking on a download link would make
      konqueror embed the downloaded file in the current view or in another
      tab or window according to the user settings.
      
      To have the same happen with WebEnginePart, the openUrlRequest signal
      must be emitted by the part in response to
      QWebEngineProfile::downloadRequested
      signal.
      
      To achieve this, a new class, WebEnginePartDownloadManager, is
      introduced. This class connects to QWebProfile::downloadRequested signal
      and to a new signal, navigationRequested, from each existing
      WebEnginePage.
      
      The navigationRequested signal (emitted by a web page's
      acceptNavigationRequest method) allows the download manager to associate
      each download request with a navigation request, and, consequently, with
      the WebEnginePage which requested the download (this is necessary
      because there's no way to associate the download request with a
      QWebEnginePage automatically). At this point, the openUrlRequest is
      emitted from the part corresponding to the page. Note that the download
      is not performed using QWebEngineDownloadItem (that is,
      QWebEngineDownloadItem::accept is not called).
      
      Sometimes, a download is requested without a corresponding call to
      acceptNavigationRequest: in this case, the signal is emitted from an
      arbitrary part, specifying to open the file in a new window.
      
      This process doesn't always work, expecially when downloads are started
      from javascript or by clicking on links forcing a download or specifying
      a _blank target. These issues need to be investigated further
      
      Differential Revision: https://phabricator.kde.org/D6781
      c217801a