Redesign profile creation

Currently WebEngine offers the profile handling via QWebEngineProfile. Users can create private profile (off the record profile) using QWebEngineProfile() constructor or non private one using QWebEngineProfile(QString). This unfortunately does not work well since every non private profile requires unique storage path, moreover this path has to be unique cross application wise. Therefore, some way of locking the storage path must be implemented to avoid the data corruption and possible crashes. This has to be enforced by the api , therefore there should be a way to inform user that creation of QWebEngineProfile(QString) failed. Moreover QWebengine uses the default profile which is by default non private and uses 'Default' storage path.

To deal with the issue we can:

1. Deprecate all setters in QWebEngineProfile and introduce QWebEngineProfileBuilder

QWebEngineProfileBuilder builder;

builder.setOffTheRecord(false)
builder.setCachePath(....)
builder.setStoragePath(...)
....
const QWebEngineProfile *profile = builder.create()
if (!profile) {
    qDebug() bulder.error() << builder.errorsString()
}

pros: looks simple, the private browsing always opens new tab in browsers -> profile should be just const or ?
cons: still the issue how to handle failed default profile, always offTheRecord ? qml ?

2. Add setter setOffTheRecord() ,error() errorString() to QWebEngineProfile

QWebEngine profile("Test")
if (profile.error() {
 qDebug()<<"Could not create Test profile , created offTheRecord profile instead"
}
profile.setStorageName("Test1)
profile.setOffTheRecord(false);

pros: fixes issue of creation of default profile -> in case of failure it is offTheRecord, but can be changed later
cons: requires recreation of browser context adapter , the chromium part is not designed for non const profiles.

3. Introduce new clases QWebEnginePrivateProfileNewName , QWebEngineProfileNewName.

QWebEngineProfile/NewName derives from QWebEnginePrivateProfile/NewName

Both classes have factory method which locks storage location

pros: looks simple , QWebEnginePrivateProfile has only const methods , QWebEngineProfile still could keep the setters
cons: dumps old classes

4. Make one off the record profile -> globalProfile , add factory method QWebEngineProfile to create custom profiles

--------------------------------------------------------------------------------------------------------------------------------------------------------

Some latest thoughts about the issue (as of Jun 21) in case this idea needs restore.

• c++ builder could be in form of:

  class Q_WEBENGINECORE_EXPORT QWebEngineProfileBuilder {
  public:
      QWebEngineProfile* create(QObject *parent = nullptr);
      QWebEngineProfile* create(const QString &storageName, QObject *parent = nullptr);
      void setPersistentStoragePath(const QString &path);
      void setCachePath(const QString &path);
      void setHttpUserAgent(const QString &userAgent);
      void setHttpCacheType(QWebEngineProfile::HttpCacheType);
      void setHttpAcceptLanguage(const QString &httpAcceptLanguage);
      void setPersistentCookiesPolicy(QWebEngineProfile::PersistentCookiesPolicy);
      void setHttpCacheMaximumSize(int maxSize);
  private:
      Q_DISABLE_COPY(QWebEngineProfileBuilder)
      Q_DECLARE_PRIVATE(QWebEngineProfileBuilder)
      QScopedPointer<QWebEngineProfileBuilderPrivate> d_ptr;
  };
  

  We drop error() , since it is up to user to make sure profiles are unique and do version checkups. We remove storage setters from profiles.

• for qml we do not need builder or creator patterns , we could simply create profile when things gets parsed (on parser complete), and make one-time-set only storage values , in case user tries later to reset the value the warning is logged (so the same way as location map plugin setup works), this way we do not need any api changes.