RFR: 8218640: Update ICU4C to version 64.2

[Arun Joseph]

We currently use ICU4C version 62.1. We should update to the latest stable 
version 64.2.
http://site.icu-project.org/home



Commits:
 - b56b720e: 8218640: Update ICU4C to version 64.2

Changes: https://git.openjdk.java.net/jfx/pull/10/files
 Webrev: https://webrevs.openjdk.java.net/jfx/10/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8218640
  Stats: 41065 lines in 430 files changed: 23684 ins; 7205 del; 10176 mod
  Patch: https://git.openjdk.java.net/jfx/pull/10.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/10/head:pull/10

PR: https://git.openjdk.java.net/jfx/pull/10

Re: RFR: 8239589: JavaFX UI will not repaint after reconnecting via Remote Desktop [v5]

[Arun Joseph]

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: [External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276)

[Arun Joseph]

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 applicatio

Re: RFR: 8262276: Debug build of WebKit fails [v2]

[Arun Joseph]

> 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&pr=417&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=417&range=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: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH

[Arun Joseph]

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

RFR: 8259555: Webkit crashes on Apple Silicon

[Arun Joseph]

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&pr=452&range=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

Integrated: 8259555: Webkit crashes on Apple Silicon

[Arun Joseph]

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: 8260245: Update ICU4C to version 68.2

[Arun Joseph]

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&pr=456&range=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

Re: RFR: 8260245: Update ICU4C to version 68.2

[Arun Joseph]

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

Re: RFR: 8260245: Update ICU4C to version 68.2 [v2]

[Arun Joseph]

> 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&pr=456&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=456&range=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: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3]

[Arun Joseph]

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

Integrated: 8260245: Update ICU4C to version 68.2

[Arun Joseph]

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: [External] : Re: OpenJFX custom build - Java application crash (semi-related to 8262276)

[Arun Joseph]

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 a

Re: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v2]

[Arun Joseph]

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: OpenJFX custom build - Java application crash (semi-related to 8262276)

[Arun Joseph]

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

RFR: 8263788: JavaFX application freezes completely after some time when using the WebView

[Arun Joseph]

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&pr=461&range=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: RFR: 8263788: JavaFX application freezes completely after some time when using the WebView

[Arun Joseph]

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

Re: RFR: 8264990: WebEngine crashes with segfault when not loaded through system classloader [v3]

[Arun Joseph]

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

Integrated: 8263788: JavaFX application freezes completely after some time when using the WebView

[Arun Joseph]

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: 8262276: Debug build of WebKit fails [v3]

[Arun Joseph]

> 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&pr=417&range=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

Re: RFR: 8265469: Allow to build media and webkit for Linux-AArch64

[Arun Joseph]

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: 8265469: Allow to build media and webkit for Linux-AArch64 [v2]

[Arun Joseph]

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

Integrated: 8262276: Debug build of WebKit fails

[Arun Joseph]

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

RFR: 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest

[Arun Joseph]

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&pr=497&range=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: 8266968: Ignore test.com.sun.webkit.LocalStorageAccessTest

[Arun Joseph]

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: 8267858: Document that title property in WebEngine gets updated asynchronously

[Arun Joseph]

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&pr=522&range=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

Re: RFR: 8267858: Document that title property in WebEngine gets updated asynchronously

[Arun Joseph]

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

Integrated: 8267858: Document that title property in WebEngine gets updated asynchronously

[Arun Joseph]

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: 8268915: WebKit build fails with Xcode 12.5

[Arun Joseph]

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

RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it

[Arun Joseph]

In the HTMLEditor, when positioning the caret in a text and trying to set a 
font-family that has a number in it is not working.

Issue: In 
[CSSPropertyParser.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSPropertyParser.cpp),
 concatenateFamilyName() function parses only identifiers. So, when a number is 
introduced in a font-name, it fails.

Fix: Pass the font-name as a string in HTMLEditorSkin.java by adding quotes.

A new font is added as a resource for the test. This font is same as 
modules/javafx.web/src/main/native/Tools/DumpRenderTree/fonts/WebKit Layout 
Tests 2.ttf



Commits:
 - 5a1fbade: 8230492: font-family not set in HTMLEditor if font name has a 
number in it

Changes: https://git.openjdk.java.net/jfx/pull/27/files
 Webrev: https://webrevs.openjdk.java.net/jfx/27/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8230492
  Stats: 62 lines in 3 files changed: 60 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27

PR: https://git.openjdk.java.net/jfx/pull/27

Re: RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it

[Arun Joseph]

On Wed, 30 Oct 2019 13:27:32 GMT, Kevin Rushforth  wrote:

> On Wed, 30 Oct 2019 11:09:38 GMT, Hadzic Samir  wrote:
> 
>> On Wed, 30 Oct 2019 10:07:42 GMT, Arun Joseph 
>>  wrote:
>> 
>>> In the HTMLEditor, when positioning the caret in a text and trying to set a 
>>> font-family that has a number in it is not working.
>>> 
>>> Issue: In 
>>> [CSSPropertyParser.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/css/parser/CSSPropertyParser.cpp),
>>>  concatenateFamilyName() function parses only identifiers. So, when a 
>>> number is introduced in a font-name, it fails.
>>> 
>>> Fix: Pass the font-name as a string in HTMLEditorSkin.java by adding quotes.
>>> 
>>> A new font is added as a resource for the test. This font is same as 
>>> modules/javafx.web/src/main/native/Tools/DumpRenderTree/fonts/WebKit Layout 
>>> Tests 2.ttf
>>> 
>>> 
>>> 
>>> Commits:
>>>  - 5a1fbade: 8230492: font-family not set in HTMLEditor if font name has a 
>>> number in it
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/27/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/27/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8230492
>>>   Stats: 62 lines in 3 files changed: 60 ins; 0 del; 2 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/27.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27
>> 
>> Will this be in conflict with https://github.com/openjdk/jfx/pull/12 ? I'll 
>> look at your unit tests in order to implement one similar
> 
> I would think that the two fixes are independent of one another, but it would 
> be a good idea to test HTMLEditor with both patches applied.

I tested HTMLEditor with both patches applied, and both fixes are working fine 
without any conflict.

PR: https://git.openjdk.java.net/jfx/pull/27

Re: RFR: WIP: 8230231: font-family not updated in HTMLEditor

[Arun Joseph]

On Thu, 10 Oct 2019 14:56:19 GMT, Hadzic Samir  wrote:

> On Thu, 10 Oct 2019 12:19:18 GMT, Kevin Rushforth  wrote:
> 
>> On Thu, 10 Oct 2019 09:12:57 GMT, Hadzic Samir  wrote:
>> 
>>> On Wed, 9 Oct 2019 20:09:58 GMT, Kevin Rushforth  wrote:
>>> 
 On Wed, 9 Oct 2019 16:09:58 GMT, Hadzic Samir  wrote:
 
> On Wed, 9 Oct 2019 16:09:07 GMT, Kevin Rushforth  wrote:
> 
>> On Wed, 9 Oct 2019 16:09:06 GMT, Hadzic Samir  
>> wrote:
>> 
>>> Fix for https://github.com/javafxports/openjdk-jfx/issues/573
>>> 
>>> Issue on JDK bug tracking : 
>>> https://bugs.openjdk.java.net/browse/JDK-8230231
>>> 
>>> I tried to add a test but I do not succeed at even running the existing 
>>> Web tests.. I will need some help on that side..
>>> 
>>> 
>>> 
>>> Commits:
>>>  - e9df9db5: Adding double-quote for HTMLEditorSkin font-family
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/12/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8230231
>>>   Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/12.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/12/head:pull/12
>> 
>> @Maxoudela please edit the title as follows:
>> 
>> 1. Remove the space before the `:` (that extra space is why jcheck 
>> failed)
>> 2. Change the text of the title to match the JBS bug summary exactly. 
>> You can edit the JBS bug summary if you feel it needs to be changed, but 
>> in this case, the JBS bug has a title that is more in line with our 
>> usual practice of having the bug title be descriptive of what the 
>> problem is and not what the solution happens to be.
>> 
>> As for unit tests, you will very likely need to add this as a system 
>> test under `tests/system/src/main/test`. See 
>> [tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java).
>>  Presuming that you can add your test to that existing class, you would 
>> run it as follows:
>> 
>> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest
> 
> Thanks @kevinrushforth . I'm sorry for posting the Pull request like 
> that, I will thoroughly read the contributing guidelines and updates my 
> PR accordingly.
> 
> I'll try to add a test asap, thanks for the pointer.
 
