HTMLEditor customization

Tom Eugelink tbee at tbee.org
Wed Jul 24 18:55:54 UTC 2024


insertHTML has the same peculiar behavior.

I've added a button to the toolbar that calls insertHTML/insertImage with an embedded image.
- click at the end of the html, click button: call is unsuccessful (returns false)
- click at the end of the html, click button: call is successful (returns true, image is added)
- click at the end of the html, click button: call is unsuccessful (returns false)
- click at the end of the html, click button: call is successful (returns true, image is added)
...

It does not matter if it is an img-tag or a p-tag or whatever, the alternating behavior is the same. Also multiple clicks make no difference, all of them either fail or succeed, it is the regaining of the focus of the WebPage that makes the difference. It can be any component that the focus is lost to, but webview.requestFocus is not enough (it does not really place the focus back to the webpage, e.g. the toolbar buttons stay disabled).

Interestingly, when the insert*-commands succeed, the webpage.getHtml call returns an empty string, and when they fail you get the actual HTML. But for the rest none of the webPage methods make a difference.

It would be nice to understand why the wrapped browser alternates between two states.



On 2024-07-24 09:15, Tom Eugelink wrote:
> Apparently I had checked out an old repository where that code was missing. Should have looked again in the URL before posting.
>
> Anyhow, I've progressed to the point where I can insert an image using the W3C insertImage command. Works fine, but it is picky when it can be executed. However, the queryCommandEnabled does not return a correct value; the true or false does not actually match whether the insertImage command will succeed. The value is only correct after focus is moved out of the WebView, but that doesn't work practically (you can hardly bounce the focus after every keystroke).
>
> I'll give the insertHtml command a try.
>
>
> On 2024-07-22 17:27, Andy Goryachev wrote:
>>
>> /**
>>
>>      * Represents commands that can be passed into the HTMLEditor web engine.
>>
>>      */
>>
>> publicenumCommand {
>>
>> line 1167
>>
>> -andy
>>
>> *From: *openjfx-discuss <openjfx-discuss-retn at openjdk.org> on behalf of Tom Eugelink <tbee at tbee.org>
>> *Date: *Saturday, July 20, 2024 at 00:21
>> *To: *openjfx-discuss at openjdk.org <openjfx-discuss at openjdk.org>
>> *Subject: *Re: HTMLEditor customization
>>
>> It seems those 10 year old hacks are not working anymore. All of the 'selection' objects in javascript appear to be either null, or unwilling to return a range.
>>
>> The other approach would be to extend the HTMLEditor implementation, because why not? While investigating that approach I got confused:
>> https://github.com/javafxports/openjdk-jfx/blob/develop/modules/javafx.web/src/main/java/javafx/scene/web/HTMLEditorSkin.java
>> import static javafx.scene.web.HTMLEditorSkin.Command.*;
>>
>> Where did the Command enum hide? It should be in the HTMLEditorSkin class?
>>
>>
>> On 2024-07-19 07:37, Tom Eugelink wrote:
>> > I was wondering; is the HTML editor still at the point where any customization is done by executing javascript code via the WebEngine? I find some 10 year old or so articles on how to insert things at the cursor position using that approach. And inserting additional buttons in the toolbar by finding it via its CSS class?
>> >
>> > Because the vanilla version of the HTML editor is limited; no image support and all.
>> >
>> > Regards, Tom
>> >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-discuss/attachments/20240724/28e2c047/attachment-0001.htm>


More information about the openjfx-discuss mailing list