1. 17 Sep, 2020 1 commit
  2. 15 Sep, 2020 1 commit
  3. 12 Sep, 2020 2 commits
  4. 11 Sep, 2020 4 commits
  5. 10 Sep, 2020 2 commits
    • Stefano Crocco's avatar
      Add a button to display the credentials which will be saved · bcd15121
      Stefano Crocco authored
      Currently, when the user is asked whether to save credentials using the
      password bar, he has no way to know which values will be saved. To fix
      this, a button is added to the password bar to toggle a widget which
      displays those values.
    • Stefano Crocco's avatar
      Fix compilation with Qt 5.12 and Qt 5.13 · 8c8cb4fb
      Stefano Crocco authored
      Despite Qt 5.12 being the minimum required Qt version, the following
      functions introduced in Qt 5.14 were used:
      - QComboBox::textActivated (in settings/konqhtml/appearance.cpp)
      - downloadFileName, downloadDirectory, setDownloadFileName,
        setDownloadDirectory in QWebEngineDownloadItem
      Don't use QComboBox::textActivated
      Use QWebEngineDownloadItem::path and QWebEngineDownloadItem::setPath with Qt 5.13
  6. 09 Sep, 2020 1 commit
    • Stefano Crocco's avatar
      Ignore fields which most likely aren't for credentials · 900079a5
      Stefano Crocco authored
      There are some web fields which most likely the user will never want to
      store in KWallet, such as search fields. However, currently the KWallet
      integration also takes into account these, which can lead to surprising
      results (for example, the wallet icon being displayed for pages like
      Google which only has a search field).
      To avoid this, each field name is checked aginst a set of hard-coded
      field names which it's assumed the user will want to ignore.
  7. 08 Sep, 2020 2 commits
  8. 04 Sep, 2020 1 commit
  9. 03 Sep, 2020 1 commit
  10. 01 Sep, 2020 1 commit
  11. 31 Aug, 2020 1 commit
  12. 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.
  13. 29 Aug, 2020 1 commit
  14. 28 Aug, 2020 1 commit
    • Stefano Crocco's avatar
      Fix a bug causing being unable to overwrite existing cached data · c740a8ed
      Stefano Crocco authored
      This bug has been introduced by changing
      WebEngineWallet::WebEngineWalletPrivate::saveDataToCache so that it
      doesn't delete entries in pendingSaveRequests anymore but leaves this
      task to its caller. However, the caller can't know whether the data has
      actually been saved or whether the saveFormDataRequested signal has been
      emitted because the user needs to decide what to do. As a consequence,
      the entry in pendingSaveRequests will always be removed, so that when
      the user decides to save it, it won't be there anymore.
      To avoid this issue, saveDataToCache now returns a bool telling whether
      the data has been saved (and the entry must be remvoed) or not.
  15. 26 Aug, 2020 1 commit
  16. 23 Aug, 2020 3 commits
    • Stefano Crocco's avatar
      Add an entry to the wallet popup menu to start filling of web forms · 9f33ee4d
      Stefano Crocco authored
      Sometimes the user may need to fill the web forms on a page after the
      page has been loaded (for example because the page has unconvetional
      ways of asking for login information which prevent automatic filling
      from working).
      A second entry to show the wallet manager is also added to the menu.
    • Stefano Crocco's avatar
      Display different wallet icon depending on whether cached data exists · 73ecc2e1
      Stefano Crocco authored
      With the previous improvement to the KWallet integration, the open wallet
      icon was displayed in the status bar whenever the current page
      contained web forms, regardless of whether or not there was cached data.
      This is confusing for the user.
      Now if the web page contains forms but there's no cached data for it,
      the closed walled icon is displayed instead. This way, the user
      knows that there's to possibility to use the KWallet integration for the
      current page but that there's no cached data for it.
    • Yuri Chornoivan's avatar
      Fix minor typo · fd9ad10d
      Yuri Chornoivan authored
  17. 22 Aug, 2020 2 commits
    • 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
      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.
    • Script Kiddy's avatar
      SVN_SILENT made messages (.desktop file) - always resolve ours · 7e30b477
      Script Kiddy authored
      In case of conflict in i18n, keep the version of the branch "ours"
      To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
  18. 16 Aug, 2020 1 commit
  19. 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
      * 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.
  20. 13 Aug, 2020 1 commit
  21. 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
  22. 07 Aug, 2020 1 commit
    • Stefano Crocco's avatar
      Allow the user to choose how to open an URL from history when activating it · 48a0e965
      Stefano Crocco authored
      Previously, when the user double clicked an entry in the history dialog,
      the URL was opened in a new window, with no way to change this
      Now the user can configure what to do when activating an entry
      choosing from:
      - always open the URL in the current tab
      - always open the URL in a new tab
      - always open the URL in a new window
      - open the URL in a new tab unless the current tab has a konq: URL or an
        empty URL, in which cases open the URL in the current tab.
      This also changes the behaviour of the history dialog so that the entry
      is opened when it is activated, not double clicked.
      The user's choice is also honoured from the history sidebar module,
      except that the last option can't be used because (as far as I can see),
      the module can't access the current URL. In the sidebar module, this
      option is considered as if it were "always open in a new tab".
  23. 06 Aug, 2020 4 commits
  24. 05 Aug, 2020 1 commit
  25. 03 Aug, 2020 2 commits
  26. 01 Aug, 2020 2 commits