> I'm sorry for posting the Pull request like that
 
 No problem. I mainly wanted to make sure that you knew why the RFR wasn't 
 sent. As for the note about the title matching, the contributing 
 guidelines don't mention that and I now realize that they should -- I'll 
 add that along with some other improvements I'll be making.
 
> I'll try to add a test asap, thanks for the pointer.
 
 Great, thanks.
>>> 
>>> Hum I do not succeed in running the existing test either. Here is my log. 
>>> Apparently, the tests are failing because the WebView is null and not 
>>> initialized. Do you have any clue of what I've been doing wrong? 
>>> 
>>> Should I try to update my gradle version and JDK version maybe?
>>> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest
>>> Starting a Gradle Daemon (subsequent builds will be faster)
>>> 
 Configure project :
>>> MACOSX_MIN_VERSION = 10.9
>>> MACOSX_SDK_PATH = 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
>>> *
>>> Unsupported gradle version 4.8 in use.
>>> Only version 5.3 is supported. Use this version at your own risk
>>> *
>>> gradle.gradleVersion: 4.8
>>> OS_NAME: mac os x
>>> OS_ARCH: x86_64
>>> JAVA_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home
>>> JDK_HOME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home
>>> java.runtime.version: 11.0.1+13
>>> java version: 11.0.1
>>> java build number: 13
>>> jdk.runtime.version: 11.0.1+13
>>> jdk version: 11.0.1
>>> jdk build number: 13
>>> minimum jdk version: 11
>>> minimum jdk build number: 28
>>> XCODE version: Xcode10.1-MacOSX10.14+1.0
>>> cmake version: 3.13.3
>>> ninja version: 1.8.2
>>> ant version: 1.10.5
>>> HAS_JAVAFX_MODULES: false
>>> STUB_RUNTIME: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home
>>> CONF: Debug
>>> NUM_COMPILE_THREADS: 1
>>> COMPILE_TARGETS: mac
>>> COMPILE_FLAGS_FILES: buildSrc/mac.gradle
>>> HUDSON_JOB_NAME: not_hudson
>>> HUDSON_BUILD_NUMBER: 
>>> PROMOTED_BUILD_NUMBER: 0
>>> PRODUCT_NAME: OpenJFX
>>> RELEASE_VERSION: 14
>>> RELEASE_SUFFIX: -internal
>>> RELEASE_VERSION_SHORT: 14-internal
>>> RELEASE_VERSION_LONG: 14-internal+0-20

Re: RFR: WIP: 8230231: font-family not updated in HTMLEditor

[Arun Joseph]

On Tue, 5 Nov 2019 09:26:56 GMT, Arun Joseph 
 wrote:

> On Thu, 10 Oct 2019 14:56:19 GMT, Hadzic Samir  wrote:
> 
>> On Thu, 10 Oct 2019 12:19:18 GMT, Kevin Rushforth  wrote:
>> 
>>> On Thu, 10 Oct 2019 09:12:57 GMT, Hadzic Samir  wrote:
>>> 
>>>> On Wed, 9 Oct 2019 20:09:58 GMT, Kevin Rushforth  wrote:
>>>> 
>>>>> On Wed, 9 Oct 2019 16:09:58 GMT, Hadzic Samir  wrote:
>>>>> 
>>>>>> On Wed, 9 Oct 2019 16:09:07 GMT, Kevin Rushforth  
>>>>>> wrote:
>>>>>> 
>>>>>>> On Wed, 9 Oct 2019 16:09:06 GMT, Hadzic Samir  
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Fix for https://github.com/javafxports/openjdk-jfx/issues/573
>>>>>>>> 
>>>>>>>> Issue on JDK bug tracking : 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8230231
>>>>>>>> 
>>>>>>>> I tried to add a test but I do not succeed at even running the 
>>>>>>>> existing Web tests.. I will need some help on that side..
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Commits:
>>>>>>>>  - e9df9db5: Adding double-quote for HTMLEditorSkin font-family
>>>>>>>> 
>>>>>>>> Changes: https://git.openjdk.java.net/jfx/pull/12/files
>>>>>>>>  Webrev: https://webrevs.openjdk.java.net/jfx/12/webrev.00
>>>>>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8230231
>>>>>>>>   Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
>>>>>>>>   Patch: https://git.openjdk.java.net/jfx/pull/12.diff
>>>>>>>>   Fetch: git fetch https://git.openjdk.java.net/jfx 
>>>>>>>> pull/12/head:pull/12
>>>>>>> 
>>>>>>> @Maxoudela please edit the title as follows:
>>>>>>> 
>>>>>>> 1. Remove the space before the `:` (that extra space is why jcheck 
>>>>>>> failed)
>>>>>>> 2. Change the text of the title to match the JBS bug summary exactly. 
>>>>>>> You can edit the JBS bug summary if you feel it needs to be changed, 
>>>>>>> but in this case, the JBS bug has a title that is more in line with our 
>>>>>>> usual practice of having the bug title be descriptive of what the 
>>>>>>> problem is and not what the solution happens to be.
>>>>>>> 
>>>>>>> As for unit tests, you will very likely need to add this as a system 
>>>>>>> test under `tests/system/src/main/test`. See 
>>>>>>> [tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/scene/web/HTMLEditorTest.java).
>>>>>>>  Presuming that you can add your test to that existing class, you would 
>>>>>>> run it as follows:
>>>>>>> 
>>>>>>> gradle -PFULL_TEST=true :systemTests:test --tests HTMLEditorTest
>>>>>> 
>>>>>> Thanks @kevinrushforth . I'm sorry for posting the Pull request like 
>>>>>> that, I will thoroughly read the contributing guidelines and updates my 
>>>>>> PR accordingly.
>>>>>> 
>>>>>> I'll try to add a test asap, thanks for the pointer.
>>>>> 
>>>>>> I'm sorry for posting the Pull request like that
>>>>> 
>>>>> No problem. I mainly wanted to make sure that you knew why the RFR wasn't 
>>>>> sent. As for the note about the title matching, the contributing 
>>>>> guidelines don't mention that and I now realize that they should -- I'll 
>>>>> add that along with some other improvements I'll be making.
>>>>> 
>>>>>> I'll try to add a test asap, thanks for the pointer.
>>>>> 
>>>>> Great, thanks.
>>>> 
>>>> Hum I do not succeed in running the existing test either. Here is my log. 
>>>> Apparently, the tests are failing because the WebView is null and not 
>>>> initialized. Do you have any clue of what I've been doing wrong? 
>>>> 
>>>> Should I try to update my gradle version and JDK version maybe?
>>>

Re: [Rev 01] RFR: 8230492: font-family not set in HTMLEditor if font name has a number in it

[Arun Joseph]

The pull request has been updated with additional changes.



Added commits:
 - afc7f17a: Minor formatting

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/27/files
  - new: https://git.openjdk.java.net/jfx/pull/27/files/5a1fbade..afc7f17a

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/27/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/27/webrev.00-01

  Issue: https://bugs.openjdk.java.net/browse/JDK-8230492
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/27/head:pull/27

