1. 31 Dec, 2020 1 commit
    • Stefano Crocco's avatar
      Revert "Fix focus when opening page in a new tab" · 1f014821
      Stefano Crocco authored
      This reverts commit a69162a9.
      
      It seems that this causes issues with links to non-html files. For
      example:
      - open a web page
      - from that page, middle click on a link to another web page to open it
        in another tab
      - from the second page, middle click on a link to a PDF file
      
      What should happen is that the PDF file is displayed in a third tab
      while the first two tabs remain unchanged. Instead, with original commit
      the PDF file is displayed not only in the third tab but also in the
      first one.
      1f014821
  2. 28 Dec, 2020 1 commit
    • Stefano Crocco's avatar
      Fix focus when opening page in a new tab · a69162a9
      Stefano Crocco authored
      When opening a page in a new tab by middle-clicking a link, focus wasn't
      moved to the new page but remained in the location bar. This happens
      because the createNewWindow signal is emitted by
      NewWindowPage::acceptNavigationRequest using an empty URL rather than
      the true URL. To fix this, the real URL is passed to the createNewWindow signal.
      a69162a9
  3. 23 Oct, 2020 1 commit
  4. 22 Oct, 2020 1 commit
    • Stefano Crocco's avatar
      Improve feature permission request · 194204a8
      Stefano Crocco authored and David Faure's avatar David Faure committed
      QtWebEngine only seems to support site-wide rather than page-wide
      feature permissions, since the URL passed by the
      featurePermissionRequest signal always has / as path. Since the
      permission bar was only shown if this URL is equal to the page's URL
      (which includes the path), they were almost never shown and the feature
      request was automatically denied (except for notifications). This is now
      fixed by comparing the request URL with an URL with / as path.
      
      Besides, the feature permission bar always had the same label (referring
      to geolocalization). Now the label has a different text according to the
      feature.
      
      Multiple permission bars can now be displayed at once.
      194204a8
  5. 17 Sep, 2020 1 commit
  6. 04 Sep, 2020 1 commit
  7. 30 Aug, 2020 1 commit
    • Stefano Crocco's avatar
      Add a Wallet submenu to the Tools menu · 9eeb270f
      Stefano Crocco authored
      The menu contains the same actions as the popup menu you get when
      clicking on the wallet icon. This makes the actions easier to discover
      and allows to access them using only the keyboard. Besides, it allows to
      assign shortcuts to them.
      9eeb270f
  8. 22 Aug, 2020 1 commit
    • Stefano Crocco's avatar
      Improve integration with KWallet · 3c109c19
      Stefano Crocco authored
      Konqueror fails to save user credentials in many sites for two reasons:
      - the site sets the autocomplete attribute to off for the fields (I
        can't understand whether this is an oversight or a conscious choice)
      - clicking the "login" (or similar) button causes
        QWebEnginePage::acceptNavigationRequest with a type argument different
        from NavigationTypeFormSubmitted. Since Konqueror uses that value to
        decide whether credentials should be saved or not, it doesn't save
        them.
      
      Given this situation, I believe that there's no simple way to
      automatically detect when credential saving and loading should be
      applied, so I decided to give the user the ability to manually choose
      which fields should be saved and to manually save them. In practice, I
      added three entries to the KWallet popup menu in Konqueror:
      - one displays a dialog where the user can choose which of the
        fields in the current page should be saved in KWallet. This allows to
        override the autocomplete=off HTML attribute
      - one allows to remove the customization described above
      - one immediately saves the credentials to KWallet, allowing
        to work around the NavigationTypeFormSubmitted issue.
      3c109c19
  9. 14 Aug, 2020 1 commit
    • Stefano Crocco's avatar
      Rely on QtWebEngine to determine the mimetype of http(s) URLs · 82241a80
      Stefano Crocco authored
      When KonqRun::scanFile is called from a view using a WebEnginePart and
      for a http or https URL with an unknown mimetype, don't use
      BrowserRun::scanFile but always return "text/html". This is because
      BrowserRun::scanFile issues a GET request to determine the mimetype, but
      QtWebEngine will then issue the same request, causing a double GET
      request. This way, instead, there will be only one GET request (from
      QtWebEngine). If QtWebEngine determines that the mimetype is one it
      can't open itself, the corresponding WebEnginePage will emit a
      openUrlRequest signal, with the real mimetype. Since the mimetype is now
      known, there isn't the risk of entering an endless loop.
      
      There are two problems:
      * the double GET request issue remains when the URL can't be displayed
        by QtWebEngine. QtWebEngine
        emits the downloadRequested signal after doing a GET request to determine the
        mimetype of the URL. Using KIO/KParts to download the file causes a second GET
        request.
      * using QtWebEngine to determine the mimetype forces the user to use
        WebEnginePart to open URLs with mimetypes it can hanlde, even if the user has
        chosen another part for them. For example, clicking an a link to an image in a
        remote web page will cause the image to be opened in WebEnginePart even if the
        user chose to use GwenViewPart for images. This happens because, since
        QtWebEngine can handle images, it doesn't emit the downloadRequested signal.
      82241a80
  10. 25 Jul, 2020 1 commit
  11. 19 Jul, 2020 2 commits
    • Stefano Crocco's avatar
      Mark the file downloaded from a blob as temporary · e6ee46cd
      Stefano Crocco authored
      When emitting the BrowserExtension::openUrlRequest for the file a blob
      URL was downloaded to, add an entry to
      KParts::OpenArgumentRequest::metaData. This entry is taken into account
      by KonqMainWindow::openUrlRequestHelper which will set the tempFile flag
      of the KonqOpenUrlRequest it creates to true.
      
      This way, if the file is opened in Konqueror, it's deleted when the
      corresponding tab does. It doesn't have any effect if the file is opened
      in an external application.
      e6ee46cd
    • Stefano Crocco's avatar
      Add support for full screen web pages · bc3a0717
      Stefano Crocco authored and David Faure's avatar David Faure committed
      Konqueror already has a full screen mode where the menu bar and the
      title bar are hidden and the window takes all the space in the screen.
      However, this isn't enough as some web pages (for example when those
      playing a video) now expect a full screen mode (which I call complete
      full screen) where an element of the page, and not just the window,
      takes all the screen.
      
      To achieve this kind of full screen, it's necessary to hide not only the
      menu bar and the title bar, but also the status bar, the tab bar and the
      tool bars. In theory, also the side bar and the terminal emulator should
      be hidden, but this commit doesn't to that.
      
      When switching to a different tab, the complete full screen mode is
      automatically exited (because it's strictly related to the contents
      of the page). Complete full screen mode is NOT entered again
      automatically when switching back to the previous page. This is
      consistent with the behavior of other browsers such as Chrome or
      FireFox.
      
      If Konqueror is exited while in complete full screen mode, its main
      window settings are not saved.
      bc3a0717
  12. 15 Jul, 2020 1 commit
    • Jonathan Marten's avatar
      Port and update the WebEnginePart · 1b6ba1e8
      Jonathan Marten authored and Stefano Crocco's avatar Stefano Crocco committed
      kDebug(), qDebug() -> qCDebug() with logging category
      Use Qt5 signal connection syntax
      KSslInfoDialog::errorsFromString() -> certificatErrorsFromString()
      Comment out unused KParts::SelectorInterface functions
      QHostAddress::operator=(QString) -> QHostAddress(QString)
      1b6ba1e8
  13. 23 May, 2020 1 commit
  14. 10 May, 2020 1 commit
  15. 04 Jan, 2020 1 commit
    • Stefano Crocco's avatar
      Avoid automatically displaying local URLs in WebEnginePart · b165ee39
      Stefano Crocco authored
      Summary:
      When a file URL is passed to WebEnginePage::acceptNavigationRequest,
      don't allow QtWebEngine to decide what to do with it (open it in the
      QWebEnginePage or not) but let Konqueror make the choice according to
      the user's configuration.
      
      Whitout this change, clicking on the "Home" link in the introduction
      page (konq:konqueror) opens the page in WebEnginePart, while it should
      open it in DolphinPart (or whichever part the user has chosen to display
      directories).
      
      Test Plan:
      from the introduction page (konq:konqueror) click the "Home Folder"
      link and check that the home folder is opened in DolphinPart and not
      WebEnginePart. Create an HTML file with a link to a local image file, open the
      HTML file in Konqueror and click on the link to the image. check that the image
      is opened in the part chosen to handle images.
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Differential Revision: https://phabricator.kde.org/D26417
      b165ee39
  16. 19 Nov, 2019 1 commit
  17. 21 Oct, 2019 1 commit
  18. 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
  19. 13 Jan, 2019 1 commit
  20. 10 Jan, 2019 2 commits
  21. 06 Jan, 2019 1 commit
  22. 20 Dec, 2018 1 commit
  23. 08 Nov, 2018 1 commit
  24. 04 Nov, 2018 1 commit
    • Stefano Crocco's avatar
      Ask the user what to do in case of a SSL certificate error · 011fdc2e
      Stefano Crocco authored
      Summary:
      When a certificate error happens, the user is asked whether to ignore
      the error or not.
      
      Things become more complicated if the page is loaded by
      WebEnginePart::load. In this case, SSL errors will have already been
      detected by the KParts framework, so asking the user again would be
      meaningless. To avoid this, before calling WebEngineView::load,
      WebEnginePart::load stores the URL in an instance variable of
      WebEnginePage: WebEnginePage::certificateError checks whether this
      variable is the same as the URL which produced the error and, in this
      case, always returns true.
      
      Unfortunately, it's impossible to integrate all of this with the KDE
      certificates management system, as QWebEngine doesn't provide any information
      about them except an error code and description.
      
      Test Plan:
      find a page with an invalid SSL certificate, enter it in the address
      bar then check that one (and only one) dialog is shown and that answering to
      ignore the error makes the page load.
      
      Attempt to load the web page from a link and check that the behaviour is the
      same.
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Differential Revision: https://phabricator.kde.org/D16355
      011fdc2e
  25. 07 Aug, 2018 1 commit
    • Stefano Crocco's avatar
      Synchronize cookies between QWebEngine and KCookieServer · b10baef5
      Stefano Crocco authored
      Summary:
      KHTML part and KWebKitPart both use KCookieServer to manage cookies,
      while WebEnginePart doesn't. This has at least two consequences:
      - cookie settings made using the ""Cookie" page in Konqueror settings dialog or
        in SystemSettings aren't honoured
      - you can't use KIO to download files from many sites (in particular, sites
        requiring authentication) because the cookies received by the browser and
        those used by KIO are different.
      
      Qt WebEngine provide a class, `QWebEngineCookieStore` to allow synchronizing
      cookies between Qt WebEngine and other systems. Unfortunately, the API provided
      by this class is quite different from the API used by KCookieServer.
      
      I added a class, `WebEnginePartCookieJar` to manage the synchronization of cookies
      between Qt WebEngine and `KCookieServer`, then added a static variable of this
      class to `WebEnginePart`. This static variable is filled by `WebEnginePart`'s
      constructor the first time it's created.
      
      `WebEnginePartCookieJar` does the following:
      - disables persistent cookies in `QWebEngineProfile`. This way, cookies will
        only be stored on disk by `KCookieStore`
      - on creation, loads cookies from `KCookieServer` and adds them to
        `QWebEngineCookieStore`
      - in response to the `QWebEngineCookieStore::cookiesAdded` signal, it adds the
        cookie to `KCookieServer` according to the Cookies KCM settings
      - in response to the `QWebEngineCookieStore::cookiesRemoved` signal, it removes
        the cookie from `KCookieServer`
      - in response to the `QApplication::lastWindowClosed` signal, it calls
        `KCookieServer::deleteSessionCookies` for each window (having store each
        window's id earlier).
      
      Some functionality is missing, however, because of `KCookieServer`'s API:
      - there's no way to know when a cookie is added to `KCookieServer` or removed
        from it, so (aside from loading the coockies from `KCookieServer` when the
        `WebEnginePartCookieJar` is created) the synchronization is only one-way: from
        the `QWebEngineCookieStore` to `KCookieServer`. This should not be an issue
        most of the times, but it also means that, if the user deletes a cookie from
        the Cookies KCM while Konqueror is running, this change won't be propagated to
        `QWebEngineCookieStore` until Konqueror is restarted
      - when the cookie policy is set to "Ask", `KCookieServer` doesn't provide a way
        to find out what the user chose. As a workaround, `WebEnginePartCookieJar`
        checks whether the cookie exists in `KCookieStore` and removes it from the
        `QWebEngineCookieStore` if it doesn't. However, there's no way to distinguish
        between an "Accept" and "AcceptUntilSession" answer.
      
      Some tricks have been needed to make all this work. In particular:
      - `QWebEngineCookieStore` only provides the origin URL to the function set as
        cookie filter; however, `QWebEngineCookieStore::setCookieFilter` only exists
        since Qt 5.11, so on earlier Qt versions we can't determine whether a cookie
        is a cross origin cookie or not and honour the corresponding setting in the
        Cookie KCM
      - `KCookieServer::addCookies` requires an URL as parameter, but
        `QWebEngineCookieStore::cookiesAdded` doesn't provide one (I thought the URL
        passed to the cookie filter could be used, but there's no warranty that the
        order the requests are passed to the filter is the same in which cookies are
        added). Looking at the source code for `KCookieStore` and `KCookieJar`,
        however, it seems that they use this parameter mainly to determine the domain
        if it isn't specified in the cookie. Since the `QNetworkCookie` given by
        `KCookieServer::addCookies` seems to always have a non-empty domain, the URL
        is created using that domain as host
      - since `QWebEngineCookieStore` doesn't provide a way to find out which page
        made the request resulting in a cookie, there's no way to be sure of the
        window ID to pass to `KCookieServer::addCookies`. `WebEnginePartCookieJar`
        assumes that the window is the active one (this, of course, is only a problem
        when Konqueror has more than one window open)
      - there's an issue with expiration times. `KCookieJar` reads expiration times
        using `QDateTime::fromString` which, it seems, always interpret that time as
        local time even if expiration times in cookies is in GMT; this can lead to
        cookies to be considered expired when they should not. For example, if my
        local time is GMT +1 and I receive a cookie at 14:00 (local time) which
        expires in half an hour, it's expiration field will be something like
        "13:30:00 GMT"; however `KCookieJar` seems to interpret it as 13:30 local time
        and, since in local time, the time is 14:00, it considers the cookie expired.
        I worked around this issue by manually setting the time zone in the
        `QNetworkCookie` to GMT, but I can't understand why this happens (it also
        happens when calling `KCookieServer::addCookie` from the command line using
        `qdbus`, but it doesn't happen when using KHTMLPart).
      
      Test Plan: Open the "Cookies" page in SystemSettings, remove all cookies, use Konqueror to navigate web pages using cookies and note which cookies have appeared in the list; repeat the operation using KHTML and check that the cookies are the same.
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Differential Revision: https://phabricator.kde.org/D14379
      b10baef5
  26. 04 Feb, 2018 1 commit
    • Stefano Crocco's avatar
      Add back KWallet support to Konqueror · 56ea2a32
      Stefano Crocco authored
      Summary:
      Added back the ability to store user names and passwords to KWallet and automatically fill them when loading a page.
      
      I copied the files `kwebwallet.cpp` and `kwebwallet.h` from the `KDEWebKit` framework and modified it to adapt to `QWebEngine`. In particular, I needed to modify the way form data is passed from javascript to C++ serializing it using JSON and read it back using `QJsonDocument`. Also, since `QWebEnginePage` doesn't allow to access frames from the C++ side, I needed to remove all the code dealing with recurisve searches and implement it in javascript.
      
      As the old code, this intentionally doesn't work with input elements with the `autocomplete` attribute set to `false`.
      
      I've not modified the copyright information in the files I copied from `KDEWebKit` as I don't know which is the correct way to do so: I must make clear my files are based on the work on other people but at the same time that I've changed them: how do I do this?
      
      Test Plan: I tried to access several sites requiring a login in, asking Konqueror to save the password, then logging out and visiting the page again. Except when the `autocomplete` attribute was `false` (checked by looking at the html code), Konqueror always saved and restored login information correctly.
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Differential Revision: https://phabricator.kde.org/D10178
      56ea2a32
  27. 24 Jul, 2017 1 commit
    • Stefano Crocco's avatar
      Fix download behavior when using webengine part · 77ee86e6
      Stefano Crocco authored and David Faure's avatar David Faure committed
      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
  28. 23 Jul, 2017 1 commit
    • 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
  29. 14 Jul, 2017 1 commit
    • David Faure's avatar
      Implement a file dialog for downloads · 86ed6024
      David Faure authored
      (rather than silently saving into ~/Downloads).
      
      We don't have a GUI like Firefox or Chrome to notify of on-going downloads,
      let's do as we always did and bring up a file dialog.
      86ed6024
  30. 03 Jan, 2017 2 commits
  31. 02 Jan, 2017 1 commit
  32. 05 Dec, 2016 1 commit
  33. 05 Nov, 2016 1 commit
  34. 01 Nov, 2016 3 commits
  35. 31 Oct, 2016 1 commit