Re: RFR: 8268915: WebKit build fails with Xcode 12.5
On Thu, 17 Jun 2021 14:52:53 GMT, Kevin Rushforth wrote: > The JavaFX WebKit build fails with Xcode 12.5 + MacOS 11.3 SDK. This is > related to the added C++20 support where some of the system include files now > do `#include `. Because the macOS file system is case insensitive, > it matches a file named `VERSION` in the sqlite source directory. That file > is just a plain text file (not used by our build at all) so the fix is to > rename it to `VERSION.txt`. I've done a CI build on all three platforms. > @jgneff has verified that renaming this file fixes the build for XCode 12.5. Fix looks good. - Marked as reviewed by ajoseph (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/535
Integrated: 8267858: Document that title property in WebEngine gets updated asynchronously
On Thu, 27 May 2021 17:25:27 GMT, Arun Joseph wrote: > The title property is not guaranteed to be updated right after the page is > loaded, but gets updated asynchronously. This pull request has now been integrated. Changeset: ca250364 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/ca250364aae7a4e071d307ac1091c22776cf9a38 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8267858: Document that title property in WebEngine gets updated asynchronously Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/522
Re: RFR: 8267858: Document that title property in WebEngine gets updated asynchronously
On Thu, 3 Jun 2021 23:53:48 GMT, Kevin Rushforth wrote: >> modules/javafx.web/src/main/java/javafx/scene/web/WebEngine.java line 441: >> >>> 439: >>> 440: /* >>> 441: * The page title. This gets updated asynchronously. >> >> Is there any more information or guarantee when the update is expected to be >> complete, or is it truly asynchronous? I we know that this will happen >> between the current pulse and the next one, that might be helpful to >> developers (although I agree waiting for the titleProperty to be changed is >> the better approach). >> If there is no link beween the webkit thread that gets the title and the >> quantum renderer, it is really asynchronous and in that case tricks like >> waiting for a few pulses won't help either -- but it would be good to >> mention that so that developers don't create workarounds that might work in >> some cases and fail in others. > > I had exactly the same thought about the need to document it more clearly. > Maybe something like: > > "This property will be updated asynchronously some time after the page is > loaded. Applications should not rely on any particular timing, but should > listen for changes to this property, or bind to it, to know when it has been > updated." > > Btw, you modified an ordinary comment, not a javadoc comment. The newly added > sentence needs to go on the javadoc comment, which is on the `titleProperty` > method a few lines down from here. Be sure to run `gradle javadoc` and look > at the generated docs. I've modified the right javadoc comment now. - PR: https://git.openjdk.java.net/jfx/pull/522
RFR: 8267858: Document that title property in WebEngine gets updated asynchronously
The title property is not guaranteed to be updated right after the page is loaded, but gets updated asynchronously. - Commit messages: - Fix javadoc comment - Merge branch 'master' into 8267858 - 8267858: Document that title property in WebEngine gets updated asynchronously Changes: https://git.openjdk.java.net/jfx/pull/522/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=522=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267858 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/522.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/522/head:pull/522 PR: https://git.openjdk.java.net/jfx/pull/522
Integrated: 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest
On Wed, 12 May 2021 13:18:25 GMT, Arun Joseph wrote: > The system test test.com.sun.webkit.LocalStorageAccessTest fails on Windows > as mentioned in > [JDK-8265661](https://bugs.openjdk.java.net/browse/JDK-8265661). We should > skip this test until it is fixed. This pull request has now been integrated. Changeset: 389e8c04 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/389e8c04c42bbc19eebbade69ed175c7e56cf65d Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/497
RFR: 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest
The system test test.com.sun.webkit.LocalStorageAccessTest fails on Windows as mentioned in [JDK-8265661](https://bugs.openjdk.java.net/browse/JDK-8265661). We should skip this test until it is fixed. - Commit messages: - 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest Changes: https://git.openjdk.java.net/jfx/pull/497/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=497=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266968 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/497.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/497/head:pull/497 PR: https://git.openjdk.java.net/jfx/pull/497
Integrated: 8262276: Debug build of WebKit fails
On Thu, 4 Mar 2021 06:41:53 GMT, Arun Joseph wrote: > Fixing the Debug build of WebKit. > > Test: Build JavaFX using `-PCOMPILE_WEBKIT=true -PCONF=DebugNative` and test > using a simple HelloWebView app. This pull request has now been integrated. Changeset: ed080c82 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/ed080c82 Stats: 34 lines in 6 files changed: 21 ins; 0 del; 13 mod 8262276: Debug build of WebKit fails Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/417
Re: RFR: 8265469: Allow to build media and webkit for Linux-AArch64 [v2]
On Fri, 23 Apr 2021 09:04:47 GMT, Johan Vos wrote: >> Changes that allow to build linux configuration on Linux AArch64 >> This PR introduces an `IS_AARCH64` parameter in build.gradle. >> This PR already contains the change from PR #465 so if this one gets >> integrated, that change needs to removed from this PR. > > Johan Vos has updated the pull request incrementally with one additional > commit since the last revision: > > remove classifier as per reviewer comment Marked as reviewed by ajoseph (Committer). - PR: https://git.openjdk.java.net/jfx/pull/467
Re: RFR: 8265469: Allow to build media and webkit for Linux-AArch64
On Mon, 19 Apr 2021 19:57:50 GMT, Johan Vos wrote:
> Changes that allow to build linux configuration on Linux AArch64
> This PR introduces an `IS_AARCH64` parameter in build.gradle.
> This PR already contains the change from PR #465 so if this one gets
> integrated, that change needs to removed from this PR.
Other than that, the changes looks good.
build.gradle line 3465:
> 3463: def webkitProperties = targetProperties.webkit
> 3464: def classifier = (t.name != "linux" && t.name != "win") ?
> t.name :
> 3465: IS_64 ? IS_AARCH64 ? "${t.name}-aarch64" :
> "${t.name}-amd64" : "${t.name}-i586"
I don't think this change is necessary as `classifier` was used for
webview-deps, and it's not used anymore (removed in
https://github.com/openjdk/jfx/commit/bf203ad716633e8c9f23a70448fac1ed580a7fb5).
This `classifier` definition can also be removed.
-
PR: https://git.openjdk.java.net/jfx/pull/467
Re: RFR: 8262276: Debug build of WebKit fails [v3]
> Fixing the Debug build of WebKit. > > Test: Build JavaFX using `-PCOMPILE_WEBKIT=true -PCONF=DebugNative` and test > using a simple HelloWebView app. Arun Joseph has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge - Fix InternalFunction crash - 8262276: Debug build of WebKit fails - Changes: https://git.openjdk.java.net/jfx/pull/417/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=417=02 Stats: 34 lines in 6 files changed: 21 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/417.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/417/head:pull/417 PR: https://git.openjdk.java.net/jfx/pull/417
Integrated: 8263788: JavaFX application freezes completely after some time when using the WebView
On Mon, 12 Apr 2021 13:10:53 GMT, Arun Joseph wrote: > Issue: Java application (with WebView) will completely freeze after using it > for a while. > > Fix: Use native isMainThread functions instead of JNI call. This pull request has now been integrated. Changeset: 49d2126e Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/49d2126e Stats: 38 lines in 3 files changed: 15 ins; 18 del; 5 mod 8263788: JavaFX application freezes completely after some time when using the WebView Reviewed-by: kcr, ghb - PR: https://git.openjdk.java.net/jfx/pull/461
Re: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v3]
On Thu, 15 Apr 2021 16:43:08 GMT, Matthias Bläsing wrote: >> The functions from FileSystemJava are called from different threads the >> root problem manifests because the JNI FindClass function behaves >> differently when called from a context that is the ancestor of a java >> frame compared to when called in isolation. >> >> A segmentation fault is observed when local storage of a webview is >> accessed. At that time a new native thread is spun up and that sets up >> the local storage, by calling into the JVM via >> WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is >> invoked to get a referenc to the java implementation of the FileSystem. >> As this is is called from a new native thread (no java context >> available), JNI uses the system classloader to locate the class. This >> fails if the JavaFX modules are not on the boot module/class path. >> >> Instead on relying on fetching the class reference everytime it is >> needed, this change fetches it once when the JavaFX library is loaded >> and stores it in the WTF namespace. >> >> In addition to this it was observed, that there is no attachment to the >> JVM done when calling into the filesystem. No fault was observed, but >> the JNI specs indicate, that the JNIEnv interface is only valid when >> attached. > > Matthias Bläsing has updated the pull request incrementally with one > additional commit since the last revision: > > Review fix: Use correct bug id The test and changes looks good. - Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/458
Re: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView
On Thu, 15 Apr 2021 23:41:02 GMT, Kevin Rushforth wrote:
>> Issue: Java application (with WebView) will completely freeze after using it
>> for a while.
>>
>> Fix: Use native isMainThread functions instead of JNI call.
>
> modules/javafx.web/src/main/native/Source/WTF/wtf/java/MainThreadJava.cpp
> line 45:
>
>> 43: #elif OS(WINDOWS)
>> 44: static ThreadIdentifier mainThread { 0 };
>> 45: #endif
>
> Both here and below, where the `isMainThread` is defined, assume that `UNIX`
> and `WINDOWS` are the only two options. I presume this is a valid assumption?
I've tested in all three platforms. The two options are sufficient as Mac and
Linux uses `pthread`.
-
PR: https://git.openjdk.java.net/jfx/pull/461
RFR: 8263788: JavaFX application freezes completely after some time when using the WebView
Issue: Java application (with WebView) will completely freeze after using it for a while. Fix: Use native isMainThread functions instead of JNI call. - Commit messages: - Remove platform check in ThreadingWin - Remove fwkIsMainThread - 8263788: JavaFX application freezes completely after some time when using the WebView Changes: https://git.openjdk.java.net/jfx/pull/461/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=461=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263788 Stats: 38 lines in 3 files changed: 15 ins; 18 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/461.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/461/head:pull/461 PR: https://git.openjdk.java.net/jfx/pull/461
Re: OpenJFX custom build - Java application crash (semi-related to 8262276)
I’m marking the PR (https://github.com/openjdk/jfx/pull/461) as ready for review. You can add your evaluation in the PR. — Arun Joseph
Re: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2]
On Fri, 9 Apr 2021 21:10:46 GMT, Matthias Bläsing wrote: >> The functions from FileSystemJava are called from different threads the >> root problem manifests because the JNI FindClass function behaves >> differently when called from a context that is the ancestor of a java >> frame compared to when called in isolation. >> >> A segmentation fault is observed when local storage of a webview is >> accessed. At that time a new native thread is spun up and that sets up >> the local storage, by calling into the JVM via >> WTF::FileSystem::makeAllDirectories. At that point GetFileSystemClass is >> invoked to get a referenc to the java implementation of the FileSystem. >> As this is is called from a new native thread (no java context >> available), JNI uses the system classloader to locate the class. This >> fails if the JavaFX modules are not on the boot module/class path. >> >> Instead on relying on fetching the class reference everytime it is >> needed, this change fetches it once when the JavaFX library is loaded >> and stores it in the WTF namespace. >> >> In addition to this it was observed, that there is no attachment to the >> JVM done when calling into the filesystem. No fault was observed, but >> the JNI specs indicate, that the JNIEnv interface is only valid when >> attached. > > Matthias Bläsing has updated the pull request incrementally with one > additional commit since the last revision: > > Revert changes to thread attachment introduced in second commit > > Thread attachment is handled in > > jfx/modules/javafx.web/src/main/native/Source/WebKitLegacy/Storage/StorageThread.cpp > and thus does not need to be modified. tests/system/src/test/java/test/com/sun/webkit/LocalStorageAccessTest.java line 36: > 34: /** > 35: * @test > 36: * @bug 9069811 The changes looks good. The bug id is not modified at this point. - PR: https://git.openjdk.java.net/jfx/pull/458
Re: [External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276)
I think the issue is caused by the JNI call in isMainThread() function in MainThreadJava.cpp and one solution would be to use the respective native calls for each platforms. I’ll create a PR with the above fix shortly after performing a couple of sanity checks. — Arun Joseph On 12-Apr-2021, at 1:29 PM, Primož Kokol mailto:primoz.ko...@gmail.com>> wrote: Did the thread dump created using the debug build helped with understanding of what the issue was? — PrimosK On Tue, 23 Mar 2021 at 18:53, Arun Joseph mailto:arun.aj.jos...@oracle.com>> wrote: The thread dump doesn’t have enough details to locate where the problem occurs. Using a debug build with assertions disabled (as mentioned in the previous mail) may help in generating a thread dump for getting some more information. — Arun Joseph On 18-Mar-2021, at 3:39 PM, Primož Kokol mailto:primoz.ko...@gmail.com>> wrote: Thanks for pointing us in the right direction. I wasn't aware that jfxwebkit.pdb will be generated also in the case of a production build. So after generating a production build we were able to produce a thread dump (using jfxwebkit.pdb symbols) at the time when the application freezes. The complete bug report including thread dump is there: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263788<https://urldefense.com/v3/__https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263788__;!!GqivPVa7Brio!PNGdt-6i1OVlO2wDGTAtrKqpYpUwAwVhSlCnjD5ZDMFBKT5TzscS2TxfNzhFNz_rHv8-$> Could you please just scan through it and let us know whether there is enough information to pursue this further or whether any additional information is needed? — PrimosK On Tue, 16 Mar 2021 at 13:30, Arun Joseph mailto:arun.aj.jos...@oracle.com>> wrote: The app is now crashing at InternalFunction which calls jsDynamicCast in JSCast.h, which lead to the initial crash. This assert failure occurs because the type value is ObjectType instead of InternalFunctionType or NullSetterFunctionType. I need to check why this is happens. NDEBUG and ASSERT_ENABLED are used interchangeably in the WebKit code. So, for creating a build without asserts, you can either use the release build PDBs, or set NDEBUG to 1 in WTF/wtf/PlatformEnable.h to generate a minimal debug build. — Arun Joseph On 15-Mar-2021, at 6:08 PM, Primož Kokol mailto:primoz.ko...@gmail.com>> wrote: I've tried to remove this particular assert statement at "JSCast.h:143": // ASSERT_UNUSED(vm, canCast == from->JSCell::inherits(vm, Target::info())); ... and now application crashes at different assert statement: > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const > char * __formal, int __formal) Line 672 C++ Symbols loaded. jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const WTF::String & name, JSC::InternalFunction::NameAdditionMode nameAdditionMode) Line 49 C++ Symbols loaded. jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const WTF::String & ident) Line 58 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, const WTF::String & name) Line 231 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * globalObject, const WTF::String & name, JSC::Bindings::Method * method) Line 212 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) Line 124 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ Symbols loaded. jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, JSC::JSValue baseValue, const JSC::Identifier & ident, JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const JSC::Instruction * pc) Line 833 C++ Symbols loaded. jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. 0025dabfaf00() Unknown Non-user code 0025dabfafc0() Unknown Non-user code 0164ca445b4b() Unknown Non-user code () Unknown Non-user code 0164ca445b46() Unknown Non-user code Is there any way we could turn off assertions in general when producing debug build? On Sat, 13 Mar 2021 at 05:41, A
Integrated: 8260245: Update ICU4C to version 68.2
On Mon, 5 Apr 2021 18:14:36 GMT, Arun Joseph wrote: > We currently use ICU4C version 64.2. We should update to the latest stable > version 68.2. > http://site.icu-project.org/home This pull request has now been integrated. Changeset: 808b1078 Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/808b1078 Stats: 45773 lines in 673 files changed: 24665 ins; 8082 del; 13026 mod 8260245: Update ICU4C to version 68.2 8232379: Need to remove large icudt64l.zip binary file from source repository Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/456
Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3]
On Sun, 4 Apr 2021 16:36:27 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives >> or the `jmod` tool itself has the required support. For more information on >> the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more >> information on the command to recreate the JMOD files, see the >> [`strip-nondeterminism`][2] repository. I'd like to propose that we allow >> for reproducible builds in JavaFX 17 and consider making them the default in >> JavaFX 18. >> >> Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module >> stores the time of the build. Furthermore, for builds that don't run on the >> Hudson continuous integration tool, the class adds the build time to the >> system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned >> by the file system. The native shared libraries also store their object >> files in the order returned by the file system. Most file systems, though, >> do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics >> module stores the absolute path of its `.css` input file in the >> corresponding `.bss` output file, which is then included in the JavaFX >> Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the >> first three sources of non-determinism. A later pull request can modify the >> Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request incrementally with one additional > commit since the last revision: > > Include WebKit shared library for Windows > > Enable reproducible builds of the native WebKit shared library for > Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. Changes looks good. Verified the build on all 3 platforms. - Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/446
Re: RFR: 8260245: Update ICU4C to version 68.2 [v2]
> We currently use ICU4C version 64.2. We should update to the latest stable > version 68.2. > http://site.icu-project.org/home Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Add icuVersion - Changes: - all: https://git.openjdk.java.net/jfx/pull/456/files - new: https://git.openjdk.java.net/jfx/pull/456/files/c66fbd74..351e02b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=456=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=456=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/456.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/456/head:pull/456 PR: https://git.openjdk.java.net/jfx/pull/456
Re: RFR: 8260245: Update ICU4C to version 68.2
On Mon, 5 Apr 2021 19:09:19 GMT, Kevin Rushforth wrote: >> We currently use ICU4C version 64.2. We should update to the latest stable >> version 68.2. >> http://site.icu-project.org/home > > Overall this looks good. I'll review / test it in detail later. > > Quick comments on the PR: > > 1. You need to update the version number in `.../legal/icu_web.md` > 2. Related to the above, can you create a new `UPDATING.txt` file in > `.../native/Source/ThirdParty/icu` with instructions as to what needs to be > updated when updating to a new ICU version, specifically including the > changes to `build.gradle`, `.../legal/icu_web.md`, and > `/native/Source/ThirdParty/icu/CMakeLists.txt` regarding updating the version > number, along with anything else that isn't obvious (although I think the > rest is straight-forward)? > 3. Will the changes in core WebKit code (e.g., `TRUE` --> `true`) cause merge > conflicts in the future? > > Also, since this also addresses > [JDK-8232379](https://bugs.openjdk.java.net/browse/JDK-8232379), can you add > it to this PR with `/issue add 8232379`? The other WebKit changes are present in the upstream repo as well (https://bugs.webkit.org/show_bug.cgi?id=218522). - PR: https://git.openjdk.java.net/jfx/pull/456
RFR: 8260245: Update ICU4C to version 68.2
We currently use ICU4C version 64.2. We should update to the latest stable version 68.2. http://site.icu-project.org/home - Commit messages: - Add UPDATING.txt file - Update license - Modify exec files - Add icudt68l repo - Remove icudt file - 8260245: Update ICU4C to version 68.2 Changes: https://git.openjdk.java.net/jfx/pull/456/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=456=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260245 Stats: 45770 lines in 673 files changed: 24662 ins; 8082 del; 13026 mod Patch: https://git.openjdk.java.net/jfx/pull/456.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/456/head:pull/456 PR: https://git.openjdk.java.net/jfx/pull/456
Integrated: 8259555: Webkit crashes on Apple Silicon
On Fri, 2 Apr 2021 15:37:38 GMT, Arun Joseph wrote: > WebKit crashes during JavaScriptCore initialization code for Apple Silicon. This pull request has now been integrated. Changeset: b2f842de Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/b2f842de Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8259555: Webkit crashes on Apple Silicon Co-authored-by: Peter Zhelezniakov Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/452
RFR: 8259555: Webkit crashes on Apple Silicon
WebKit crashes during JavaScriptCore initialization code for Apple Silicon. - Commit messages: - 8259555: Webkit crashes on Apple Silicon Changes: https://git.openjdk.java.net/jfx/pull/452/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=452=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259555 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/452.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/452/head:pull/452 PR: https://git.openjdk.java.net/jfx/pull/452
Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
On Thu, 1 Apr 2021 17:33:35 GMT, Kevin Rushforth wrote: >> The WebKit build is complicated (to say the least). All of the WebKit >> components, including the additional third-party dependencies in >> `/Source/ThirdParty`, are built using cmake. I think any changes would >> involve passing flags to cmake in `build.gradle`. >> >> @arun-Joseph might be able to comment on that. > > I should add that if changes are needed to the `Makefile.msvc` files to > accept extra link flags to be passed in, then it would be fine to modify them. It would be better to add the flag in `libxml/CMakeLists.txt` or in `build.gradle` via `cmakeArgs`. - PR: https://git.openjdk.java.net/jfx/pull/446
Re: RFR: 8262276: Debug build of WebKit fails [v2]
> Fixing the Debug build of WebKit. > > Test: Build JavaFX using `-PCOMPILE_WEBKIT=true -PCONF=DebugNative` and test > using a simple HelloWebView app. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Fix InternalFunction crash - Changes: - all: https://git.openjdk.java.net/jfx/pull/417/files - new: https://git.openjdk.java.net/jfx/pull/417/files/6cab829e..31ea28c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=417=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=417=00-01 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/417.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/417/head:pull/417 PR: https://git.openjdk.java.net/jfx/pull/417
Re: [External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276)
The thread dump doesn’t have enough details to locate where the problem occurs. Using a debug build with assertions disabled (as mentioned in the previous mail) may help in generating a thread dump for getting some more information. — Arun Joseph On 18-Mar-2021, at 3:39 PM, Primož Kokol mailto:primoz.ko...@gmail.com>> wrote: Thanks for pointing us in the right direction. I wasn't aware that jfxwebkit.pdb will be generated also in the case of a production build. So after generating a production build we were able to produce a thread dump (using jfxwebkit.pdb symbols) at the time when the application freezes. The complete bug report including thread dump is there: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263788<https://urldefense.com/v3/__https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263788__;!!GqivPVa7Brio!PNGdt-6i1OVlO2wDGTAtrKqpYpUwAwVhSlCnjD5ZDMFBKT5TzscS2TxfNzhFNz_rHv8-$> Could you please just scan through it and let us know whether there is enough information to pursue this further or whether any additional information is needed? — PrimosK On Tue, 16 Mar 2021 at 13:30, Arun Joseph mailto:arun.aj.jos...@oracle.com>> wrote: The app is now crashing at InternalFunction which calls jsDynamicCast in JSCast.h, which lead to the initial crash. This assert failure occurs because the type value is ObjectType instead of InternalFunctionType or NullSetterFunctionType. I need to check why this is happens. NDEBUG and ASSERT_ENABLED are used interchangeably in the WebKit code. So, for creating a build without asserts, you can either use the release build PDBs, or set NDEBUG to 1 in WTF/wtf/PlatformEnable.h to generate a minimal debug build. — Arun Joseph On 15-Mar-2021, at 6:08 PM, Primož Kokol mailto:primoz.ko...@gmail.com>> wrote: I've tried to remove this particular assert statement at "JSCast.h:143": // ASSERT_UNUSED(vm, canCast == from->JSCell::inherits(vm, Target::info())); ... and now application crashes at different assert statement: > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const > char * __formal, int __formal) Line 672 C++ Symbols loaded. jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const WTF::String & name, JSC::InternalFunction::NameAdditionMode nameAdditionMode) Line 49 C++ Symbols loaded. jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const WTF::String & ident) Line 58 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, const WTF::String & name) Line 231 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * globalObject, const WTF::String & name, JSC::Bindings::Method * method) Line 212 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) Line 124 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ Symbols loaded. jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, JSC::JSValue baseValue, const JSC::Identifier & ident, JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const JSC::Instruction * pc) Line 833 C++ Symbols loaded. jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. 0025dabfaf00() Unknown Non-user code 0025dabfafc0() Unknown Non-user code 0164ca445b4b() Unknown Non-user code () Unknown Non-user code 0164ca445b46() Unknown Non-user code Is there any way we could turn off assertions in general when producing debug build? On Sat, 13 Mar 2021 at 05:41, Arun Joseph mailto:arun.aj.jos...@oracle.com>> wrote: I’m currently looking into why the native debug build is crashing. This same assert fails while running FileReaderTest using the native debug build. For the time being, you can try building by removing this particular assert statement for debugging. — Arun Joseph > On 12-Mar-2021, at 11:47 PM, Primož Kokol > mailto:primoz.ko...@gmail.com>> wrote: > > Hi Kevin, > > Unfortunately I don't have a test case. We are using various WebViews in > our production application hence we
Re: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v5]
On Sat, 20 Mar 2021 13:40:51 GMT, Kevin Rushforth wrote: >> This is a fix for a long-standing bug where the D3D pipeline will stop >> rendering when a Windows remote desktop session is disconnected and then >> reconnected. >> >> A preliminary Draft PR #315 by @Schmidor was a good first step in solving >> this. I took that and continued the work in my Draft PR #403. It is now >> ready for formal review in this new PR. You can see PR #403 for details on >> the history of the changes. >> >> ## Evaluation >> >> The root cause of this bug is that the D3D pipeline did not handle a return >> code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error >> occurs, an application needs to destroy and recreate the Direct3D device. >> >> The solution is to implement a new `D3DPipeline::reinitialize` method that >> will destroy the native D3D device and dispose the existing ResourceFactory >> objects and their associated BaseContext objects upon receiving >> `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is >> not recreated (it remains a singleton). In support of this, I implemented >> proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean >> everything up and also to avoid memory leaks. >> >> Additionally, there were several places that assumed that some textures (and >> mesh vertices) could be made permanent and never need to handle the case of >> a lost device. These all had to be fixed to allow for the possibility of a >> lost device and associated resource factory. They included: >> >> * UploadingPainter and PresentingPainter need to set the resource factory to >> null when not ready, so it will get the (possibly new) factory the next time >> it tries. >> * The gradient texture cache in `PaintHelper` has to be cleared and >> recreated when the surface is lost >> * The 3D triangle mesh and Phong material classes need to be disposed when >> the resource factory is disposed. >> * WebView often renders to a texture image at a time other than from the >> main rendering job, so needs to directly handle the case of a resource >> factory that is lost. >> * Decora PPSRenderer assumed that the resource factory never went away; it >> also accessed it on the wrong thread. Both problems were addressed by >> deferring the initialization of the resource factory and handling the case >> where the device is disposed. >> * Snapshot needs to allow for the platform image to be null if the device >> has been disposed. >> >> ## Notes to Reviewers >> >> I created this PR from a branch that contains the original 4 commits by >> @Schmidor (rebased on top of the current `master`) and then a single commit >> on top of that to complete it. This allows anyone who is interested to >> easily see the diffs between this PR and Oliver's original Draft PR. Most >> reviewers can just go to the list of "Files" and see the aggregate diffs. >> >> During the course of my testing I discovered three outstanding problems, >> which will be handled by filing follow-up issues. Once I file them, I'll add >> a comment to this PR with the bug IDs. >> >> 1. Media: a media stream playing at the time of a reconnect doesn't continue >> playing. Reloading the media works fine. This is not directly related to >> this bug, since it also happens with the software pipeline. >> 2. Canvas: doesn't preserve the contents after a device reconnect (noticed >> while running Zoomy, where the BG color is wrong after device >> reinitialization). This might point to a need to let the app know they have >> to repaint, since there is no possible way to preserve the contents of the >> texture when the device is lost. >> 3. WebView: there is a possible memory leak when device isn't ready after >> first reset, due to a `WCRenderQueueImpl::gc` instance being held in a >> JNIGlobal. This looks like a preexisting condition that could happen with a >> page (re)load today. It happens rarely. >> >> This is a complicated enough change that I'd like three reviewers. The bulk >> of the changes are Windows-specific, but there are changes in common code so >> at least a sanity check needs to be done on all platforms using both the HW >> and SW pipelines. The case of a disposed device can currently only happen on >> Windows with the D3D pipeline. > > Kevin Rushforth has updated the pull request incrementally with one > additional commit since the last revision: > > Address review comments to fix typo in comment Fix looks good. Tested WebView by reconnecting via remote desktop. - Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/430
Re: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v4]
On Fri, 19 Mar 2021 12:08:04 GMT, Kevin Rushforth wrote:
>> This is a fix for a long-standing bug where the D3D pipeline will stop
>> rendering when a Windows remote desktop session is disconnected and then
>> reconnected.
>>
>> A preliminary Draft PR #315 by @Schmidor was a good first step in solving
>> this. I took that and continued the work in my Draft PR #403. It is now
>> ready for formal review in this new PR. You can see PR #403 for details on
>> the history of the changes.
>>
>> ## Evaluation
>>
>> The root cause of this bug is that the D3D pipeline did not handle a return
>> code of `D3DERR_DEVICEREMOVED` from `TestCooperativeLevel`. When that error
>> occurs, an application needs to destroy and recreate the Direct3D device.
>>
>> The solution is to implement a new `D3DPipeline::reinitialize` method that
>> will destroy the native D3D device and dispose the existing ResourceFactory
>> objects and their associated BaseContext objects upon receiving
>> `D3DERR_DEVICEREMOVED`. Note that the `D3DPipeline` Java object singleton is
>> not recreated (it remains a singleton). In support of this, I implemented
>> proper disposal logic in `BaseResourceFactory` and `BaseContext` to clean
>> everything up and also to avoid memory leaks.
>>
>> Additionally, there were several places that assumed that some textures (and
>> mesh vertices) could be made permanent and never need to handle the case of
>> a lost device. These all had to be fixed to allow for the possibility of a
>> lost device and associated resource factory. They included:
>>
>> * UploadingPainter and PresentingPainter need to set the resource factory to
>> null when not ready, so it will get the (possibly new) factory the next time
>> it tries.
>> * The gradient texture cache in `PaintHelper` has to be cleared and
>> recreated when the surface is lost
>> * The 3D triangle mesh and Phong material classes need to be disposed when
>> the resource factory is disposed.
>> * WebView often renders to a texture image at a time other than from the
>> main rendering job, so needs to directly handle the case of a resource
>> factory that is lost.
>> * Decora PPSRenderer assumed that the resource factory never went away; it
>> also accessed it on the wrong thread. Both problems were addressed by
>> deferring the initialization of the resource factory and handling the case
>> where the device is disposed.
>> * Snapshot needs to allow for the platform image to be null if the device
>> has been disposed.
>>
>> ## Notes to Reviewers
>>
>> I created this PR from a branch that contains the original 4 commits by
>> @Schmidor (rebased on top of the current `master`) and then a single commit
>> on top of that to complete it. This allows anyone who is interested to
>> easily see the diffs between this PR and Oliver's original Draft PR. Most
>> reviewers can just go to the list of "Files" and see the aggregate diffs.
>>
>> During the course of my testing I discovered three outstanding problems,
>> which will be handled by filing follow-up issues. Once I file them, I'll add
>> a comment to this PR with the bug IDs.
>>
>> 1. Media: a media stream playing at the time of a reconnect doesn't continue
>> playing. Reloading the media works fine. This is not directly related to
>> this bug, since it also happens with the software pipeline.
>> 2. Canvas: doesn't preserve the contents after a device reconnect (noticed
>> while running Zoomy, where the BG color is wrong after device
>> reinitialization). This might point to a need to let the app know they have
>> to repaint, since there is no possible way to preserve the contents of the
>> texture when the device is lost.
>> 3. WebView: there is a possible memory leak when device isn't ready after
>> first reset, due to a `WCRenderQueueImpl::gc` instance being held in a
>> JNIGlobal. This looks like a preexisting condition that could happen with a
>> page (re)load today. It happens rarely.
>>
>> This is a complicated enough change that I'd like three reviewers. The bulk
>> of the changes are Windows-specific, but there are changes in common code so
>> at least a sanity check needs to be done on all platforms using both the HW
>> and SW pipelines. The case of a disposed device can currently only happen on
>> Windows with the D3D pipeline.
>
> Kevin Rushforth has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Address review comments to fix typos, naming
modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCPageBackBufferImpl.java
line 126:
> 124: firstValidate = false;
> 125: } else {
> 126: // texture must have been nullified in factoryReset() or
> factoryReleased.
Minor: factoryReleased -> factoryReleased()
-
PR: https://git.openjdk.java.net/jfx/pull/430
Re: [External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276)
The app is now crashing at InternalFunction which calls jsDynamicCast in JSCast.h, which lead to the initial crash. This assert failure occurs because the type value is ObjectType instead of InternalFunctionType or NullSetterFunctionType. I need to check why this is happens. NDEBUG and ASSERT_ENABLED are used interchangeably in the WebKit code. So, for creating a build without asserts, you can either use the release build PDBs, or set NDEBUG to 1 in WTF/wtf/PlatformEnable.h to generate a minimal debug build. — Arun Joseph On 15-Mar-2021, at 6:08 PM, Primož Kokol mailto:primoz.ko...@gmail.com>> wrote: I've tried to remove this particular assert statement at "JSCast.h:143": // ASSERT_UNUSED(vm, canCast == from->JSCell::inherits(vm, Target::info())); ... and now application crashes at different assert statement: > jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, const > char * __formal, int __formal) Line 672 C++ Symbols loaded. jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, const WTF::String & name, JSC::InternalFunction::NameAdditionMode nameAdditionMode) Line 49 C++ Symbols loaded. jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const WTF::String & ident) Line 58 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, const WTF::String & name) Line 231 C++ Symbols loaded. jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * globalObject, const WTF::String & name, JSC::Bindings::Method * method) Line 212 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols loaded. jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) Line 124 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 48 C++ Symbols loaded. jfxwebkit.dll!JSC::PropertySlot::getValue(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName) Line 422 C++ Symbols loaded. jfxwebkit.dll!JSC::JSValue::get(JSC::JSGlobalObject * globalObject, JSC::PropertyName propertyName, JSC::PropertySlot & slot) Line 963 C++ Symbols loaded. jfxwebkit.dll!JSC::LLInt::performLLIntGetByID(const JSC::Instruction * pc, JSC::CodeBlock * codeBlock, JSC::JSGlobalObject * globalObject, JSC::JSValue baseValue, const JSC::Identifier & ident, JSC::GetByIdModeMetadata & metadata) Line 759 C++ Symbols loaded. jfxwebkit.dll!llint_slow_path_get_by_id(JSC::CallFrame * callFrame, const JSC::Instruction * pc) Line 833 C++ Symbols loaded. jfxwebkit.dll!llint_entry () Unknown Non-user code. Symbols loaded. 0025dabfaf00() Unknown Non-user code 0025dabfafc0() Unknown Non-user code 0164ca445b4b() Unknown Non-user code () Unknown Non-user code 0164ca445b46() Unknown Non-user code Is there any way we could turn off assertions in general when producing debug build? On Sat, 13 Mar 2021 at 05:41, Arun Joseph mailto:arun.aj.jos...@oracle.com>> wrote: I’m currently looking into why the native debug build is crashing. This same assert fails while running FileReaderTest using the native debug build. For the time being, you can try building by removing this particular assert statement for debugging. — Arun Joseph > On 12-Mar-2021, at 11:47 PM, Primož Kokol > mailto:primoz.ko...@gmail.com>> wrote: > > Hi Kevin, > > Unfortunately I don't have a test case. We are using various WebViews in > our production application hence we don't know where/why exactly the > application freezes. > > We were hoping that we will be able to identify it using the native debug > build (& attached debugged) but it is now unfortunately crashing with the > above error. > > Side note: > Should I contact Arun directly or is he seeing these messages? > > -- PrimosK > > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth > mailto:kevin.rushfo...@oracle.com>> > wrote: > >> Arun should be able to help you with the crash you are seeing in debug >> mode. >> >> Regarding the hang, do you have a test case that will reproduce it? A >> few different developers have reported similar hangs. We ended up >> closing a recently-filed bug, JDK-8260238 [1], because were (and still >> are) unable to reproduce the hang. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238 >> >> >> On 3/12/2021 1:06 AM, Primož Kokol wrote: >>> Hi everyone, >>> >>> I would need some help related to OpenJFX build. >>> >>> I was able to successfully prepare a build following this pr
Re: OpenJFX custom build - Java application crash (semi-related to 8262276)
I’m currently looking into why the native debug build is crashing. This same assert fails while running FileReaderTest using the native debug build. For the time being, you can try building by removing this particular assert statement for debugging. — Arun Joseph > On 12-Mar-2021, at 11:47 PM, Primož Kokol wrote: > > Hi Kevin, > > Unfortunately I don't have a test case. We are using various WebViews in > our production application hence we don't know where/why exactly the > application freezes. > > We were hoping that we will be able to identify it using the native debug > build (& attached debugged) but it is now unfortunately crashing with the > above error. > > Side note: > Should I contact Arun directly or is he seeing these messages? > > -- PrimosK > > On Fri, 12 Mar 2021 at 19:00, Kevin Rushforth > wrote: > >> Arun should be able to help you with the crash you are seeing in debug >> mode. >> >> Regarding the hang, do you have a test case that will reproduce it? A >> few different developers have reported similar hangs. We ended up >> closing a recently-filed bug, JDK-8260238 [1], because were (and still >> are) unable to reproduce the hang. >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8260238 >> >> >> On 3/12/2021 1:06 AM, Primož Kokol wrote: >>> Hi everyone, >>> >>> I would need some help related to OpenJFX build. >>> >>> I was able to successfully prepare a build following this procedure (from >>> pull/417 request): >>> https://github.com/openjdk/jfx/pull/417#issuecomment-795178731 >>> >>> We wanted to use it in our existing application (Java 11.0.10) to debug >> an >>> issue where the application would hang/freeze for no obvious reason >> because >>> of WebKit. >>> >>> In order to use this build we've manually overridden javafx-*.jar files >> in >>> our application with the ones from the above build. >>> We've also placed all produced DLL files in our application's "bin" >> folder >>> so they are properly picked up (I've verified and I can confirm that >>> jfxwebkit.dll produced by our debug build is loaded). >>> >>> After using this native debug build, the application will crash instead >>> with: >>> Unhandled exception at 0x7FFA1E93286E (ucrtbase.dll) in java.exe: >> Fatal >>> program exit requested. >>> >>> It looks like it happens when JS code calls Java method. >>> >>> There is the call stack at the time when exception happens: >>> >>>> ucrtbase.dll!abort () Unknown Non-user code. Symbols loaded. >>> jfxwebkit.dll!WTFCrashWithInfo(int __formal, const char * __formal, >> const >>> char * __formal, int __formal) Line 672 C++ Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::inheritsJSTypeImpl(JSC::VM >>> & vm, JSC::InternalFunction * from, JSC::JSTypeRange range) Line 143 C++ >>> Symbols loaded. >>> >>> >> jfxwebkit.dll!JSC::JSCastingHelpers::InheritsTraits::inherits(JSC::VM >>> & vm, JSC::InternalFunction * from) Line 164 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::jsDynamicCast>> *,JSC::InternalFunction>(JSC::VM & vm, JSC::InternalFunction * from) Line >>> 182 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::InternalFunction::finishCreation(JSC::VM & vm, >> const >>> WTF::String & name, JSC::InternalFunction::NameAdditionMode >>> nameAdditionMode) Line 49 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::RuntimeMethod::finishCreation(JSC::VM & vm, const >>> WTF::String & ident) Line 58 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::finishCreation(JSC::VM & globalData, >>> const WTF::String & name) Line 231 C++ Symbols loaded. >>> jfxwebkit.dll!JavaRuntimeMethod::create(JSC::JSGlobalObject * >>> globalObject, const WTF::String & name, JSC::Bindings::Method * method) >>> Line 212 C++ Symbols loaded. >>> >> jfxwebkit.dll!JSC::Bindings::JavaInstance::getMethod(JSC::JSGlobalObject >>> * globalObject, JSC::PropertyName propertyName) Line 241 C++ Symbols >> loaded. >>> >>> >> jfxwebkit.dll!JSC::Bindings::RuntimeObject::methodGetter(JSC::JSGlobalObject >>> * lexicalGlobalObject, __int64 thisValue, JSC::PropertyName propertyName) >>> Line 124 C++ Symbols loaded. >>> jfxwebkit.dll!JSC::PropertySlot::customGetter(JSC::JSGlobalObject * >>>
Re: CFV: New OpenJFX Committer: John Neffenger
Vote: YES — Arun Joseph > On 10-Mar-2021, at 5:27 PM, Kevin Rushforth > wrote: > > I hereby nominate John Neffenger [1] to OpenJFX Committer. > > John is an OpenJFX community member, who has contributed 10 commits [2] to > OpenJFX. > > Votes are due by March 24, 2021 at 12:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#jgneff > > [2] > https://github.com/openjdk/jfx/search?q=author-email%3Ajohn%40status6.com=author-date=Commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > >
Re: RFR: 8262276: Debug build of WebKit fails
On Tue, 9 Mar 2021 14:55:59 GMT, PrimosK wrote: >>> when passing `--info` to gradle, the build succeeds. Without passing >>> `--info` it fails. I'll do more testing later. >> >> Interesting. I don't see this problem. I am able to build with or without >> `--info`. I am also now (with this patch) able to build with or without >> `-PCONF=DebugNative`. >> >> As mentioned earlier, some of the unit tests fail to run in debug mode. Arun >> will look into these failures. > > I think this is actually a lack of physical memory. I was doing tests inside > Windows Sandbox which has 4GB of memory by default. > > After repeating the build procedure inside VM with 16GB of memory the build > succeeded. > > Side question - I see there was: > `C:\jfx\build\modular-sdk\modules_libs\javafx.web\jfxwebkit.dll` > produced but I don't see any PDB files (debugging and project state > information) despite `CONF = DebugNative` is present. Am I missing something? The PDB files are located in `modules\javafx.web\build\win\Debug\bin\jfxwebkit.pdb`. At present, they are not copied to sdk. This bug (https://bugs.openjdk.java.net/browse/JDK-8263259) is created to fix the same. - PR: https://git.openjdk.java.net/jfx/pull/417
RFR: 8262276: Debug build of WebKit fails
Fixing the Debug build of WebKit. Test: Build JavaFX using `-PCOMPILE_WEBKIT=true -PCONF=DebugNative` and test using a simple HelloWebView app. - Commit messages: - 8262276: Debug build of WebKit fails Changes: https://git.openjdk.java.net/jfx/pull/417/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=417=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262276 Stats: 59 lines in 7 files changed: 39 ins; 16 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/417.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/417/head:pull/417 PR: https://git.openjdk.java.net/jfx/pull/417
Integrated: 8260165: CSSFilterTest.testCSSFilterRendering system test fails
On Mon, 22 Feb 2021 11:55:00 GMT, Arun Joseph wrote: > Issue: Initial layout delay was removed and layout() is called from > layoutTimer instead of WebPage::prePaint(). > > Fix: Re-introduce the initial layout delay. This pull request has now been integrated. Changeset: 8ad18c32 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/8ad18c32 Stats: 8 lines in 2 files changed: 6 ins; 2 del; 0 mod 8260165: CSSFilterTest.testCSSFilterRendering system test fails Reviewed-by: kcr, ghb - PR: https://git.openjdk.java.net/jfx/pull/408
Integrated: 8260257: [Linux] WebView no longer reacts to some mouse events
On Wed, 17 Feb 2021 14:14:35 GMT, Arun Joseph wrote: > Timer in RunLoopGeneric has an open bug in WebKit > (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain > active even after firing. > > Reverting back to WebCore Timer for ScrollAnimation in Linux. This pull request has now been integrated. Changeset: dc91f64b Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/dc91f64b Stats: 170 lines in 5 files changed: 169 ins; 0 del; 1 mod 8260257: [Linux] WebView no longer reacts to some mouse events Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/404
Re: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v2]
On Wed, 24 Feb 2021 13:33:39 GMT, Kevin Rushforth wrote:
>> Arun Joseph has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add system test
>
> tests/system/src/test/java/test/javafx/scene/web/WebPageTest.java line 135:
>
>> 133:
>> 134: assertTrue("Timeout when waiting for focus change ",
>> Util.await(webViewStateLatch));
>> 135:
>
> I needed to add a `sleep(500)` here.
I've used `Util.sleep(1000)` instead to make it similar to the other system web
tests.
-
PR: https://git.openjdk.java.net/jfx/pull/404
Re: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v3]
> Timer in RunLoopGeneric has an open bug in WebKit > (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain > active even after firing. > > Reverting back to WebCore Timer for ScrollAnimation in Linux. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Add sleep - Changes: - all: https://git.openjdk.java.net/jfx/pull/404/files - new: https://git.openjdk.java.net/jfx/pull/404/files/903093ac..aea26961 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=404=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=404=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/404.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/404/head:pull/404 PR: https://git.openjdk.java.net/jfx/pull/404
Re: RFR: 8260165: CSSFilterTest.testCSSFilterRendering system test fails
On Wed, 24 Feb 2021 13:01:50 GMT, Kevin Rushforth wrote: >> Issue: Initial layout delay was removed and layout() is called from >> layoutTimer instead of WebPage::prePaint(). >> >> Fix: Re-introduce the initial layout delay. > > This seems a safe enough fix to restore the layout delay that was removed in > WebKit 610.2 (and which has caused a regression). Are there any drawbacks to > doing this? The only drawback would be layout is calculated in the next updateContent cycle instead of right after loading the first page, which is same as before WebKit 610.2. This would only cause a delay of a few milliseconds (~10 ms for this test). - PR: https://git.openjdk.java.net/jfx/pull/408
RFR: 8260165: CSSFilterTest.testCSSFilterRendering system test fails
Issue: Initial layout delay was removed and layout() is called from layoutTimer instead of WebPage::prePaint(). Fix: Re-introduce the initial layout delay. - Commit messages: - Add comment - 8260165: CSSFilterTest.testCSSFilterRendering system test fails Changes: https://git.openjdk.java.net/jfx/pull/408/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=408=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260165 Stats: 8 lines in 2 files changed: 6 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/408.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/408/head:pull/408 PR: https://git.openjdk.java.net/jfx/pull/408
Re: RFR: 8260257: [Linux] WebView no longer reacts to some mouse events [v2]
> Timer in RunLoopGeneric has an open bug in WebKit > (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain > active even after firing. > > Reverting back to WebCore Timer for ScrollAnimation in Linux. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Add system test - Changes: - all: https://git.openjdk.java.net/jfx/pull/404/files - new: https://git.openjdk.java.net/jfx/pull/404/files/480c0d98..903093ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=404=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=404=00-01 Stats: 161 lines in 3 files changed: 160 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/404.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/404/head:pull/404 PR: https://git.openjdk.java.net/jfx/pull/404
Integrated: 8261927: WebKit build fails with Visual Studio 2017
On Thu, 18 Feb 2021 13:25:14 GMT, Arun Joseph wrote: > The WebKit build fails with Visual Studio 2017. > > Issue: Visual Studio 2017 doesn't support if constexpr in lambda > > Test: Build webkit with the VS2017 compiler with and without this fix. It > should fail without the fix and build with the fix. This pull request has now been integrated. Changeset: 9e42eea4 Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/9e42eea4 Stats: 33 lines in 1 file changed: 31 ins; 0 del; 2 mod 8261927: WebKit build fails with Visual Studio 2017 Reviewed-by: kcr, ghb - PR: https://git.openjdk.java.net/jfx/pull/405
RFR: 8261927: WebKit build fails with Visual Studio 2017
The WebKit build fails with Visual Studio 2017. Issue: Visual Studio 2017 doesn't support if constexpr in lamda Test: Build webkit with the VS2017 compiler with and without this fix. It should fail without the fix and build with the fix. - Commit messages: - 8261927: WebKit build fails with Visual Studio 2017 Changes: https://git.openjdk.java.net/jfx/pull/405/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=405=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261927 Stats: 33 lines in 1 file changed: 31 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/405.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/405/head:pull/405 PR: https://git.openjdk.java.net/jfx/pull/405
RFR: 8260257: [Linux] WebView no longer reacts to some mouse events
Timer in RunLoopGeneric has an open bug in WebKit (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain active even after firing. Reverting back to WebCore Timer for ScrollAnimation in Linux. - Commit messages: - 8260257: [Linux] WebView no longer reacts to some mouse events Changes: https://git.openjdk.java.net/jfx/pull/404/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=404=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260257 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/404.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/404/head:pull/404 PR: https://git.openjdk.java.net/jfx/pull/404
Integrated: 8254836: Cherry pick GTK WebKit 2.30.3 changes
On Wed, 3 Feb 2021 17:52:31 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.30.3 > https://webkitgtk.org/2020/11/20/webkitgtk2.30.3-released.html This pull request has now been integrated. Changeset: 425c3353 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/425c3353 Stats: 679 lines in 37 files changed: 483 ins; 87 del; 109 mod 8254836: Cherry pick GTK WebKit 2.30.3 changes Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/392
RFR: 8254836: Cherry pick GTK WebKit 2.30.3 changes
Update to GTK WebKit 2.30.3 https://webkitgtk.org/2020/11/20/webkitgtk2.30.3-released.html - Commit messages: - 8254836: Cherry pick GTK WebKit 2.30.3 changes Changes: https://git.openjdk.java.net/jfx/pull/392/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=392=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254836 Stats: 679 lines in 37 files changed: 483 ins; 87 del; 109 mod Patch: https://git.openjdk.java.net/jfx/pull/392.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/392/head:pull/392 PR: https://git.openjdk.java.net/jfx/pull/392
Integrated: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows
On Mon, 1 Feb 2021 03:31:10 GMT, Arun Joseph wrote: > Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 > onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms > `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few > ms early. The same is not present in `WorkQueueGeneric` and needs to be added. > > Also removing `WorkQueueWin` as it's removed for WebKit as well. This pull request has now been integrated. Changeset: e481f8c7 Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/e481f8c7 Stats: 212 lines in 3 files changed: 13 ins; 199 del; 0 mod 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/391
Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2]
On Mon, 1 Feb 2021 16:55:50 GMT, Kevin Rushforth wrote:
>> Arun Joseph has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update comment
>
> modules/javafx.web/src/main/native/Source/WTF/wtf/generic/WorkQueueGeneric.cpp
> line 85:
>
>> 83: // so far.
>> 84: const Seconds slopAdjustment { 20_ms };
>> 85: if (delay)
>
> Since `delay` is an object of type `Seconds`, should this be `if
> (delay.milliseconds())`? Otherwise, won't it just check whether the object is
> non-null?
In
[Seconds.h](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/Seconds.h),
there's an `operator bool()` which checks the m_value.
-
PR: https://git.openjdk.java.net/jfx/pull/391
Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2]
> Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 > onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms > `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few > ms early. The same is not present in `WorkQueueGeneric` and needs to be added. > > Also removing `WorkQueueWin` as it's removed for WebKit as well. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Update comment - Changes: - all: https://git.openjdk.java.net/jfx/pull/391/files - new: https://git.openjdk.java.net/jfx/pull/391/files/739f3207..ea61414f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=391=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=391=00-01 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/391.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/391/head:pull/391 PR: https://git.openjdk.java.net/jfx/pull/391
RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows
Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few ms early. The same is not present in `WorkQueueGeneric` and needs to be added. Also removing `WorkQueueWin` as it's removed for WebKit as well. - Commit messages: - 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows Changes: https://git.openjdk.java.net/jfx/pull/391/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=391=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260163 Stats: 204 lines in 3 files changed: 5 ins; 199 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/391.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/391/head:pull/391 PR: https://git.openjdk.java.net/jfx/pull/391
Integrated: 8259635: Update to 610.2 version of WebKit
On Thu, 21 Jan 2021 04:14:28 GMT, Arun Joseph wrote: > Update JavaFX WebKit to GTK WebKit 2.30 (610.2) This pull request has now been integrated. Changeset: b0a404de Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/b0a404de Stats: 257339 lines in 5451 files changed: 125161 ins; 93742 del; 38436 mod 8259635: Update to 610.2 version of WebKit Reviewed-by: kcr, ghb, jvos - PR: https://git.openjdk.java.net/jfx/pull/382
Re: RFR: 8259635: Update to 610.2 version of WebKit [v2]
> Update JavaFX WebKit to GTK WebKit 2.30 (610.2) Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Fix color in DefaultPlugin - Changes: - all: https://git.openjdk.java.net/jfx/pull/382/files - new: https://git.openjdk.java.net/jfx/pull/382/files/f55e82f8..ccb53c63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=382=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=382=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/382.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/382/head:pull/382 PR: https://git.openjdk.java.net/jfx/pull/382
Re: RFR: 8259635: Update to 610.2 version of WebKit
On Thu, 21 Jan 2021 13:25:39 GMT, Kevin Rushforth wrote: >> Update JavaFX WebKit to GTK WebKit 2.30 (610.2) > > I reviewed all of the changes outside `modules/javafx.web/src/main/native/`. > Most look related to the change to use the Prism Color object instead of an > int. I did have a question about one of those changes: > > modules/javafx.web/src/main/java/com/sun/webkit/plugin/DefaultPlugin.java > -g.fillRect(x, y, w, h, 0x11aa); > +g.fillRect(x, y, w, h, new Color(0.33f, 1.0f, 1.0f, 0.1f)); > > These are not equivalent colors. Is this intentional? It should be `new Color(2 / 3.0f, 1.0f, 1.0f, 1 / 15.0f)`. I'll update the PR. - PR: https://git.openjdk.java.net/jfx/pull/382
RFR: 8259635: Update to 610.2 version of WebKit
Update JavaFX WebKit to GTK WebKit 2.30 (610.2) - Commit messages: - 8259635: Update to 610.2 version of WebKit Changes: https://git.openjdk.java.net/jfx/pull/382/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=382=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259635 Stats: 257339 lines in 5451 files changed: 125161 ins; 93742 del; 38436 mod Patch: https://git.openjdk.java.net/jfx/pull/382.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/382/head:pull/382 PR: https://git.openjdk.java.net/jfx/pull/382
Re: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v6]
On Wed, 16 Dec 2020 19:07:17 GMT, Matthias Bläsing wrote: >> The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that >> the java class com.sun.webkit.MainThread can be found be the JNI >> function FindClass. This is only true if the class is loadable by the >> system class loader. >> >> One such case is when the OpenJFX modules are loaded from a new >> ModuleLayer. To fix this, the reference to the class needs to be loaded >> from when a JNI call from Java into native code is active. In that case >> FindClass uses the classloader associated with that method. >> >> The test code can be executed by running: >> >> cd tests/manual/web/dataurl >> ../../../../gradlew run > > Matthias Bläsing has updated the pull request incrementally with one > additional commit since the last revision: > > Ensure error code 0 is not reached by normal javafx exit Marked as reviewed by ajoseph (Committer). - PR: https://git.openjdk.java.net/jfx/pull/360
Re: RFR: 8242361: JavaFX Web View crashes with Segmentation Fault, when HTML contains Data-URIs [v3]
On Tue, 15 Dec 2020 16:57:13 GMT, Matthias Bläsing
wrote:
>> The code in WTF::scheduleDispatchFunctionsOnMainThread assumes, that
>> the java class com.sun.webkit.MainThread can be found be the JNI
>> function FindClass. This is only true if the class is loadable by the
>> system class loader.
>>
>> One such case is when the OpenJFX modules are loaded from a new
>> ModuleLayer. To fix this, the reference to the class needs to be loaded
>> from when a JNI call from Java into native code is active. In that case
>> FindClass uses the classloader associated with that method.
>>
>> The test code can be executed by running:
>>
>> cd tests/manual/web/dataurl
>> ../../../../gradlew run
>
> Matthias Bläsing has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Updated according to review comments
>
> - The text and formatting was adjusted according to the raised concerns.
> - The test was modified with a 15000ms timeout as is the case for other
> tests in the systemTests project
> - A safeguard was added in the launched child JVM, that terminates the
> child after 15000ms is it did not exit normally
> - The detection of a successful test was moved to a ChangeLister on the
> load worker state. It is assumed, that the worker success state is
> similar to the DOMContentLoaded event. The latter is fired after
> synchronous javascript was executed and that would be late enough to
> "see" the DOM update of the title.
>
> It was validated, that the test still fails without the fix and succeeds
> with it.
Fix and test looks good. Added a minor typo fix.
modules/javafx.web/src/main/native/Source/WTF/wtf/java/MainThreadJava.cpp line
49:
> 47: {
> 48: // Initialize the class reference and methodids for the MainThread.
> The
> 49: // initilization has to be done from a context where the class
initilization -> initialization
-
PR: https://git.openjdk.java.net/jfx/pull/360
Integrated: 8257897: Fix webkit build for XCode 12
On Tue, 8 Dec 2020 17:29:56 GMT, Arun Joseph wrote: > The WebKit build fails with recent Xcode 12. > > Bug: `getVTablePointer()` should return a const void* > > Fix: Use const void* and remove dependency on JavaVM.framework in Xcode > Upstream fix: https://bugs.webkit.org/show_bug.cgi?id=207871 > > Test: Build webkit with the Xcode 12 compiler with and without this fix. It > should fail without the fix and build with the fix. This pull request has now been integrated. Changeset: 7fa02fe2 Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/7fa02fe2 Stats: 8 lines in 3 files changed: 0 ins; 4 del; 4 mod 8257897: Fix webkit build for XCode 12 Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/365
RFR: 8257897: Fix webkit build for XCode 12
The WebKit build fails with recent Xcode 12. Bug: `getVTablePointer()` should return a const void* Fix: Use const void* and remove dependency on JavaVM.framework in Xcode Upstream fix: https://bugs.webkit.org/show_bug.cgi?id=207871 Test: Build webkit with the Xcode 12 compiler with and without this fix. It should fail without the fix and build with the fix. - Commit messages: - 8257897: Fix webkit build for XCode 12 Changes: https://git.openjdk.java.net/jfx/pull/365/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=365=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257897 Stats: 8 lines in 3 files changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/365.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/365/head:pull/365 PR: https://git.openjdk.java.net/jfx/pull/365
Integrated: 8254049: Update WebView to public suffix list 2020-04-24
On Mon, 19 Oct 2020 04:29:13 GMT, Arun Joseph wrote: > We should use the public_suffix_list.dat file in the JDK instead. Reading the > public_suffix_list.dat file is modified to be similar to > [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). > If the file is not present, `isPublicSuffix()` returns `false`, which is > similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java This pull request has now been integrated. Changeset: c8d9c94d Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/c8d9c94d Stats: 5363 lines in 4 files changed: 87 ins; 5214 del; 62 mod 8254049: Update WebView to public suffix list 2020-04-24 Reviewed-by: kcr, ghb - PR: https://git.openjdk.java.net/jfx/pull/324
Re: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v5]
> We should use the public_suffix_list.dat file in the JDK instead. Reading the > public_suffix_list.dat file is modified to be similar to > [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). > If the file is not present, `isPublicSuffix()` returns `false`, which is > similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Concat log warning - Changes: - all: https://git.openjdk.java.net/jfx/pull/324/files - new: https://git.openjdk.java.net/jfx/pull/324/files/fc3b66cf..49d7b5f4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=324=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx=324=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/324/head:pull/324 PR: https://git.openjdk.java.net/jfx/pull/324
Re: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v4]
> We should use the public_suffix_list.dat file in the JDK instead. Reading the > public_suffix_list.dat file is modified to be similar to > [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). > If the file is not present, `isPublicSuffix()` returns `false`, which is > similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Add doPrivileged block - Changes: - all: https://git.openjdk.java.net/jfx/pull/324/files - new: https://git.openjdk.java.net/jfx/pull/324/files/be156736..fc3b66cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=324=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx=324=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/324/head:pull/324 PR: https://git.openjdk.java.net/jfx/pull/324
Re: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v3]
> We should use the public_suffix_list.dat file in the JDK instead. Reading the > public_suffix_list.dat file is modified to be similar to > [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). > If the file is not present, `isPublicSuffix()` returns `false`, which is > similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Create pslFile variable - Changes: - all: https://git.openjdk.java.net/jfx/pull/324/files - new: https://git.openjdk.java.net/jfx/pull/324/files/6ed148f6..be156736 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=324=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=324=01-02 Stats: 20 lines in 1 file changed: 10 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/324/head:pull/324 PR: https://git.openjdk.java.net/jfx/pull/324
Re: RFR: 8254049: Update WebView to public suffix list 2020-04-24 [v2]
> We should use the public_suffix_list.dat file in the JDK instead. Reading the > public_suffix_list.dat file is modified to be similar to > [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). > If the file is not present, `isPublicSuffix()` returns `false`, which is > similar to how WebKit ignores the public suffix check when it is disabled. > > Test: Run PublicSuffixesTest.java Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Check whether PSL file exists - Changes: - all: https://git.openjdk.java.net/jfx/pull/324/files - new: https://git.openjdk.java.net/jfx/pull/324/files/e5c9d4de..6ed148f6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=324=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=324=00-01 Stats: 35 lines in 2 files changed: 27 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/324/head:pull/324 PR: https://git.openjdk.java.net/jfx/pull/324
Re: RFR: 8254049: Update WebView to public suffix list 2020-04-24
On Tue, 27 Oct 2020 00:38:31 GMT, Kevin Rushforth wrote: >> We should use the public_suffix_list.dat file in the JDK instead. Reading >> the public_suffix_list.dat file is modified to be similar to >> [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). >> If the file is not present, `isPublicSuffix()` returns `false`, which is >> similar to how WebKit ignores the public suffix check when it is disabled. >> >> Test: Run PublicSuffixesTest.java > > modules/javafx.web/src/main/java/com/sun/webkit/network/PublicSuffixes.java > line 132: > >> 130: return null; >> 131: } >> 132: return rulesCache.computeIfAbsent(tld, k -> >> createRules(tld)); > > If the public_suffixes file cannot be loaded (for example, if it is removed > from the JDK), then this causes a warning to be logged on every call to this > (basically on every load of any web site). It might be better to call > `createRules` from a static init block. If `createRules` is called from a static init block, then all the public suffix rules (for all TLDs) must be loaded during initialization. Another approach would be to set a `fileNotFound` flag which could be set to true in `getPubSuffixStream` and call `Rules.getRules` only when the value is `false`. - PR: https://git.openjdk.java.net/jfx/pull/324
Integrated: 8242861: Update ImagePattern to apply SVG pattern transforms
On Mon, 20 Apr 2020 05:40:51 GMT, Arun Joseph wrote: > fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() > doesn't use patternTransform argument as ImagePattern doesn't have the same > attribute. So, the final image won't be transformed. This pull request has now been integrated. Changeset: dd22cd2d Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/dd22cd2d Stats: 104 lines in 6 files changed: 83 ins; 11 del; 10 mod 8242861: Update ImagePattern to apply SVG pattern transforms Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/190
Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v7]
On Tue, 3 Nov 2020 12:01:38 GMT, Ambarish Rapte wrote:
>> Arun Joseph has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect concat param order
>
> modules/javafx.graphics/src/main/java/com/sun/prism/impl/ps/PaintHelper.java
> line 754:
>
>> 752:
>> 753: BaseTransform paintXform = paint.getPatternTransformNoClone();
>> 754: if (paintXform != null) {
>
> Minor: Is the null check needed ? I could not find an instance where an
> object of `ImagePattern` is constructed using default constructor.
> If `ImagePattern.getPatternTransformNoClone()` could return null then should
> we do null check with other calls to
> `ImagePattern.getPatternTransformNoClone()` ? OR may be remove this null
> check.
The null check is not actually required as instances of `ImagePattern` can't
have a null `patternTransform`. I added this check as `setLinearGradient` and
`setRadialGradient` functions have also added them, when instances of
`Gradient` can't have null as its transform. Should this null check be removed?
-
PR: https://git.openjdk.java.net/jfx/pull/190
Re: CFV: New OpenJFX Committer: Pankaj Bansal
Vote: YES > On 23-Oct-2020, at 8:08 PM, Kevin Rushforth > wrote: > > I hereby nominate Pankaj Bansal [1] to OpenJFX Committer. > > Pankaj is a member of Java client team at Oracle, who has contributed 11 > commits [2] to OpenJFX. > > Votes are due by November 6, 2020. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] https://openjdk.java.net/census#pbansal > > [2] > https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22Pankaj+Bansal%22=commits > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer >
Integrated: 8252596: [TESTBUG] WebPageShim::paint is not thread-safe
On Wed, 21 Oct 2020 17:30:36 GMT, Arun Joseph wrote: > Issue: Tests using `WebPageShim::paint` fails around 1/10 times. > > Fix: Execute `WebPageShim::paint` in the render thread using `PrismInvoker`. > Ran tests over 100 times, no failures. > > Used the initial unit test in the PR for > [JDK-8202990](https://bugs.openjdk.java.net/browse/JDK-8202990). This pull request has now been integrated. Changeset: 4e5f0e6b Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/4e5f0e6b Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8252596: [TESTBUG] WebPageShim::paint is not thread-safe Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/327
RFR: 8252596: [TESTBUG] WebPageShim::paint is not thread-safe
Issue: Tests using `WebPageShim::paint` fails around 1/10 times. Fix: Execute `WebPageShim::paint` in the render thread using `PrismInvoker`. Ran tests over 100 times, no failures. Used the initial unit test in the PR for [JDK-8202990](https://bugs.openjdk.java.net/browse/JDK-8202990). - Commit messages: - 8252596: [TESTBUG] WebPageShim::paint is not thread-safe Changes: https://git.openjdk.java.net/jfx/pull/327/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=327=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252596 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/327.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/327/head:pull/327 PR: https://git.openjdk.java.net/jfx/pull/327
RFR: 8254049: Update WebView to public suffix list 2020-04-24
We should use the public_suffix_list.dat file in the JDK instead. Reading the public_suffix_list.dat file is modified to be similar to [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java). If the file is not present, `isPublicSuffix()` returns `false`, which is similar to how WebKit ignores the public suffix check when it is disabled. Test: Run PublicSuffixesTest.java - Commit messages: - 8254049: Update WebView to public suffix list 2020-04-24 Changes: https://git.openjdk.java.net/jfx/pull/324/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=324=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254049 Stats: 5325 lines in 3 files changed: 55 ins; 5216 del; 54 mod Patch: https://git.openjdk.java.net/jfx/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/324/head:pull/324 PR: https://git.openjdk.java.net/jfx/pull/324
Re: RFR: 8254049: Update WebView to public suffix list 2020-04-24
On Mon, 19 Oct 2020 04:29:13 GMT, Arun Joseph wrote:
> We should use the public_suffix_list.dat file in the JDK instead. Reading the
> public_suffix_list.dat file is modified
> to be similar to
> [DomainName.java](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/util/DomainName.java).
> If the file is not present, `isPublicSuffix()` returns `false`, which is
> similar to how WebKit ignores the public
> suffix check when it is disabled. Test: Run PublicSuffixesTest.java
modules/javafx.web/src/test/java/test/com/sun/webkit/network/PublicSuffixesTest.java
line 72:
> 70: @Test
> 71: public void testWildcardRule() {
> 72: test("mm", true);
Had to modify the test as the rule for `*.ar` domain changed.
-
PR: https://git.openjdk.java.net/jfx/pull/324
Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v6]
On Mon, 12 Oct 2020 13:42:08 GMT, Kevin Rushforth wrote: >> Instead of negation, it should have been at the opposite positions. I have >> fixed this in the latest commit. The arg >> list order for >> [`concatenate`](https://github.com/openjdk/jfx/blob/a56ba63bef9b33c4ad5cc9e05ae5bdb0ee480a3f/modules/javafx.graphics/src/main/java/com/sun/javafx/geom/transform/AffineBase.java#L2849) >> is different compared to the constructor of Affine2D. > > With your latest change, the call looks like what I would expect now. I > suspect a shear transform would have been > broken before this last fix, but I didn't try it. Yes, shear transforms were broken before this commit. Now, all transforms works as expected. - PR: https://git.openjdk.java.net/jfx/pull/190
Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v6]
On Fri, 9 Oct 2020 22:14:15 GMT, Kevin Rushforth wrote: >> Arun Joseph has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Update copyright year >> - Minor refactoring > > modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java > line 790: > >> 788: Affine3D at = new Affine3D(); >> 789: at.translate(phase.getX(), phase.getY()); >> 790: at.concatenate(m[0], -m[1], m[4], -m[2], m[3], >> m[5]); > > Can you explain why the matrix is transformed in this way (specifically the > negation of elements 1 and 2)? A code > comment would be helpful since it is non-obvious. Instead of negation, it should have been at the opposite positions. I have fixed this in the latest commit. The arg list order for [`concatenate`](https://github.com/openjdk/jfx/blob/a56ba63bef9b33c4ad5cc9e05ae5bdb0ee480a3f/modules/javafx.graphics/src/main/java/com/sun/javafx/geom/transform/AffineBase.java#L2849) is different compared to the constructor of Affine2D. - PR: https://git.openjdk.java.net/jfx/pull/190
Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v6]
On Fri, 9 Oct 2020 21:48:40 GMT, Kevin Rushforth wrote: >> Arun Joseph has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Update copyright year >> - Minor refactoring > > modules/javafx.graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java > line 742: > >> 740: } >> 741: >> 742: g2d.fill(tmpAT.createTransformedShape(shape)); > > Maybe move the `fill` call inside the try/catch so it won't draw anything if > the transform is non-invertible? That > matches what `drawMappedTextureRaw` does. Moved `g2d.fill` into try/catch block. - PR: https://git.openjdk.java.net/jfx/pull/190
Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v7]
> fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() > doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be > transformed. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Fix incorrect concat param order - Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/4241c502..abb4787a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=190=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx=190=05-06 Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190
Integrated: 8253696: WebEngine refuses to load local "file:///" CSS stylesheets when using JDK 15
On Mon, 5 Oct 2020 07:08:33 GMT, Arun Joseph wrote: > Issue: In JDK15, > [URLConnection](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/net/www/URLConnection.java) > class overrode the getHeaderFields() methods to return properties, which > previously returned an empty map from its > super class. Fix: Extract headers only when it's a HttpURLConnection, > otherwise return an empty String. This pull request has now been integrated. Changeset: 15e52d8f Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/15e52d8f Stats: 24 lines in 3 files changed: 15 ins; 0 del; 9 mod 8253696: WebEngine refuses to load local "file:///" CSS stylesheets when using JDK 15 Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/314
RFR: 8253696: WebEngine refuses to load local "file:///" CSS stylesheets when using JDK 15
Issue: In JDK15, [URLConnection](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/net/www/URLConnection.java) class overrode the getHeaderFields() methods to return properties, which previously returned an empty map from its super class. Fix: Extract headers only when it's a HttpURLConnection, otherwise return an empty String. - Commit messages: - Update copyright year - Add unit test - WebEngine refuses to load local "file:///" CSS stylesheets when using JDK 15 Changes: https://git.openjdk.java.net/jfx/pull/314/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=314=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253696 Stats: 24 lines in 3 files changed: 15 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/314.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/314/head:pull/314 PR: https://git.openjdk.java.net/jfx/pull/314
Re: RFR: 8218973: SVG with masking is not rendering image with mask effect [v13]
On Thu, 17 Sep 2020 06:29:36 GMT, Arun Joseph wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Updates as per review comments > > The fix works when the shape is displayed initially on the screen, but fails > when we scroll the image off-screen and > then, back. To see the issue, you need to either rotate the gradient > transform (by 90 degrees) or use a circle (any > shape other than a rectangle) as the mask shape, as this bug can't be seen > using a mask rectangle. To reproduce the above issue, you can either you `` or ` ` in `svgMask.html` and resize the window for scrolling. - PR: https://git.openjdk.java.net/jfx/pull/213
Re: RFR: 8218973: SVG with masking is not rendering image with mask effect [v13]
On Mon, 14 Sep 2020 13:47:28 GMT, Bhawesh Choudhary wrote: >> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp >> in WebKit was not implemented, so masking >> doesn't take place at all while rendering SVGRect. to fix this issue add >> implementation of function clipToImageBuffer() >> in GraphicsContextJava.cpp and send clip image to >> WCGraphicsPrismContext.java While rendering in >> WCGraphicsPrismContext.java if image clip mask is available, use it for >> rendering using MaskTextureGraphics interface >> otherwise use usual way of rendering. > > Bhawesh Choudhary has updated the pull request incrementally with one > additional commit since the last revision: > > Updates as per review comments The fix works when the shape is displayed initially on the screen, but fails when we scroll the image off-screen and then, back. To see the issue, you need to either rotate the gradient transform (by 90 degrees) or use a circle (any shape other than a rectangle) as the mask shape, as this bug can't be seen using a mask rectangle. - PR: https://git.openjdk.java.net/jfx/pull/213
Re: RFR: 8202990: javafx webview css filter property with display scaling [v3]
On Thu, 3 Sep 2020 06:07:10 GMT, Bhawesh Choudhary wrote: >> ImageJava.cpp ignores CompositeOperator parameter in drawImage function due >> to which shadow was getting drawn on top of >> actual image. apply given composite operator to graphics context before >> drawing image to fix this issue. another issue >> is into WCGraphicsPrismContext.java. while blending two layers, applying >> state to the destination layer was missed due >> to which image was not getting drawn with right scale in hidpi mode. apply >> state to fix the issue. > > Bhawesh Choudhary has updated the pull request incrementally with one > additional commit since the last revision: > > Updated test as per review comment The fix and test looks good. - Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/279
Integrated: 8252062: WebKit build fails with recent VS 2019 compiler
On Wed, 2 Sep 2020 11:22:45 GMT, Arun Joseph wrote: > The WebKit build fails with recent VS 2019 compiler. > > Bug: This MediaQueryEvaluator constructor takes a String parameter, but the > conversion of char* to String is failing. > > Fix: Use the default constructor of MediaQueryEvaluator, which also returns > true for "all". > > Test: Build webkit with the recent VS 2019 compiler with and without this > fix. It should fail without the fix and build > with the fix. This pull request has now been integrated. Changeset: 8e3616cf Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/8e3616cf Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8252062: WebKit build fails with recent VS 2019 compiler Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/294
RFR: 8252062: WebKit build fails with recent VS 2019 compiler
The WebKit build fails with recent VS 2019 compiler. Bug: This MediaQueryEvaluator constructor takes a String parameter, but the conversion of char* to String is failing. Fix: Use the default constructor of MediaQueryEvaluator, which also returns true for "all". Test: Build webkit with the recent VS 2019 compiler with and without this fix. It should crash without the fix and build with the fix. - Commit messages: - 8252062: WebKit build fails with recent VS 2019 compiler Changes: https://git.openjdk.java.net/jfx/pull/294/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=294=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252062 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/294.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/294/head:pull/294 PR: https://git.openjdk.java.net/jfx/pull/294
Re: RFR: 8202990: javafx webview css filter property with display scaling [v2]
On Tue, 1 Sep 2020 06:29:17 GMT, Bhawesh Choudhary
wrote:
>> ImageJava.cpp ignores CompositeOperator parameter in drawImage function due
>> to which shadow was getting drawn on top of
>> actual image. apply given composite operator to graphics context before
>> drawing image to fix this issue. another issue
>> is into WCGraphicsPrismContext.java. while blending two layers, applying
>> state to the destination layer was missed due
>> to which image was not getting drawn with right scale in hidpi mode. apply
>> state to fix the issue.
>
> Bhawesh Choudhary has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Moved test from unit test to system test
tests/system/src/test/java/test/javafx/scene/web/CSSFilterTest.java line 93:
> 92: double deltaOpacity = Math.abs(notExpected.getOpacity() -
> actual.getOpacity());
> 93: if (deltaRed < delta && deltaGreen < delta && deltaBlue < delta
> && deltaOpacity < delta) {
> 94: fail(msg + " not expected:" + colorToString(notExpected)
testColorEquals can be reused here.
`if (testColorEquals(expected, actual, delta))`
-
PR: https://git.openjdk.java.net/jfx/pull/279
Re: RFR: 8202990: javafx webview css filter property with display scaling [v2]
On Tue, 1 Sep 2020 06:29:17 GMT, Bhawesh Choudhary wrote: >> ImageJava.cpp ignores CompositeOperator parameter in drawImage function due >> to which shadow was getting drawn on top of >> actual image. apply given composite operator to graphics context before >> drawing image to fix this issue. another issue >> is into WCGraphicsPrismContext.java. while blending two layers, applying >> state to the destination layer was missed due >> to which image was not getting drawn with right scale in hidpi mode. apply >> state to fix the issue. > > Bhawesh Choudhary has updated the pull request incrementally with one > additional commit since the last revision: > > Moved test from unit test to system test tests/system/src/test/java/test/javafx/scene/web/CSSFilterTest.java line 44: > 43: import static javafx.concurrent.Worker.State.SUCCEEDED; > 44: import static org.junit.Assert.assertEquals; > 45: import static org.junit.Assert.assertNotNull; assertEquals is not used in this test and can be removed. - PR: https://git.openjdk.java.net/jfx/pull/279
Integrated: 8252381: Cherry pick GTK WebKit 2.28.4 changes
On Thu, 27 Aug 2020 14:59:56 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.28.4 > https://webkitgtk.org/2020/07/28/webkitgtk2.28.4-released.html This pull request has now been integrated. Changeset: 88c0f978 Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/88c0f978 Stats: 174 lines in 21 files changed: 16 ins; 123 del; 35 mod 8252381: Cherry pick GTK WebKit 2.28.4 changes Reviewed-by: kcr, bchoudhary - PR: https://git.openjdk.java.net/jfx/pull/289
Re: RFR: 8202990: javafx webview css filter property with display scaling
On Tue, 11 Aug 2020 16:18:37 GMT, Bhawesh Choudhary wrote: > ImageJava.cpp ignores CompositeOperator parameter in drawImage function due > to which shadow was getting drawn on top of > actual image. apply given composite operator to graphics context before > drawing image to fix this issue. another issue > is into WCGraphicsPrismContext.java. while blending two layers, applying > state to the destination layer was missed due > to which image was not getting drawn with right scale in hidpi mode. apply > state to fix the issue. The fix and test looks good. - Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/279
RFR: 8252381: Cherry pick GTK WebKit 2.28.4 changes
Update to GTK WebKit 2.28.4 https://webkitgtk.org/2020/07/28/webkitgtk2.28.4-released.html - Commit messages: - 8252381: Cherry pick GTK WebKit 2.28.4 changes Changes: https://git.openjdk.java.net/jfx/pull/289/files Webrev: https://webrevs.openjdk.java.net/jfx/289/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252381 Stats: 174 lines in 21 files changed: 123 ins; 16 del; 35 mod Patch: https://git.openjdk.java.net/jfx/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/289/head:pull/289 PR: https://git.openjdk.java.net/jfx/pull/289
Re: RFR: 8202990: javafx webview css filter property with display scaling
On Wed, 12 Aug 2020 15:59:20 GMT, Kevin Rushforth wrote: > With your patch installed, I see a race condition that manifests in one of > two ways: I couldn't reproduce the race condition or crash with the fix. > I suspect this might be related to the gc.setCompositeOperation call. This may not be the cause as the compositeOperator is pushed to a RenderQueue which is decoded from the java side. - PR: https://git.openjdk.java.net/jfx/pull/279
Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v6]
> fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() > doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be > transformed. Arun Joseph has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year - Minor refactoring - Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/d808d27a..4241c502 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/190/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/190/webrev.04-05 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190
Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v5]
> fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() > doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be > transformed. Arun Joseph has updated the pull request incrementally with three additional commits since the last revision: - Exclude TYPE_IDENTITY case - Another fix for printing - Minimal fix for printing - Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/9b841f4b..d808d27a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/190/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/190/webrev.03-04 Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190
Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v4]
> fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() > doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be > transformed. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Incorect axis of rotational - Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/2e2b5cd1..9b841f4b Webrevs: - full: https://webrevs.openjdk.java.net/jfx/190/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/190/webrev.02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190
Re: RFR: 8240969: WebView does not allow to load style sheet in modularized applications [v4]
On Fri, 14 Aug 2020 06:23:18 GMT, Tobias Diez wrote: >> Currently, loading a style sheet file using >> `WebView.getEngine().setUserStyleSheetLocation(url)` fails if the url >> start's with `jrt`, i.e. if the file is packaged in an application image >> using jlink. This is fixed with this PR. > > Tobias Diez has updated the pull request incrementally with one additional > commit since the last revision: > > Update MiscellaneousTest.java The fix and test looks good. - Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/22
Re: RFR: 8181775: JavaFX WebView does not calculate border-radius properly [v4]
On Thu, 23 Jul 2020 09:43:36 GMT, Bhawesh Choudhary wrote: >> root cause of issue is prism's fillRoundedRect() API doesn't allow rendering >> of rounded corner rectangle if four >> corners have different radii. but same can be achieved via Path. to fix the >> issue, in GraphicsContextJava.cpp while >> rendering fillRoundedRect, check if all four corners have same radii. if >> yes, use FILL_ROUNDED_RECT to draw it >> otherwise construct a path from given rounded rect and draw it. > > Bhawesh Choudhary has updated the pull request with a new target base due to > a merge or a rebase. The pull request now > contains four commits: > - Merge branch 'master' into 8181775 > - Removed wildcard import statement > - Formatting (File Mode Attribute change) > - 8181775: JavaFX WebView does not calculate border-radius properly The fix and test looks good. - Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/218
Re: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v4]
On Mon, 27 Jul 2020 21:16:41 GMT, Nir Lisker wrote: >> Fixes https://bugs.openjdk.java.net/browse/JDK-8246343 and some additional >> fixes in the vicinity. > > Nir Lisker has updated the pull request incrementally with one additional > commit since the last revision: > > Addressed review comments modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 257: > 256: * @param spacing the amount of horizontal space between each child > 257: * @param children The initial set of children for this pane > 258: * @since JavaFX 8.0 Minor typo (The -> the) - PR: https://git.openjdk.java.net/jfx/pull/274
Integrated: 8249839: Cherry pick GTK WebKit 2.28.3 changes
On Thu, 23 Jul 2020 05:34:50 GMT, Arun Joseph wrote: > Update to GTK WebKit 2.28.3 > https://webkitgtk.org/2020/07/09/webkitgtk2.28.3-released.html This pull request has now been integrated. Changeset: 926b5b6b Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/926b5b6b Stats: 531 lines in 36 files changed: 64 ins; 379 del; 88 mod 8249839: Cherry pick GTK WebKit 2.28.3 changes Reviewed-by: kcr, bchoudhary - PR: https://git.openjdk.java.net/jfx/pull/271
Re: RFR: 8218973: SVG with masking is not rendering image with mask effect [v6]
On Tue, 21 Jul 2020 21:50:39 GMT, Bhawesh Choudhary wrote: >> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp >> in WebKit was not implemented, so masking >> doesn't take place at all while rendering SVGRect. to fix this issue add >> implementation of function clipToImageBuffer() >> in GraphicsContextJava.cpp and send clip image to >> WCGraphicsPrismContext.java While rendering in >> WCGraphicsPrismContext.java if image clip mask is available, use it for >> rendering using MaskTextureGraphics interface >> otherwise use usual way of rendering. > > Bhawesh Choudhary has updated the pull request incrementally with one > additional commit since the last revision: > > HiDPI printing and Rendering fix modules/javafx.web/src/main/native/Source/WebCore/rendering/svg/RenderSVGResourceMasker.cpp line 93: > 92: auto deviceScaleFactor = document().deviceScaleFactor(); > 93: maskImageContext.applyDeviceScaleFactor(deviceScaleFactor); > 94: For javafx port specific code in WebKit, it should be enclosed in `#if PLATFORM(JAVA)`. But I think that there should be a better approach as other ports don't require this scaling of `deviceScaleFactor` - PR: https://git.openjdk.java.net/jfx/pull/213
RFR: 8249839: Cherry pick GTK WebKit 2.28.3 changes
Update to GTK WebKit 2.28.3 https://webkitgtk.org/2020/07/09/webkitgtk2.28.3-released.html - Commit messages: - Cherry pick GTK WebKit 2.28.3 changes Changes: https://git.openjdk.java.net/jfx/pull/271/files Webrev: https://webrevs.openjdk.java.net/jfx/271/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249839 Stats: 533 lines in 36 files changed: 381 ins; 66 del; 86 mod Patch: https://git.openjdk.java.net/jfx/pull/271.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/271/head:pull/271 PR: https://git.openjdk.java.net/jfx/pull/271
Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v3]
> fillPath() and fillRect() functions in > [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp) > use Image::drawPattern() for applying patterns as fill. But drawPattern() > doesn't use patternTransform argument as > ImagePattern doesn't have the same attribute. So, the final image won't be > transformed. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Modify SW pipeline - Changes: - all: https://git.openjdk.java.net/jfx/pull/190/files - new: https://git.openjdk.java.net/jfx/pull/190/files/76e4745d..2e2b5cd1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/190/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/190/webrev.01-02 Stats: 91 lines in 3 files changed: 33 ins; 58 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/190/head:pull/190 PR: https://git.openjdk.java.net/jfx/pull/190
Integrated: 8245284: Update to 610.1 version of WebKit
On Fri, 10 Jul 2020 05:26:39 GMT, Arun Joseph wrote: > Update JavaFX WebKit to GTK WebKit 2.28 (610.1) This pull request has now been integrated. Changeset: 5e7e452c Author: Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/5e7e452c Stats: 300855 lines in 5370 files changed: 94021 ins; 146480 del; 60354 mod 8245284: Update to 610.1 version of WebKit Co-authored-by: Guru Hb Co-authored-by: Bhawesh Choudhary Reviewed-by: kcr, bchoudhary, sykora - PR: https://git.openjdk.java.net/jfx/pull/263
RFR: 8245284: Update to 610.1 version of WebKit
Update JavaFX WebKit to GTK WebKit 2.28 (610.1) - Commit messages: - Fix exec files - 8245284: Update to 610.1 version of WebKit Changes: https://git.openjdk.java.net/jfx/pull/263/files Webrev: https://webrevs.openjdk.java.net/jfx/263/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245284 Stats: 301003 lines in 5370 files changed: 146627 ins; 94168 del; 60208 mod Patch: https://git.openjdk.java.net/jfx/pull/263.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/263/head:pull/263 PR: https://git.openjdk.java.net/jfx/pull/263