PR: https://git.openjdk.java.net/jfx/pull/27

RFR: 8231188: Update SQLite to version 3.30.1

[Arun Joseph]

We currently use SQLite version 3.28.0. We should update to the latest stable 
release version 3.30.1 released.
https://www.sqlite.org/index.html



Commits:
 - 24c6375d: 8231188: Update SQLite to version 3.30.1

Changes: https://git.openjdk.java.net/jfx/pull/31/files
 Webrev: https://webrevs.openjdk.java.net/jfx/31/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8231188
  Stats: 7934 lines in 4 files changed: 3028 ins; 734 del; 4172 mod
  Patch: https://git.openjdk.java.net/jfx/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/31/head:pull/31

PR: https://git.openjdk.java.net/jfx/pull/31

RFR: 8234239: [TEST_BUG] Reenable few ignored web tests

[Arun Joseph]

The following tests can be reenabled:

CookieManager.testPutOverwriteExpired
CookieManager.testPutPurgeDomainAfterExpiry
CookieManager.testPutPurgeCookiesGlobally2
CookieManager.testPutPurgeCookiesGlobally3
CookieManager.testPutPurgeCookiesGloballyAfterExpiry
CallbackTest.testCustomPopup
CallbackTest.testDefaultPopup
LeakTest.testGarbageCollectability
LeakTest.testOleg
MiscellaneousTest.testRT30835



Commits:
 - f2f121d9: 8234239: Reenable few ignored web tests

Changes: https://git.openjdk.java.net/jfx/pull/42/files
 Webrev: https://webrevs.openjdk.java.net/jfx/42/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234239
  Stats: 20 lines in 4 files changed: 0 ins; 20 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/42.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42

PR: https://git.openjdk.java.net/jfx/pull/42

Re: [Rev 01] RFR: 8234239: [TEST_BUG] Reenable few ignored web tests

[Arun Joseph]

The pull request has been updated with additional changes.



Added commits:
 - ca460353: Remove ignore imports and update copyright

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/42/files
  - new: https://git.openjdk.java.net/jfx/pull/42/files/f2f121d9..ca460353

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/42/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/42/webrev.00-01

  Issue: https://bugs.openjdk.java.net/browse/JDK-8234239
  Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/42.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42

PR: https://git.openjdk.java.net/jfx/pull/42

Re: [Rev 02] RFR: 8234239: [TEST_BUG] Reenable few ignored web tests

[Arun Joseph]

The pull request has been updated with additional changes.



Added commits:
 - 8c2b988d: Modified LeakTest.testOleg

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/42/files
  - new: https://git.openjdk.java.net/jfx/pull/42/files/ca460353..8c2b988d

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/42/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/42/webrev.01-02

  Issue: https://bugs.openjdk.java.net/browse/JDK-8234239
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/42.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42

PR: https://git.openjdk.java.net/jfx/pull/42

Re: [Rev 01] RFR: 8234239: [TEST_BUG] Reenable few ignored web tests

[Arun Joseph]

On Fri, 15 Nov 2019 23:03:46 GMT, Kevin Rushforth  wrote:

