summaryrefslogtreecommitdiffstats
path: root/src/process
Commit message (Collapse)AuthorAgeFilesLines
* Adaptations for Chromium 66Allan Sandfeld Jensen2018-06-261-7/+7
| | | | | Change-Id: Iee88721a50036d4ef85a23dd1708d4fb84218708 Reviewed-by: Michal Klocek <michal.klocek@qt.io>
* Update export symbols for webenginecore moduleMichal Klocek2018-06-151-1/+1
| | | | | | | | | | | Use own WEBENGINECORE_EXPORT define, mark most headers private and use WEBENGINECORE_PRIVATE_EXPORT for it. For sanity, add "WARNING" as for private headers even though they are never installed. Change-Id: I523d28c1d00217f48bc63dabf138dd3a7eb482d4 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Separate argv for QCoreApplication and Chromium in WebEngineProcessKai Koehne2018-02-211-3/+25
| | | | | | | | | | | | | | | | On Linux, Chromium manipulates argv, merging all command line arguments into argv[0] and deleting the other arguments - see set_process_title_linux.cc for the glory details. This potentially confuses QCoreApplication::applicationDirPath(), which assumes that argv[0] contains the binary path. This in turn caused a regression in Qt 5.9.4 where resource files could not be located anymore for QtWebEngineProcess. Avoid this by making two distinct copies of argv already in main(). Task-number: QTBUG-66346 Change-Id: I24d103bb15e77db69faae3bcfc736df25e4ec5d3 Reviewed-by: Michal Klocek <michal.klocek@qt.io>
* Mark QtWebEngineProcess as compatible with Windows 10Kai Koehne2017-04-212-0/+19
| | | | | | | | | | | | | | This fixes ::GetVersionEx to report the actual Windows version, instead of always reporting Windows 8. Note though that this fixes only the renderer process - the manifest of the user process is beyond our control. Chromium currently uses the dynamic checks for Windows 10 to e.g. enable advanced sandboxing for ppapi, and scroll performance (see https://bugs.chromium.org/p/chromium/issues/detail?id=517183) Change-Id: I72870f31eac2074748b2c11a2b6cab9a03e62527 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Merge remote-tracking branch 'origin/5.7' into 5.8Allan Sandfeld Jensen2016-08-301-63/+1
|\ | | | | | | Change-Id: I82f7a6a6d1bf27dc8adf7e2a91ea8ab29c54a607
| * Fix sandboxing of localtime syscallAllan Sandfeld Jensen2016-08-191-63/+1
| | | | | | | | | | | | | | | | | | | | The check OS(LINUX) does not work here, so use the Qt OS defines, and remove the stat and fopen overrides that Chromium no longer proxies this way. Task-number: QTBUG-55125 Change-Id: Ie03b8e0cabd100f2f72b7ab1cff5dc8697ba69ad Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | Adjust webengine to the qtConfig() changes in qtbaseLars Knoll2016-08-231-3/+3
|/ | | | | Change-Id: I907f6ea73a1d707eda536764c4b0b2edea49a963 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix debug-only build on WindowsJoerg Bornemann2016-05-091-1/+1
| | | | | | | | | | Do not attempt to build the release version of QtWebEngineProcess if Qt is not configured for release. Task-number: QTBUG-53240 Change-Id: Iff52a5049b3eefdd52c405fb80095a4d53c55fba Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io> Reviewed-by: Michal Klocek <michal.klocek@theqtcompany.com>
* Provide a debug version of QtWebEngineProcessJoerg Bornemann2016-05-041-0/+2
| | | | | | | | | | | | | We never shipped a debug version of the QtWebEngineProcess executable. This is problematic in debug_and_release builds when a debug application starts the release version of QtWebEngineProcess. The Qt libraries will then be loaded twice, in debug and release. Also, in development setups where only the debug libraries are deployed, the release version of QtWebEngineProcess cannot be loaded. Task-number: QTBUG-49493 Change-Id: I2f7bfb9c7cf8e869dc91007f4e967a713f438065 Reviewed-by: Michael Brüning <michael.bruning@theqtcompany.com>
* Merge branch '5.6' into 5.7Allan Sandfeld Jensen2016-04-112-20/+15
|\ | | | | | | Change-Id: I53645ee5405b1c43807123fd3c196e314cfd1ce9
| * Use qt_app -> relative_qt_rpath for QtWebEngineProcess.Alexandru Croitor2016-03-241-15/+12
| | | | | | | | | | | | | | | | | | | | Use CONFIG+=relative_qt_rpath to make sure the web engine process contains a relative rpath instead of an absolute path rpath value. Change-Id: I5f3c9fb93273c41bed795aeba112f260382d2bf8 Task-number: QTBUG-50155 Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
| * Stop using QT_PRIVATE for QtWebEngineProcess in a non-framework build.Alexandru Croitor2016-03-241-4/+2
| | | | | | | | | | | | | | For executables, QT and QT_PRIVATE are the same. Change-Id: I8f8ef29aea6f4ebb3d7b6cd2f3bc6a3cbf83b0e4 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
| * Set CFBundleIdentifier for QtWebEngineProcess to a proper value.Alexandru Croitor2016-03-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | When QtWebEngineProcess bundle is created, the generated Info.plist CFBundleIdentifier contains the default dummy prefix added by qmake, namely: "com.yourcompany.QtWebEngineProcess". Make sure it uses the proper "org.qt-project.Qt" prefix. Change-Id: I8e060aeeeb8a53980139e790d3e3947752ffa1d3 Task-number: QTBUG-51942 Reviewed-by: Michael Brüning <michael.bruning@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-03-211-16/+2
|\| | | | | | | | | | | | | | | Conflicts: src/3rdparty src/webenginewidgets/doc/src/qwebenginepage_lgpl.qdoc Change-Id: I90728e965399e51b626d538924de955f9abab5fe
| * OS X: Fix QtWebEngineProcess @rpath handling so macdeployqt works.Alexandru Croitor2016-02-251-16/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QtWebengineProcess was built on OSX using frameworks, all linked frameworks were found using @executable_path, except for QtPositioning which still used @rpath, and the run path list did not contain an entry to point to the main app bundle frameworks directory. Make sure all frameworks use @rpath, and also add a run path value pointing to the main app bundle frameworks directory, so all frameworks can be found once deployed with macdeployqt. Change-Id: Ie25f4c15169bd608dd819294901c196a7d794f43 Task-number: QTBUG-50155 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com> Reviewed-by: Michael Brüning <michael.bruning@theqtcompany.com> Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com>
* | Unify license header usage.Jani Heikkinen2016-02-012-22/+28
|/ | | | | | | | | Update files using old header.LGPL3 to use header.LGPL Update files using old header.FLD to use new header.FDL Update files using old header.BSD to use new header.BSD Change-Id: I36a67aaa8c3ca6c7946308defc9c03c3571a7d23 Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
* Revert "Remove rpath workaround from QtWebProcess build."Michael Bruning2015-10-301-1/+16
| | | | | | | | | | | It does not work properly with the new rpath logic and causes problems with the installer packages. This should be a temporary fix until the rpath situation has been cleaned up again. This reverts commit 819279827a4ce05562909994468ec5604392c672. Change-Id: I082ba0118d410f90d202c786d07717bf224d5f70 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.5' into 5.6Liang Qi2015-10-283-0/+168
|\ | | | | | | | | | | | | Conflicts: src/3rdparty Change-Id: I49acdd9b5ca94f2807b0c13a97f508a67f1c5750
| * make the render process DPI-awareJoerg Bornemann2015-10-133-0/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | On Windows, system calls that retrieve screen properties (like GetSystemMetrics to get the size of a scroll bar button) are dependent on the DPI awareness setting of the calling process. The render process must use the same DPI awareness setting as the browser process. Retrieve the DPI awareness of the parent process in the render process and set it accordingly. Task-number: QTBUG-48380 Change-Id: Ic17d29d0f584e3cf230ac6ea2b08e3aa0d87ccdd Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
* | Remove rpath workaround from QtWebProcess build.Jake Petroules2015-09-061-17/+1
|/ | | | | | | | | This also fixes a runtime failure when building the webengine module independently (for example, where QtCore and QtWebEngine* frameworks are located in different directories). Change-Id: I801d74da0be495089bf552b85b507918684b9685 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
* Make QtWebEngineProcess use full 4 GiByte of memoryKai Koehne2015-08-031-0/+2
| | | | | | | | | | Pass /LARGEADDRESSAWARE the the MSVC linker to allow allocating more than two GiByte of memory for 32 bit. The flag is a NOOP for 64 bit. Task-number: QTBUG-47129 Change-Id: I82c4a7bc99e9042c4901425b37202d7977c0bcaa Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Peter Varga <pvarga@inf.u-szeged.hu>
* Deploy QtWebEngineProcess.exe at library executables path on WindowsPeter Varga2015-04-151-1/+2
| | | | | | | | | | Use the proper library executables path on Windows instead of the libexec. With this fix it is not necessary to set QTWEBENGINEPROCESS_PATH environment variable per default. Change-Id: I8cce07b8adbccc88b03c9cf942841eb1d4a5f176 Reviewed-by: Andras Becsi <andras.becsi@theqtcompany.com>
* Update copyright headersJani Heikkinen2015-02-161-7/+7
| | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Change-Id: Ieb6bac7a1be5c25eb7cb917495b58b6a870ca6d4 Reviewed-by: Pierre Rossi <pierre.rossi@theqtcompany.com>
* Ensure QtWebEngineProcess is built in release modeAndy Shaw2015-02-031-1/+1
| | | | | | | | | | If debug_and_release is set then QtWebEngineProcess should be built in release mode as it is a separate process and when it is deployed later it will be in the right mode already. Change-Id: I377baa20f01b70db91a7a1cec5f1014b44780546 Reviewed-by: Michael Brüning <michael.bruning@theqtcompany.com> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
* OSX: Don't show QtWebEngineProcess in the dockv5.4.0Jocelyn Turcotte2014-12-022-0/+25
| | | | | | | | | | | Set the LSUIElement key as Chromium does in its helper app's Info.plist to prevent seeing a jumping icon in the dock while the OS waits in vain for QtWebEngineProcess to create a window. Change-Id: I6c836621ec506fde04bc3825f64c49630a065351 Task-number: QTBUG-42955 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com> Reviewed-by: Andras Becsi <andras.becsi@theqtcompany.com>
* Use a relative install_name for QtWebEngineProcess' dependenciesv5.4.0-rc1Jocelyn Turcotte2014-11-201-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Until we can rely on Qt using @rpath on OSX, QtWebEngineProcess' dependencies must either be updated by macdeployqt when creating an .app bundle, either we must make that path relative at build time. Since QtWebEngineProcess.app is always deployed inside QtWebEngineCore.framework, we can safely assume that the dylib is always in a parent directory and that QtCore.framework can be found one directory higher. The additional dependencies of QtWebEngineCore.framework will be handled by the dynamic linker when it gets loaded, but this only works for QtWebEngineProcess when macdeployqt uses @loader_path instead of @executable_path (then relative to the application which is in a different directory than QtWebEngineProcess). This can be forced by passing a non-empty value for its -executable= command-line argument (e.g `macdeployqt Browser.app -executable=Browser.app/Contents/MacOS/Browser`) All this will be much simpler once we got Qt framework builds to use @rpath instead in a future minor version. Task-number: QTBUG-41611 Change-Id: Ied46c65a09f7033b622708da6e3d85855f9abf34 Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Deploy external data in QtWebEngineCore.framework for framework buildsJocelyn Turcotte2014-11-061-4/+12
| | | | | | | | | | | | | | | | | | | | | There is currently no convenient way to deploy QtWebEngine into an application bundle on OSX. macdeployqt copies frameworks into a .app bundle's Frameworks directory but this makes no sense unless all the needed files are also distributed with the bundle. This patch moves: - The ffmpegsumo.so library into Libraries/ - Locale .pak files, qtwebengine_resources.pak and icudtl.dat into Resources/ - QtWebEngineProcess into its own .app bundle, itself into Helpers/ QMAKE_BUNDLE_DATA is used to copy files into the bundle while INSTALLS is used when installing normally. A LOCALE_LIST is explicitly listed since QMAKE_BUNDLE_DATA can't handle the * glob to match all source files. Change-Id: I5c0df57b4b9e93f9cce34a74a6e024bf90d37b5c Task-number: QTBUG-41611 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com> Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Create a QCoreApplication in QtWebEngineProcess as well.Michael Brüning2014-09-301-0/+5
| | | | | | | | | | | | A QCoreApplication is needed in order to correctly load the configuration from qt.conf and setup the Qt environment variables accordingly. This is important to be able to deploy applications. This patch creates a dummy QCoreApplication in process main to have the environment setup correctly. Change-Id: If536b9edf357d5925fee02f2528872101139f87e Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Update License Headers for Qt WebEngine to LGPLv3.Zeno Albisser2014-08-211-15/+10
| | | | | | | Change-Id: Idbe0eafb51d77cc00e3a93179b81770724d5bfaa Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com> Reviewed-by: Tuukka Turunen <tuukka.turunen@digia.com> Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Add proxy functions for libc symbols to allow sandboxing.Zeno Albisser2014-04-241-0/+109
| | | | | | | | | | | | | | | | These functions override symbols exported by libc, such as fopen, localtime and similar and call the exported _override function in QtWebEngineCore. This code should live in an executable, but never in a library as it causes erratic behavior depending on the linking order. With this change we now also update the submodule shasum for the 3rdparty submodule to point to a commit that includes the patches for eLinux. Change-Id: I88f32c615181eefff2b38b374eed6f57c677d186 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com>
* Deploy QtWebEngineCore as a Qt moduleJocelyn Turcotte2014-03-071-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This delegates the linking step from ninja to qmake so that we can let qmake decide the destination of the target itself, easing the deployment and installation logic across platforms. The module is only deployed as a binary and no header are available outside of the source tree. This is only to make sure that the dependence of the QtWebEngine and QtWebEngineWidgets libraries on it is resolved at runtime exactly the same way as with other Qt modules, on all platforms. Ninja still takes care of the compilation and gyp lets qmake know how and what to link by dumping the list of flags and input files in a generated .pri file. This has to be done in a separate .pro file so that we can make sure that ninja is run inconditionally before make reaches the dependency check in core_module.pro, ensured by the parent Makefile. Note 1: This patch removes RPATH hacks that are no longer necessary Note 2: Other targets like ffmpegsumo are still linked by ninja. The same logic could be moved to a qmake file but this require some more work to make sure that some switches (e.g. -stdlib=libc++) are coordinated between gyp and qmake. Change-Id: If65968547bde5b9cf732e31e97931c17ae1921a7 Reviewed-by: Zoltan Arvai <zarvai@inf.u-szeged.hu> Reviewed-by: Andras Becsi <andras.becsi@digia.com>
* Fix the embedded buildAndras Becsi2014-02-051-1/+2
| | | | | | | | | | Adopt to toolchain changes and fix the build with the current snapshot. This patch adds some missing overrides and build system configurations. Change-Id: I488929500347bdb5a077ac14e9553cedfcaa605d Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
* Fix placement of webengine processSimon Hausmann2014-01-151-2/+2
| | | | | | | | | In developer (non-prefix) builds, the binary goes to $$MODULE_BASE_OUTDIR/libexec, which is practically qtbase/libexec. In prefix builds it'll be linked to $module_toplevel/libexec and installed into $prefix/libexec. Change-Id: Ia42519f3113976e707fbda9e09dbf7ef6e235924 Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
* Moving sources to src part 2: Adjust paths.Jocelyn Turcotte2013-11-281-1/+1
| | | | | | | | | | | | | | | | | | | NOTE: To build after this you should rerun init-repository.py or run $> git submodule sync $> git submodule update $> git config qtwebengine.chromiumsrcdir src/3rdparty This makes everything build by adjusting paths. Other mixed-in changes: - Rename qtwebengine_src variables in scripts to qtwebengine_root to avoid confusion. - Cleanup the release and debug extra targets that were in lib.pro. This file has also been split into src.pro and core.pro. Change-Id: Ieee9158a65f526b15244eaca59e779b7069d337e Reviewed-by: Zeno Albisser <zeno.albisser@digia.com> Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com>
* Moving sources to src part 1: Move files.Jocelyn Turcotte2013-11-282-0/+69
This only move files without adjusting any paths. This moves: - lib/quick -> src/webengine/api (API files) lib/quick -> src/webengine (other files) This contains the main QtWebEngine module library since <ec7b2ee70a8b2db7fb87f50671a001ddd54697b0>. - lib/widgets -> src/webenginewidgets Also rename this directory to match its module name and rename Api to api. - lib -> src/core - process -> src/process - resources -> src/core/resources - tools/* -> tools/scripts/ The build directory is spread as follow: - build/build.pro -> src/core/gyp_run.pro - build/qmake_extras/* -> src/core/ (for the host and target .pro files) - build/qmake -> tools/qmake - Build related scripts -> tools/buildscripts Change-Id: I0cded1de772c99c0c1da6536c9afea353236b4a1 Reviewed-by: Zeno Albisser <zeno.albisser@digia.com> Reviewed-by: Pierre Rossi <pierre.rossi@gmail.com> Reviewed-by: Andras Becsi <andras.becsi@digia.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 04:34:45 +0000