1. 12 Aug, 2020 1 commit
    • Nicolas Fella's avatar
      Fix opening kwallet manager · 0123b144
      Nicolas Fella authored
      We were trying to launch a service (kwalletmanager_open) that doesn't exist.
      kwalletmanager5_open exists though.
      
      We don't need to do special handling for the manager being open already given that kwalletmanager is a KDBusService.
      
      This has the nice sideeffect of getting rid of QDBusInterface and KToolInvokation
      0123b144
  2. 19 Jul, 2020 1 commit
    • Stefano Crocco's avatar
      Add support for full screen web pages · bc3a0717
      Stefano Crocco authored
      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
  3. 15 Jul, 2020 1 commit
    • Jonathan Marten's avatar
      Port and update the WebEnginePart · 1b6ba1e8
      Jonathan Marten authored
      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
  4. 04 Jan, 2020 1 commit
  5. 03 Jan, 2020 1 commit
    • Stefano Crocco's avatar
      Port the About page to QtWebEngine · 64f94b6b
      Stefano Crocco authored
      Summary:
      Replace the old About Page based on KHtml with one based on QtWebEngine.
      
      This has been obtained creating a new QWebEngineUrlSchemeHandler for the `konq``
      scheme which will display the contents of the about page. The old `about` scheme
      can't be used because it's used internally by QtWebEngine.
      
      There are two problems. The first is that if the user's konquerorrc file
      contains old default value for the StartURL entry, that value will be used
      instead of the new one, which will result in an error message. I don't know how
      to force the use of the new default instead of the old one.
      
      The second problem is that clicking on the "Home Folder" link in the launch page
      will open the link in the WebEngine part instead of Dolphin part.
      
      Test Plan:
      after removing the StartURL entry from the user's konquerorrc file,
      launch Konqueror and check that the intro page is displayed. Click on one of the
      links in the page (Introduction, Tips, Specifications) and check that the
      correct page is displayed.
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Differential Revision: https://phabricator.kde.org/D26253
      64f94b6b
  6. 24 Aug, 2019 1 commit
    • Stefano Crocco's avatar
      Don't install a scheme handler for the "about" protocol · 4693187a
      Stefano Crocco authored
      Summary:
      The default mimetype for the "about" protocol is "text/html", so
      WebEnginePart::attemptInstallKIOSchemeHandler will try to install a
      scheme handler for it. This will fail with a warning from Qt because
      "about" is an internal protocol.
      
      Test Plan:
      configure Konqueror so that it displays the introduction page at
      startup, launch it from terminal and check that no warnings regarding the
      "about" protocol are displayed.
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Differential Revision: https://phabricator.kde.org/D23370
      4693187a
  7. 30 Jun, 2019 1 commit
  8. 23 Jun, 2019 1 commit
    • Stefano Crocco's avatar
      Register custom protocols using QWebEngineUrlScheme · 9552130e
      Stefano Crocco authored
      Summary:
      From Qt 5.12.0, before installing custom url scheme handlers, the scheme
      itself must be registered using QWebEngineUrlScheme.
      
      Registering URL schemes must be done before instantiating any
      QWebEngine class, so we do that at the beginning of WebEnginePart's
      constructor using a static function which only does the registration
      the first time it's called.
      
      Having to register url schemes before creating QWebEngine classes
      creates a problem beacuse we install scheme handlers dynamically from
      WebEnginePart::openUrl if the default mimetype for the URL (according to
      KProtocolManager::defaultMimeType) is 'text/html'. To avoid this issue,
      we use KProtocolInfo::protocols to obtain a list of all availlable
      protocols, create a fake URL for that protocol (as there's no way I can
      see to obtain the default mimetype for a protocol from KProtocolInfo)
      and use KProtocolManager::defaultMimeType on this URL to decide whether
      to register the URL scheme or not.
      
      Using QWebEngineUrlScheme also allows to specify that a given protocol can
      access local files, removing the need to use the html embedder from
      WebEnginePartKioHandler. Since this only works with Qt 5.12 or later, the html
      embedder is only disabled depending on the Qt version in use.
      
      Test Plan:
      run Konqueror with Qt 5.12 and check that no warnings about
      registering custom protocol are displayed on the terminal. Ensure that protocols
      such as about:, error:, man:, info: work correctly (for example, try man:cp or
      info:cp)
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Differential Revision: https://phabricator.kde.org/D21741
      9552130e
  9. 13 Jan, 2019 1 commit
  10. 10 Jan, 2019 3 commits
  11. 06 Jan, 2019 1 commit
  12. 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
  13. 21 Aug, 2018 1 commit
  14. 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
  15. 04 Aug, 2018 1 commit
    • Stefano Crocco's avatar
      Restore ability to view help pages from Konqueror · 51449ce9
      Stefano Crocco authored
      Summary:
      A generic QWebEngineUrlSchemeHandler which takes data from KIO::storedGet has been added and is now used also for man and info URLs. The old WebEnginePartHtmlMimetypeHandler has been changed into a class which only embeds the content of `file` URLs in the HTML code.
      
      I found out that several calls to `QWebEngineUrlSchemeHandler::requestStarted` may happen before the previous one has replied (it happened for the help protocol where the HTML code produced by KIO in turn contained `help` URLs). Because of this, I needed to implement a queuing mechanism in the new handler.
      
      The new handler can be used as a base class if special processing of data produced by KIO is needed
      
      Test Plan:
      - check that man pages displayed with WebEnginePart look as when displayed by KHTML (es: man:/cp)
      - check that help pages displayed with WebEnginePart look as when displayed by KHTML (es help:/kate)
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Differential Revision: https://phabricator.kde.org/D14233
      51449ce9
  16. 16 Jul, 2018 1 commit
    • Stefano Crocco's avatar
      Restore the ability to view man and info pages from Konqueror · d0842c88
      Stefano Crocco authored
      Summary:
      Add a QWebEngineUrlSchemeHandler which uses `KIO::get` to produce HTML code to be sent using `QWebEngineUrlRequestJob::reply`. This scheme handler is added whenever `WebEnginePart::openUrl` is called for an URL for which `KProtocolManager::defaultMimetype` returns `text/html`.
      
      The basic idea is taken from the implementation used in the `webengine_stream` branch, but instead of changing the way `KonqView::openUrl` works, it only adds the appropriate scheme handler.
      
      The main issue for this implementation to work is that QWebEngine refuses to load local resources in the generated HTML (images and CSS files) because of cross-origin rules. The only way to work around this limitation that I could think of is to parse the HTML code produced by `KIO::get` and to replace, in `img` and `link` elements the URL with a `data` URL embedding the content of the file. To do this, the scheme handler uses the external program **htmltidy** to convert the HTML generated by KIO into `XHTML`, then uses `QDomDocument` to parse the resulting XHTML file and replace the URLs appropriately. If one of these two steps fails, the original HTML will be used: this means that the user won't be able to see most of the formatting in the man/info pages but will be able to read the text.
      
      Unfortunately, there's still a problem I couldn't solve: some resources in the HTML produced by KIO use a `help` URL rather than the standard `file` one, but I couldn't find out to which file they point, so they aren't changed, meaning that the page is not displayed completely as it was intended.
      
      Test Plan: Open man and info pages from location bar and following links between such pages.
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Subscribers: pino
      
      Differential Revision: https://phabricator.kde.org/D13924
      d0842c88
  17. 25 Jun, 2018 1 commit
    • Stefano Crocco's avatar
      Display an error page for error URLs in WebEnginePart · 81e224f9
      Stefano Crocco authored
      Summary:
      When asked to display an error URL, WebEnginePart displayed another
      error telling that the web page "error:/..." can't be reached.
      
      To avoid this, add a scheme handler for the "error" scheme to the default
      profile. The handler replies with the html code read from an error.html page
      with placeholders replaced by the error details contained in the URL.
      
      The code used to produce the error page is taken, with small changes, by
      webpage.cpp from KWebKitPart. The error page, too is taken from KWebKitPart and
      modified a little.
      
      Test Plan:
      Entered an invalid URL in address bar and checked that the error message was
      displayed correctly.
      
      Reviewers: dfaure
      
      Reviewed By: dfaure
      
      Subscribers: anthonyfieroni
      
      Differential Revision: https://phabricator.kde.org/D12637
      81e224f9
  18. 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
  19. 02 Dec, 2016 1 commit
  20. 10 Nov, 2016 1 commit
  21. 05 Nov, 2016 1 commit
  22. 02 Nov, 2016 1 commit
  23. 01 Nov, 2016 3 commits
  24. 31 Oct, 2016 1 commit
  25. 29 Oct, 2016 3 commits
  26. 23 Oct, 2016 1 commit
  27. 21 Oct, 2016 1 commit