> On Fri, 15 Nov 2019 10:01:51 GMT, Arun Joseph  wrote:
> 
>> The pull request has been updated with additional changes.
>> 
>> 
>> 
>> Added commits:
>>  - ca460353: Remove ignore imports and update copyright
>> 
>> Changes:
>>   - all: https://git.openjdk.java.net/jfx/pull/42/files
>>   - new: https://git.openjdk.java.net/jfx/pull/42/files/f2f121d9..ca460353
>> 
>> Webrevs:
>>  - full: https://webrevs.openjdk.java.net/jfx/42/webrev.01
>>  - incr: https://webrevs.openjdk.java.net/jfx/42/webrev.00-01
>> 
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8234239
>>   Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/42.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/42/head:pull/42
> 
> I added some questions and one requested change below.
> 
> modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 82:
> 
>> 81: }
>> 82: 
>> 83: @Test public void testGarbageCollectability() throws 
>> InterruptedException {
> 
> RT-26710, aka 
> [JDK-8088139](https://bugs.openjdk.java.net/browse/JDK-8088139), is still 
> listed as open. Since these tests no longer hang, can you close 
> [JDK-8088139](https://bugs.openjdk.java.net/browse/JDK-8088139) as "Cannot 
> reproduce"?
> 
> modules/javafx.web/src/test/java/test/javafx/scene/web/LeakTest.java line 58:
> 
>> 57: 
>> 58: @Test public void testOleg() throws InterruptedException{
>> 59: final String URL = new 
>> File("src/test/resources/test/html/guimark2-vector.html").toURI().toASCIIString();
> 
> This test takes 80 seconds (`16 * 5 * 1sec`) to run, which is too long for a 
> simple unit test, when the entire rest of the test suite takes about 5 
> minutes. I recommend decreasing the duration of the key frame to 200 msec, 
> which would allow the test to run in 16 seconds.
> 
> modules/javafx.web/src/test/java/test/javafx/scene/web/CallbackTest.java line 
> 90:
> 
>> 89: 
>> 90: @Test public void testDefaultPopup() {
>> 91: clear();
> 
> This test, along with `testCustomPopup` is listed as unstable. Have you run 
> it multiple times on different systems?
> 
> 
> 
> Changes requested by kcr (Lead).

Yes, I've run the test multiple times in all 3 platforms and it's passing 
everytime.

PR: https://git.openjdk.java.net/jfx/pull/42

RFR: 8234056: Upgrade to libxslt 1.1.34

[Arun Joseph]

We need to update the version of libxslt to the latest version, 1.1.34.



Commits:
 - 2d9c0bf3: 8234056: Upgrade to libxslt 1.1.34

Changes: https://git.openjdk.java.net/jfx/pull/45/files
 Webrev: https://webrevs.openjdk.java.net/jfx/45/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234056
  Stats: 868 lines in 34 files changed: 419 ins; 263 del; 186 mod
  Patch: https://git.openjdk.java.net/jfx/pull/45.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/45/head:pull/45

PR: https://git.openjdk.java.net/jfx/pull/45

RFR: 8210955: DOMTest::testEventListenerCascade fails

[Arun Joseph]

Modified the test to work with WebView's ordering of capturing and bubbling 
event listeners.



Commits:
 - cbef0069: DOMTest::testEventListenerCascade fails

Changes: https://git.openjdk.java.net/jfx/pull/46/files
 Webrev: https://webrevs.openjdk.java.net/jfx/46/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8210955
  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/46.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/46/head:pull/46

PR: https://git.openjdk.java.net/jfx/pull/46

RFR: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute

[Arun Joseph]

Issue: Native part of WebView throws a DOMException and then, continues 
executing the rest of the function assuming that value is present. This causes 
the JVM to crash when retrieving the value.

Fix: Return from the function if exception was raised (code is similar to 
exception handling in 
[WebKitLegacy/java/DOM/JavaTreeWalker.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaTreeWalker.cpp))

This fix also needs to be applied to all function calls in 
[WebKitLegacy/java/DOM](https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM)
 functions which raises DOMError similar to createAttributeImpl().



Commits:
 - acc52780: 8233747: JVM crash in 
com.sun.webkit.dom.DocumentImpl.createAttribute

Changes: https://git.openjdk.java.net/jfx/pull/47/files
 Webrev: https://webrevs.openjdk.java.net/jfx/47/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47

PR: https://git.openjdk.java.net/jfx/pull/47

RFR: 8234593: Mark LeakTest.testGarbageCollectability as unstable

[Arun Joseph]

The test.javafx.scene.web.LeakTest.testGarbageCollectability unit test is 
failing intermittently.



Commits:
 - 1f7c5c8e: 8234593: Mark LeakTest.testGarbageCollectability as unstable

Changes: https://git.openjdk.java.net/jfx/pull/49/files
 Webrev: https://webrevs.openjdk.java.net/jfx/49/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234593
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/49.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/49/head:pull/49

PR: https://git.openjdk.java.net/jfx/pull/49

Re: [Rev 01] RFR: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute

[Arun Joseph]

The pull request has been updated with additional changes.



Added commits:
 - 2bd56c11: Modified only raiseOnDOMError

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/47/files
  - new: https://git.openjdk.java.net/jfx/pull/47/files/acc52780..2bd56c11

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/47/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/47/webrev.00-01

  Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
  Stats: 32 lines in 2 files changed: 24 ins; 6 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47

PR: https://git.openjdk.java.net/jfx/pull/47

Re: RFR: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute

[Arun Joseph]

On Wed, 20 Nov 2019 15:04:07 GMT, Kevin Rushforth  wrote:

> On Wed, 20 Nov 2019 07:05:40 GMT, Arun Joseph  wrote:
> 
>> Issue: Native part of WebView throws a DOMException and then, continues 
>> executing the rest of the function assuming that value is present. This 
>> causes the JVM to crash when retrieving the value.
>> 
>> Fix: Return from the function if exception was raised (code is similar to 
>> exception handling in 
>> [WebKitLegacy/java/DOM/JavaTreeWalker.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaTreeWalker.cpp))
>> 
>> This fix also needs to be applied to all function calls in 
>> [WebKitLegacy/java/DOM](https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM)
>>  functions which raises DOMError similar to createAttributeImpl().
>> 
>> 
>> 
>> Commits:
>>  - acc52780: 8233747: JVM crash in 
>> com.sun.webkit.dom.DocumentImpl.createAttribute
>> 
>> Changes: https://git.openjdk.java.net/jfx/pull/47/files
>>  Webrev: https://webrevs.openjdk.java.net/jfx/47/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
>>   Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/47.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47
> 
> The proposed fix seems more like a workaround to me. There are dozens of very 
> similar calls to `raiseOnDOMError` in this and other files, so I would think 
> a more general solution is needed.

For calls to `raiseOnDOMError()` with argument of type `ExceptionOr>`, 
the returned value is again passed through `WTF::getPtr()`. This doesn't modify 
the value returned, but removing it will require changing about 40 function 
calls.

PR: https://git.openjdk.java.net/jfx/pull/47

Re: [Rev 02] RFR: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute

[Arun Joseph]

The pull request has been updated with additional changes.



Added commits:
 - 7f6ed5bf: Added test for createAttribute

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/47/files
  - new: https://git.openjdk.java.net/jfx/pull/47/files/2bd56c11..7f6ed5bf

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/47/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/47/webrev.01-02

  Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
  Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47

PR: https://git.openjdk.java.net/jfx/pull/47

Re: [Rev 03] RFR: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute

[Arun Joseph]

The pull request has been updated with additional changes.



Added commits:
 - 472d77cf: Added spaces

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/47/files
  - new: https://git.openjdk.java.net/jfx/pull/47/files/7f6ed5bf..472d77cf

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/47/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/47/webrev.02-03

  Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47

PR: https://git.openjdk.java.net/jfx/pull/47

Re: RFR: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute

[Arun Joseph]

On Thu, 28 Nov 2019 13:16:19 GMT, Arun Joseph  wrote:

> On Wed, 20 Nov 2019 15:04:07 GMT, Kevin Rushforth  wrote:
> 
>> On Wed, 20 Nov 2019 07:05:40 GMT, Arun Joseph  wrote:
>> 
>>> Issue: Native part of WebView throws a DOMException and then, continues 
>>> executing the rest of the function assuming that value is present. This 
>>> causes the JVM to crash when retrieving the value.
>>> 
>>> Fix: Return from the function if exception was raised (code is similar to 
>>> exception handling in 
>>> [WebKitLegacy/java/DOM/JavaTreeWalker.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaTreeWalker.cpp))
>>> 
>>> This fix also needs to be applied to all function calls in 
>>> [WebKitLegacy/java/DOM](https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM)
>>>  functions which raises DOMError similar to createAttributeImpl().
>>> 
>>> 
>>> 
>>> Commits:
>>>  - acc52780: 8233747: JVM crash in 
>>> com.sun.webkit.dom.DocumentImpl.createAttribute
>>> 
>>> Changes: https://git.openjdk.java.net/jfx/pull/47/files
>>>  Webrev: https://webrevs.openjdk.java.net/jfx/47/webrev.00
>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8233747
>>>   Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
>>>   Patch: https://git.openjdk.java.net/jfx/pull/47.diff
>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47
>> 
>> The proposed fix seems more like a workaround to me. There are dozens of 
>> very similar calls to `raiseOnDOMError` in this and other files, so I would 
>> think a more general solution is needed.
> 
> For calls to `raiseOnDOMError()` with argument of type `ExceptionOr>`, 
> the returned value is again passed through `WTF::getPtr()`. This doesn't 
> modify the value returned, but removing it will require changing about 40 
> function calls.

In `createAttributeImpl` function in 
[JavaDocument.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaDocument.cpp),
 the value returned from `raiseOnDOMError` is passed to `WTF::getPtr` function. 
Now there are two calls to `WTF::getPtr`, one from `raiseOnDOMError` in the 
return statement and another in `createAttributeImpl`, instead of just one. So, 
this approach has an unnecessary call to `WTF::getPtr` which, if needed, has to 
removed at the `createAttributeImpl` end. This doesn't modify the `Attr` object 
returned because `WTF::getPtr` returns the same pointer when called multiple 
times.

PR: https://git.openjdk.java.net/jfx/pull/47

RFR: 8234471: Canvas in webview displayed with wrong scale on Windows

[Arun Joseph]

This bug can be reproduced when the screen resolution is at 125%, 150% and 175% 
for Windows, which correpsonds to `pixelScale` values of 1.25, 1.5 and 1.75, 
respectively.

Issue: The rectangle inside canvas is rendered on `pixelScale` while the 
borders are rendered on `Math.ceil(pixelScale)`

Fix: Use `Math.ceil(pixelScale)` for calculating `pixelScaleTransform`

-

Commits:
 - fde17b8c: 8234471: Canvas in webview displayed with wrong scale on Windows

Changes: https://git.openjdk.java.net/jfx/pull/62/files
 Webrev: https://webrevs.openjdk.java.net/jfx/62/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234471
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/62/head:pull/62

PR: https://git.openjdk.java.net/jfx/pull/62

Re: RFR: 8233942: Update to 609.1 version of WebKit

[Arun Joseph]

On Mon, 20 Jan 2020 16:39:15 GMT, Guru Hb  wrote:

> Updated GTK Webkit 2.26 (609.1) into jfx.

Marked as reviewed by ajoseph (Author).

-

PR: https://git.openjdk.java.net/jfx/pull/91

RFR: 8239454: LLIntData : invalid opcode returned for 16 and 32 bit wide instructions

[Arun Joseph]

With new bytecode format introduced in Webkit 608.1, the unlinked and linked 
bytecodes were replaced by narrow (1-byte operand) and wide (4-byte operand) 
bytecodes. These were extended to narrow, wide16 and wide32 bytecodes in WebKit 
609.1. In narrow instructions, each argument of the opcode has a fixed size of 
1-byte. The same applies for wide 16 and wide32 with 2-byte and 4-byte, 
respectively.

In the Low Level Intepreter (LLInt), each opcode has a corresponding ID 
assigned for narrow, wide16 and wide32 implementation, and the variable 
`numOpcodeIDs` is used to denote the total number of opcodes. The narrow opcode 
IDs are mapped from 0 to (`numOpcodeIDs` - 1). The next `numOpcodeIDs` opcode 
IDs are mapped to wide16 opcodes, and similarly, the next `numOpcodeIDs` to 
wide32 opcodes. The same can be found in 
[LowLevelInterpreter.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LowLevelInterpreter.cpp#L265)
 and also in the autogenerated file `Bytecodes.h`. 

Bug: When `getOpcodeWide(id)` is called in `LLIntData.h`, the value (`id` - 
`numOpcodesIDs`) is returned.

Fix: It's modified to (`id` + `numOpcodesIDs`) in `getOpcodeWide16()` and (`id` 
+ `numOpcodesIDs`*2) in `getOpcodeWide32()`.

-

Commits:
 - eed20431: 8239454: LLIntData : invalid opcode returned for 16 and 32 bit 
wide instructions

Changes: https://git.openjdk.java.net/jfx/pull/115/files
 Webrev: https://webrevs.openjdk.java.net/jfx/115/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8239454
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/115.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/115/head:pull/115

PR: https://git.openjdk.java.net/jfx/pull/115

Re: RFR: 8239109: Update SQLite to version 3.31.1

[Arun Joseph]

On Thu, 20 Feb 2020 05:58:03 GMT, Guru Hb  wrote:

> Updating SQLite to version 3.31.1 (Currently used version is 3.30.1).

Marked as reviewed by ajoseph (Author).

-

PR: https://git.openjdk.java.net/jfx/pull/119

RFR: 8237889: Update libxml2 to version 2.9.10

[Arun Joseph]

We currently use libxml2 version 2.9.9. We should update to the latest stable 
release 2.9.10.

-

Commits:
 - eaf8d1b1: 8237889: Update libxml2 to version 2.9.10

Changes: https://git.openjdk.java.net/jfx/pull/120/files
 Webrev: https://webrevs.openjdk.java.net/jfx/120/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8237889
  Stats: 2942 lines in 70 files changed: 1242 ins; 992 del; 708 mod
  Patch: https://git.openjdk.java.net/jfx/pull/120.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/120/head:pull/120

PR: https://git.openjdk.java.net/jfx/pull/120

Re: [Rev 01] RFR: 8237889: Update libxml2 to version 2.9.10

[Arun Joseph]

> We currently use libxml2 version 2.9.9. We should update to the latest stable 
> release 2.9.10.

The pull request has been updated with 1 additional commit.

-

Added commits:
 - 9c76239b: 8237889: Update libxml2 to version 2.9.10

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/120/files
  - new: https://git.openjdk.java.net/jfx/pull/120/files/eaf8d1b1..9c76239b

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/120/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/120/webrev.00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/120.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/120/head:pull/120

PR: https://git.openjdk.java.net/jfx/pull/120

Re: [Rev 01] RFR: 8234471: Canvas in webview displayed with wrong scale on Windows

[Arun Joseph]

> This bug can be reproduced when the screen resolution is at 125%, 150% and 
> 175% for Windows, which correpsonds to `pixelScale` values of 1.25, 1.5 and 
> 1.75, respectively.
> 
> Issue: The rectangle inside canvas is rendered on `pixelScale` while the 
> borders are rendered on `Math.ceil(pixelScale)`
> 
> Fix: Use `Math.ceil(pixelScale)` for calculating `pixelScaleTransform`

The pull request has been updated with 1 additional commit.

-

Added commits:
 - ea422a78: Added CanvasTest

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/62/files
  - new: https://git.openjdk.java.net/jfx/pull/62/files/fde17b8c..ea422a78

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/62/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/62/webrev.00-01

  Stats: 133 lines in 1 file changed: 133 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/62/head:pull/62

PR: https://git.openjdk.java.net/jfx/pull/62

RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash

[Arun Joseph]

Issue: The stack pointer is checked close to the stack limit during the last 
iteration of calling frameLoaded() and then, grows beyond the thread's stack 
range causing a stack overflow and crashes. This occurs as the stack grows by 
an amount larger than the reserved zone at the end of the stack.

Fix: Reduce the stack range visible to the thread in 
[StackBounds.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/StackBounds.cpp)
 similar to Mac and Linux. This causes the stack pointer check to throw a 
StackOverflowError during the last iteration.

-

Commits:
 - f780c079: 8240211: Stack overflow on Windows 32-bit can lead to crash

Changes: https://git.openjdk.java.net/jfx/pull/137/files
 Webrev: https://webrevs.openjdk.java.net/jfx/137/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8240211
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/137.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/137/head:pull/137

PR: https://git.openjdk.java.net/jfx/pull/137

Re: RFR: 8239107: Update libjpeg to version 9d

[Arun Joseph]

On Thu, 12 Mar 2020 10:43:37 GMT, Ambarish Rapte  wrote:

> Currently we use IJG libjpeg version 9c released on 14-Jan-2018
> We should update the libjpeg to latest version [9d](http://www.ijg.org/) 
> released on 12-Jan-2020
> 
> reference: https://jpegclub.org/reference/reference-sources/

Marked as reviewed by ajoseph (Author).

-

PR: https://git.openjdk.java.net/jfx/pull/143

Re: [Rev 02] RFR: 8234471: Canvas in webview displayed with wrong scale on Windows

[Arun Joseph]

> This bug can be reproduced when the screen resolution is at 125%, 150% and 
> 175% for Windows, which correpsonds to
> `pixelScale` values of 1.25, 1.5 and 1.75, respectively.
> Issue: The rectangle inside canvas is rendered on `pixelScale` while the 
> borders are rendered on `Math.ceil(pixelScale)`
> 
> Fix: Use `Math.ceil(pixelScale)` for calculating `pixelScaleTransform`

Arun Joseph has updated the pull request incrementally with one additional 
commit since the last revision:

  Updated test

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/62/files
  - new: https://git.openjdk.java.net/jfx/pull/62/files/ea422a78..eadff865

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/62/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/62/webrev.01-02

  Stats: 13 lines in 1 file changed: 8 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/62/head:pull/62

PR: https://git.openjdk.java.net/jfx/pull/62

RFR: 8242209: Increase web native thread stack size for x86 mode

[Arun Joseph]

CLoop interpreter used in 32-bit Windows uses 87 KB of stack space each time 
CLoop::execute() is called. For web native
threads which has a default stack size of 320 KB, a Stack Overflow Error is 
raised just after two calls to execute()
function. While 64-bit windows has a default stack size of 1 MB.

Fix: Increase the thread stack size of web native threads for x86 to 1 MB.

-

Commit messages:
 - 8242209: Increase web native thread stack size for x86 mode

Changes: https://git.openjdk.java.net/jfx/pull/159/files
 Webrev: https://webrevs.openjdk.java.net/jfx/159/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242209
  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/159.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/159/head:pull/159

PR: https://git.openjdk.java.net/jfx/pull/159

Re: RFR: WIP: 8230231: font-family not updated in HTMLEditor

[Arun Joseph]

On Wed, 12 Feb 2020 20:34:55 GMT, Kevin Rushforth  wrote:

>> I have indeed let this bug on the side. I would like to investigate but my 
>> time is limited these days. Especially that
>> my patch is apparently creating another issue. I will try to give it another 
>> shot in the upcoming week. But if anyone
>> has some ideas or is willing to carry the issue, feel free
>
> No hurry. I was just going through PRs that hadn't been updated in a while.

The second issue regarding selecting texts with multiple fonts will be fixed 
when
https://github.com/openjdk/jfx/pull/155 is merged.

-

PR: https://git.openjdk.java.net/jfx/pull/12

Re: RFR: 8230809: HTMLEditor formatting lost when selecting all (CTRL-A)

[Arun Joseph]

On Wed, 1 Apr 2020 10:49:22 GMT, Ajit Ghaisas  wrote:

> Bug : https://bugs.openjdk.java.net/browse/JDK-8230809
> 
> Root Cause :
> Turned out to be a simpler issue than thought.
> Atomicity check was missed while updating toolbar state (which in turn 
> updates styles).
> 
> Fix :
> Added the missed atomicity check at two places that handle text selection 
> using keyboard keys.
> 
> Testing :
> Added two system test cases. They fail without this fix and pass with it.

Marked as reviewed by ajoseph (Author).

-

PR: https://git.openjdk.java.net/jfx/pull/155

RFR: 8223298: SVG patterns are drawn wrong

[Arun Joseph]

Issue: Assuming the pixelScale is 2, the tile image size is doubled at the 
native side which is propagated to the java
side as well. But, as transform initialization takes place after scaling, the 
transform is reset to default value.

Fix: Override scale() method in WCBufferedContext class to call init() before 
scaling.

-

Commit messages:
 - 8223298: SVG patterns are drawn wrong

Changes: https://git.openjdk.java.net/jfx/pull/164/files
 Webrev: https://webrevs.openjdk.java.net/jfx/164/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8223298
  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/164.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/164/head:pull/164

PR: https://git.openjdk.java.net/jfx/pull/164

Re: [Rev 01] RFR: 8223298: SVG patterns are drawn wrong

[Arun Joseph]

> Issue: Assuming the pixelScale is 2, the tile image size is doubled at the 
> native side which is propagated to the java
> side as well. But, as transform initialization takes place after scaling, the 
> transform is reset to default value.
> Fix: Override scale() method in WCBufferedContext class to call init() before 
> scaling.

Arun Joseph has updated the pull request incrementally with one additional 
commit since the last revision:

  Update copyright year

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/164/files
  - new: https://git.openjdk.java.net/jfx/pull/164/files/ea66bca2..fb1c3934

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/164/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/164/webrev.00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/164.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/164/head:pull/164

PR: https://git.openjdk.java.net/jfx/pull/164

Re: [Rev 02] RFR: 8223298: SVG patterns are drawn wrong

[Arun Joseph]

> Issue: Assuming the pixelScale is 2, the tile image size is doubled at the 
> native side which is propagated to the java
> side as well. But, as transform initialization takes place after scaling, the 
> transform is reset to default value.
> Fix: Override scale() method in WCBufferedContext class to call init() before 
> scaling.

Arun Joseph has updated the pull request incrementally with one additional 
commit since the last revision:

  Added SVGTest

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/164/files
  - new: https://git.openjdk.java.net/jfx/pull/164/files/fb1c3934..86674653

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/164/webrev.02
 - incr: https://webrevs.openjdk.java.net/jfx/164/webrev.01-02

  Stats: 132 lines in 1 file changed: 132 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/164.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/164/head:pull/164

PR: https://git.openjdk.java.net/jfx/pull/164

FYI: 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern

[Arun Joseph]

SVGTest.testSVGRenderingWithPattern is failing frequently due to
[JDK-8243110](https://bugs.openjdk.java.net/browse/JDK-8243110). We should skip 
this test until it is fixed.

-

Commit messages:
 - 8243112: Skip failing test SVGTest.testSVGRenderingWithPattern

Changes: https://git.openjdk.java.net/jfx/pull/188/files
 Webrev: https://webrevs.openjdk.java.net/jfx/188/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243112
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/188.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/188/head:pull/188

PR: https://git.openjdk.java.net/jfx/pull/188

RFR: 8242861: Update ImagePattern to apply SVG pattern transforms

[Arun Joseph]

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.

-

Commit messages:
 - Change order of translate
 - Minimal fix
 - Remove unwanted changes
 - Implement setFillPattern
 - Implement setPattern
 - Create WCPattern
 - Add patternTransform in ImagePattern

Changes: https://git.openjdk.java.net/jfx/pull/190/files
 Webrev: https://webrevs.openjdk.java.net/jfx/190/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242861
  Stats: 50 lines in 3 files changed: 32 ins; 11 del; 7 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: [Rev 01] RFR: 8242861: Update ImagePattern to apply SVG pattern transforms

[Arun Joseph]

> 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:

  Add CanvasTest

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/190/files
  - new: https://git.openjdk.java.net/jfx/pull/190/files/c1066e95..76e4745d

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/190/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/190/webrev.00-01

  Stats: 58 lines in 1 file changed: 58 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

RFR: 8171898: [WebView] ScrollBarWidget thickness calculation is not correct

[Arun Joseph]

After [JDK-8157900](https://bugs.openjdk.java.net/browse/JDK-8157900), 
initializeThickness() moved from
ScrollBarThemeImpl to ScrollBarWidget but the implementation was kept the same 
by using testSBRef to call
setThickness() for setting ScrollBarTheme.thickness.

Modifying initializeThickness() to set ScrollBarTheme.thickness once and 
removing testSBRef.

-

Commit messages:
 - 8171898: [WebView] ScrollBarWidget thickness calculation is not correct

Changes: https://git.openjdk.java.net/jfx/pull/197/files
 Webrev: https://webrevs.openjdk.java.net/jfx/197/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8171898
  Stats: 22 lines in 2 files changed: 0 ins; 15 del; 7 mod
  Patch: https://git.openjdk.java.net/jfx/pull/197.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/197/head:pull/197

PR: https://git.openjdk.java.net/jfx/pull/197

Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms

[Arun Joseph]

On Mon, 27 Apr 2020 23:56:37 GMT, Kevin Rushforth  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.
>
> Since this is in a common method used by all shapes, and not just WebView, we 
> will need to ensure no regressions.

All ImagePattern objects, other than the one from WebView, uses the second 
constructor which assigns an identity
transform as the pattern transform. So, existing calls to PaintHelper 
concatenates the shader transform with an
identity matrix and thus, shouldn't cause any regressions. Only calls from 
WebView's drawPattern() method in
WCGraphicsPrismContext uses the patternTransform attribute.

-

PR: https://git.openjdk.java.net/jfx/pull/190

Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms

[Arun Joseph]

On Wed, 29 Apr 2020 06:45:04 GMT, Arun Joseph  wrote:

>> Since this is in a common method used by all shapes, and not just WebView, 
>> we will need to ensure no regressions.
>
> All ImagePattern objects, other than the one from WebView, uses the second 
> constructor which assigns an identity
> transform as the pattern transform. So, existing calls to PaintHelper 
> concatenates the shader transform with an
> identity matrix and thus, shouldn't cause any regressions. Only calls from 
> WebView's drawPattern() method in
> WCGraphicsPrismContext uses the patternTransform attribute.

The changes in drawPattern() forces the function to handle the operations for 
drawPattern (for images) and fillPattern
(for shapes) together. If required, a new opcode SET_FILL_PATTERN can be 
introduced for handling patterns in shapes and
part of the implementation can be seen from my previous commits to this PR.

-

PR: https://git.openjdk.java.net/jfx/pull/190

Re: RFR: 8171898: [WebView] ScrollBarWidget thickness calculation is not correct

[Arun Joseph]

On Tue, 28 Apr 2020 21:41:19 GMT, Kevin Rushforth  wrote:

>> ScrollbarThemeJava delegates scrollbar thickness calculation to 
>> ScrollBarWidget::initializeThickness()
>> [ScrollBarWidget.java] method. Since 
>> "ScrollbarThemeJava::scrollbarThickness" is not associated with any
>> "ScrollBarWidget" instance, some workaround was made using special 
>> "ScrollBarWidget" instance named testRef.
>
> While this might be the right fix, I don't think the evaluation is right. In 
> particular, this doesn't look related to
> [JDK-8157900](https://bugs.openjdk.java.net/browse/JDK-8157900). That 
> refactoring fix was behavior neutral in terms of
> the object graph -- it uses an accessor pattern rather than the removed 
> public `impl_` methods for encapsulation, but
> intentionally didn't change anything related to which instance of which 
> objects are used. That fix was not backported
> to 8u and yet this bug is listed as affecting 8u.  So, what I'd like to see 
> in the evaluation is a description of the
> root cause, and a brief explanation of the fix.  Can you also provide a test 
> case that fails without the fix and passes
> with the fix? I don't see one in JBS that you can leverage, so you may need 
> to create one.

This PR aims at modifying initializeThickness() to not use testSBRef and so, 
doesn't change the behavior of
ScrollBarWidget. As it's not a bug, test case can't be created.

-

PR: https://git.openjdk.java.net/jfx/pull/197

Re: [Rev 03] RFR: 8191758: Match WebKit's font weight rendering with JavaFX

[Arun Joseph]

On Wed, 29 Apr 2020 14:01:50 GMT, Bhawesh Choudhary 
 wrote:

>> As per JavaFx 700 font weight is considered to be bold but webkit is using 
>> 600 font weight for text to become bold. to
>> fix issue, use boldWeightValue() function which uses 700 font weight rather 
>> than isFontWeightBold() which compare
>> against 600 font weight.
>
> Bhawesh Choudhary has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   style format changes

Marked as reviewed by ajoseph (Committer).

-

PR: https://git.openjdk.java.net/jfx/pull/180

Re: [Closed] RFR: 8171898: [WebView] ScrollBarWidget thickness calculation is not correct

[Arun Joseph]

On Mon, 27 Apr 2020 08:17:50 GMT, Arun Joseph  wrote:

> ScrollbarThemeJava delegates scrollbar thickness calculation to 
> ScrollBarWidget::initializeThickness()
> [ScrollBarWidget.java] method. Since "ScrollbarThemeJava::scrollbarThickness" 
> is not associated with any
> "ScrollBarWidget" instance, some workaround was made using special 
> "ScrollBarWidget" instance named testRef.

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jfx/pull/197

Re: [Rev 02] RFR: 8218973: SVG with masking is not rendering image with mask effect

[Arun Joseph]

On Sun, 10 May 2020 20:49:07 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:
> 
>   Moved Printing drawing path to non MaskTextureGraphics interface

modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java
 line 560:

> 559: } else {
> 560: Screen screen = g.getAssociatedScreen();
> 561: FilterContext filterContext;

This logic is already present in getFilterContext(). You can call the function 
instead.

-

PR: https://git.openjdk.java.net/jfx/pull/213

Re: [Rev 03] RFR: 8218973: SVG with masking is not rendering image with mask effect

[Arun Joseph]

On Mon, 18 May 2020 08:00:38 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:
> 
>   Refactoring, Utilize getFilterContext() function

modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java
 line 536:

> 535: RTTexture paintRtTexture = 
> g.getResourceFactory().createRTTexture(
> 536: (int) Math.ceil(transformedRect.width),
> 537: (int) Math.ceil(transformedRect.height),

transformedRect's height and width are already of type int

-

PR: https://git.openjdk.java.net/jfx/pull/213

RFR: 8244579: Windows "User Objects" leakage with WebView

[Arun Joseph]

Cause: The Window Class `RunLoopMessageWindow` is never registered (this 
happens because
registerRunLoopMessageWindowClass() is moved to MainThreadWin.cpp while openjfx 
uses MainThreadJava.cpp) and this
causes every setTimer() to create a new user object instead of reusing the same 
object over again.

Fix: Call registerRunLoopMessageWindowClass() from MainThreadJava.cpp

Test: To verify open any webpage using WebView on WIndows, with and without the 
fix and compare the number of user
objects created using Windows Task Manager.

-

Commit messages:
 - 8244579: Windows "User Objects" leakage with WebView

Changes: https://git.openjdk.java.net/jfx/pull/229/files
 Webrev: https://webrevs.openjdk.java.net/jfx/229/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244579
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/229.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/229/head:pull/229

PR: https://git.openjdk.java.net/jfx/pull/229

Re: RFR: 8244579: Windows "User Objects" leakage with WebView

[Arun Joseph]

On Wed, 20 May 2020 15:16:11 GMT, Kevin Rushforth  wrote:

>> Cause: The Window Class `RunLoopMessageWindow` is never registered (this 
>> happens because
>> registerRunLoopMessageWindowClass() is moved to MainThreadWin.cpp while 
>> openjfx uses MainThreadJava.cpp) and this
>> causes every SetTimer() call in
>> [RunLoopWin.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/win/RunLoopWin.cpp)
>> to create a new user object instead of reusing the same object over again.  
>> Fix: Call
>> registerRunLoopMessageWindowClass() from MainThreadJava.cpp  Test: To verify 
>> open any webpage using WebView on WIndows,
>> with and without the fix and compare the number of user objects created 
>> using Windows Task Manager.
>
> Is there a way to create a test?

I think it will be difficult to write a test for this. While debugging, RunLoop 
was mostly used by threads managing
heap. It can't be directly accessed via JavaScript. Also, this issue only 
affects Windows. The best way would be to
monitor the user objects created.

-

PR: https://git.openjdk.java.net/jfx/pull/229

Re: [Integrated] RFR: 8244579: Windows "User Objects" leakage with WebView

[Arun Joseph]

On Wed, 20 May 2020 14:30:11 GMT, Arun Joseph  wrote:

> Cause: The Window Class `RunLoopMessageWindow` is never registered (this 
> happens because
> registerRunLoopMessageWindowClass() is moved to MainThreadWin.cpp while 
> openjfx uses MainThreadJava.cpp) and this
> causes every SetTimer() call in
> [RunLoopWin.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/win/RunLoopWin.cpp)
> to create a new user object instead of reusing the same object over again.  
> Fix: Call
> registerRunLoopMessageWindowClass() from MainThreadJava.cpp  Test: To verify 
> open any webpage using WebView on WIndows,
> with and without the fix and compare the number of user objects created using 
> Windows Task Manager.

This pull request has now been integrated.

Changeset: a13a642d
Author:Arun Joseph 
URL:   https://git.openjdk.java.net/jfx/commit/a13a642d
Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8244579: Windows "User Objects" leakage with WebView

Reviewed-by: ghb, kcr

-

PR: https://git.openjdk.java.net/jfx/pull/229

RFR: 8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

[Arun Joseph]

Cause: The test assumes that WebView/WebPage will be GCed right after 
`System.gc()`

Fix: Use `runFinalization()` and `sleep()` to wait for objects to get GCed

-

Commit messages:
 - Update copyright year
 - Remove unwanted line
 - 8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

Changes: https://git.openjdk.java.net/jfx/pull/236/files
 Webrev: https://webrevs.openjdk.java.net/jfx/236/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234540
  Stats: 33 lines in 1 file changed: 7 ins; 15 del; 11 mod
  Patch: https://git.openjdk.java.net/jfx/pull/236.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/236/head:pull/236

PR: https://git.openjdk.java.net/jfx/pull/236

Re: [Integrated] RFR: 8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

[Arun Joseph]

On Tue, 26 May 2020 09:27:52 GMT, Arun Joseph  wrote:

> Cause: The test assumes that WebView/WebPage will be GCed right after 
> `System.gc()`
> 
> Fix: Use `runFinalization()` and `sleep()` to wait for objects to get GCed

This pull request has now been integrated.

Changeset: 8914bd2a
Author:    Arun Joseph 
URL:   https://git.openjdk.java.net/jfx/commit/8914bd2a
Stats: 33 lines in 1 file changed: 15 ins; 7 del; 11 mod

8234540: javafx.web LeakTest.testGarbageCollectability fails intermittently

Reviewed-by: kcr

-

PR: https://git.openjdk.java.net/jfx/pull/236

RFR: 8243110: SVGTest.testSVGRenderingWithPattern fails intermittently

[Arun Joseph]

Issue: Snapshot taken before webpage is rendered

Fix: Use stateProperty and sleep to wait for the page to finish rendering

-

Commit messages:
 - Add sleep
 - 8243110: SVGTest.testSVGRenderingWithPattern fails intermittently

Changes: https://git.openjdk.java.net/jfx/pull/240/files
 Webrev: https://webrevs.openjdk.java.net/jfx/240/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243110
  Stats: 18 lines in 1 file changed: 15 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/240.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/240/head:pull/240

PR: https://git.openjdk.java.net/jfx/pull/240

Re: [Rev 01] RFR: 8243110: SVGTest.testSVGRenderingWithPattern fails intermittently

[Arun Joseph]

> Issue: Snapshot taken before webpage is rendered
> 
> Fix: Use stateProperty and sleep to wait for the page to finish rendering

Arun Joseph has updated the pull request incrementally with one additional 
commit since the last revision:

  Review comments

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/240/files
  - new: https://git.openjdk.java.net/jfx/pull/240/files/211a1f65..4195f0fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/240/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/240/webrev.00-01

  Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/240.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/240/head:pull/240

PR: https://git.openjdk.java.net/jfx/pull/240

Re: [Integrated] RFR: 8243110: SVGTest.testSVGRenderingWithPattern fails intermittently

[Arun Joseph]

On Thu, 28 May 2020 08:45:36 GMT, Arun Joseph  wrote:

> Issue: Snapshot taken before webpage is rendered
> 
> Fix: Use stateProperty and sleep to wait for the page to finish rendering

This pull request has now been integrated.

Changeset: 9edba9cc
Author:Arun Joseph 
URL:   https://git.openjdk.java.net/jfx/commit/9edba9cc
Stats: 19 lines in 1 file changed: 3 ins; 16 del; 0 mod

8243110: SVGTest.testSVGRenderingWithPattern fails intermittently

Reviewed-by: kcr

-

PR: https://git.openjdk.java.net/jfx/pull/240

Re: CFV: New OpenJFX Committer: Jeanette Winzenburg

[Arun Joseph]

Vote: YES

— Arun Joseph

> On 01-Jun-2020, at 7:22 PM, Kevin Rushforth  
> wrote:
> 
> I hereby nominate Jeanette Winzenburg [1] to OpenJFX Committer.
> 
> Jeanette is an OpenJFX community member, who has contributed 16 changesets 
> [2][3] to OpenJFX.
> 
> Votes are due by June 15, 2020.
> 
> Only current OpenJFX Committers [4] 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 [5]. Nomination to a project 
> Committer is described in [6].
> 
> Thanks.
> 
> -- Kevin
> 
> 
> [1] https://openjdk.java.net/census#fastegal
> 
> [2] 
> https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits
> 
> [3] 
> https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits
> 
> [4] https://openjdk.java.net/census#openjfx
> 
> [5] https://openjdk.java.net/bylaws#lazy-consensus
> 
> [6] https://openjdk.java.net/projects#project-committer
> 

Re: CFV: New OpenJFX Committer: Jose Pereda

[Arun Joseph]

Vote: YES

— Arun Joseph

> On 01-Jun-2020, at 7:23 PM, Kevin Rushforth  
> wrote:
> 
> I hereby nominate Jose Pereda [1] to OpenJFX Committer.
> 
> Jose is an OpenJFX community member, who has contributed 16 changesets [2][3] 
> to OpenJFX.
> 
> Votes are due by June 15, 2020.
> 
> Only current OpenJFX Committers [4] 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 [5]. Nomination to a project 
> Committer is described in [6].
> 
> Thanks.
> 
> -- Kevin
> 
> 
> [1] https://openjdk.java.net/census#jpereda
> 
> [2] 
> https://github.com/openjdk/jfx/search?q=author-email%3Ajpereda%40openjdk.org&s=author-date&type=Commits
> 
> [3] 
> https://github.com/openjdk/jfx/search?q=author-email%3Ajose.pereda%40gluonhq.com&s=author-date&type=Commits
> 
> [4] https://openjdk.java.net/census#openjfx
> 
> [5] https://openjdk.java.net/bylaws#lazy-consensus
> 
> [6] https://openjdk.java.net/projects#project-committer
> 

Re: RFR: 8246357: Allow static build of webkit library on linux

[Arun Joseph]

On Tue, 2 Jun 2020 17:52:37 GMT, Johan Vos  wrote:

> add changes to build a static version of libjfxwebkit.a
> Fox for JDK-8246357

Changes looks good to me.

-

Marked as reviewed by ajoseph (Committer).

PR: https://git.openjdk.java.net/jfx/pull/245

Re: [Rev 02] RFR: 8208169: can not print selected pages of web page

[Arun Joseph]

On Sun, 14 Jun 2020 19:13:41 GMT, Bhawesh Choudhary 
 wrote:

>> Print function of WebEngine.java ignores page range setting and prints given 
>> number of pages starting from first page,
>> which is the root cause of this issue. To fix it, put check for page ranges 
>> and if it available, use it for printing
>> pages otherwise print all pages as usual.
>
> Bhawesh Choudhary has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Replaced webpage with locally generated html content in test

tests/manual/printing/PrintPageRangeTest.java line 80:

> 79:
> 80: static final String initialURL = 
> "https://en.wikipedia.org/wiki/Java_version_history";;
> 81:

initialURL is no longer required

-

PR: https://git.openjdk.java.net/jfx/pull/222

RFR: 8247963: Update SQLite to version 3.32.3

[Arun Joseph]

We currently use SQLite version 3.31.1. We should update to the latest stable 
release version 3.32.3 released on
2020-06-18. https://www.sqlite.org/index.html

-

Commit messages:
 - 8247963: Update SQLite to version 3.32.3

Changes: https://git.openjdk.java.net/jfx/pull/261/files
 Webrev: https://webrevs.openjdk.java.net/jfx/261/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247963
  Stats: 4409 lines in 4 files changed: 2488 ins; 1057 del; 864 mod
  Patch: https://git.openjdk.java.net/jfx/pull/261.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/261/head:pull/261

PR: https://git.openjdk.java.net/jfx/pull/261

Integrated: 8247963: Update SQLite to version 3.32.3

[Arun Joseph]

On Wed, 1 Jul 2020 17:14:30 GMT, Arun Joseph  wrote:

> We currently use SQLite version 3.31.1. We should update to the latest stable 
> release version 3.32.3 released on
> 2020-06-18. https://www.sqlite.org/index.html

This pull request has now been integrated.

Changeset: f3a04465
Author:Arun Joseph 
URL:   https://git.openjdk.java.net/jfx/commit/f3a04465
Stats: 4413 lines in 4 files changed: 1061 ins; 2492 del; 860 mod

8247963: Update SQLite to version 3.32.3

Reviewed-by: kcr, ghb

-

PR: https://git.openjdk.java.net/jfx/pull/261

RFR: 8245284: Update to 610.1 version of WebKit

[Arun Joseph]

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

Integrated: 8245284: Update to 610.1 version of WebKit

[Arun Joseph]

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

Re: RFR: 8242861: Update ImagePattern to apply SVG pattern transforms [v3]

[Arun Joseph]

> 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

RFR: 8249839: Cherry pick GTK WebKit 2.28.3 changes

[Arun Joseph]

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: 8218973: SVG with masking is not rendering image with mask effect [v6]

[Arun Joseph]

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

Integrated: 8249839: Cherry pick GTK WebKit 2.28.3 changes

[Arun Joseph]

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: [jfx15] RFR: 8246343: Fix mistakes in FX API docs [v4]

[Arun Joseph]

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

Re: RFR: 8181775: JavaFX WebView does not calculate border-radius properly [v4]

[Arun Joseph]

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: RFR: 8240969: WebView does not allow to load style sheet in modularized applications [v4]

[Arun Joseph]

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: 8242861: Update ImagePattern to apply SVG pattern transforms [v4]

[Arun Joseph]

> 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: 8242861: Update ImagePattern to apply SVG pattern transforms [v5]

[Arun Joseph]

> 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