On Thu, 21 Apr 2022 08:38:20 GMT, Robert Lichtenberger
wrote:
> Separate test class added for TreeTableView case.
> Fix is analogous to JDK-8251480.
This pull request has now been integrated.
Changeset: 18b2366f
Author:Robert Lichtenberger
Committer: Ajit Ghaisas
URL:
On Thu, 12 May 2022 05:22:38 GMT, Ajit Ghaisas wrote:
>> Robert Lichtenberger has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8285197: TableColumnHeader: calc of cell width must respect row st
On Thu, 21 Apr 2022 08:38:20 GMT, Robert Lichtenberger
wrote:
> Separate test class added for TreeTableView case.
> Fix is analogous to JDK-8251480.
Finally found the time to cleanup the test class...
-
PR: https://git.openjdk.java.net/jfx/pull/779
> Separate test class added for TreeTableView case.
> Fix is analogous to JDK-8251480.
Robert Lichtenberger has updated the pull request incrementally with two
additional commits since the last revision:
- 8285197: TableColumnHeader: calc of cell width must respect row styling
(TreeTab
Separate test class added for TreeTableView case.
Fix is analogous to JDK-8251480.
-
Commit messages:
- 8285197: TableColumnHeader: calc of cell width must respect row styling
(TreeTableView)
Changes: https://git.openjdk.java.net/jfx/pull/779/files
Webrev:
On Tue, 19 Apr 2022 09:57:58 GMT, Marius Hanl wrote:
>>> @effad Do you have time and interest to take a look at this for the
>>> `TreeTableView` as well? Just asking as otherwise I will have a look :)
>>
>> Sorry for late response (extended easter holidays ...). Yes I could also
>> take a
On Wed, 16 Mar 2022 13:01:45 GMT, Robert Lichtenberger
wrote:
>> Might make sense to also adjust the TreeTableView sizing implementation?
>
>> Might make sense to also adjust the TreeTableView sizing implementation?
>
> Yes I think that may be a good idea. True to the ide
On Wed, 16 Mar 2022 08:20:59 GMT, Robert Lichtenberger
wrote:
> This fix respects a row factory, if present.
> It will put the cell that is used to measure the column width as child below
> the row.
> In that way the row's style will be used.
This pull request has now bee
On Tue, 22 Mar 2022 14:42:07 GMT, Robert Lichtenberger
wrote:
> findSibling adapted to only use visible menus when calculating the
> index.
This pull request has now been integrated.
Changeset: cff84e24
Author:Robert Lichtenberger
Committer: Ajit Ghaisas
URL:
> This fix respects a row factory, if present.
> It will put the cell that is used to measure the column width as child below
> the row.
> In that way the row's style will be used.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the l
On Wed, 30 Mar 2022 12:10:19 GMT, Kevin Rushforth wrote:
>> I found assertions in various other parts of the code (e.g.
>> `javafx.scene.control.skin.VirtualFlow`) so I assumed this is ok.
>
> Some old code has assertions, but library code should not use them. Please
> delete them from any new
> This fix respects a row factory, if present.
> It will put the cell that is used to measure the column width as child below
> the row.
> In that way the row's style will be used.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the l
On Tue, 29 Mar 2022 20:35:10 GMT, Marius Hanl wrote:
>> Robert Lichtenberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8251480: TableColumnHeader: calc of cell width must respect row styling
>>
> findSibling adapted to only use visible menus when calculating the
> index.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the last revision:
8251480: TableColumnHeader: calc of cell width must respect row styling
Comment im
On Wed, 30 Mar 2022 04:48:30 GMT, Ajit Ghaisas wrote:
>
> Only one minor correction needed is in comment.
Right. Just pushed a correction.
-
PR: https://git.openjdk.java.net/jfx/pull/759
On Tue, 29 Mar 2022 09:23:24 GMT, Ajit Ghaisas wrote:
> Have you considered keeping the same while loop in findSibling() method and
> skipping invisible Menus in it? This is to avoid creating and traversing a
> new list.
This would not give the correct result. findSibling must return the
> This fix respects a row factory, if present.
> It will put the cell that is used to measure the column width as child below
> the row.
> In that way the row's style will be used.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the l
On Wed, 23 Mar 2022 08:15:47 GMT, Marius Hanl wrote:
>> This fix respects a row factory, if present.
>> It will put the cell that is used to measure the column width as child below
>> the row.
>> In that way the row's style will be used.
>
>
On Wed, 23 Mar 2022 08:17:38 GMT, Marius Hanl wrote:
>> This fix respects a row factory, if present.
>> It will put the cell that is used to measure the column width as child below
>> the row.
>> In that way the row's style will be used.
>
>
On Wed, 23 Mar 2022 08:19:41 GMT, Marius Hanl wrote:
>> This fix respects a row factory, if present.
>> It will put the cell that is used to measure the column width as child below
>> the row.
>> In that way the row's style will be used.
>
>
findSibling adapted to only use visible menus when calculating the
index.
-
Commit messages:
- 8283509: Invisible menus can lead to IndexOutOfBoundsException
Changes: https://git.openjdk.java.net/jfx/pull/759/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx=759=00
Issue:
On Wed, 16 Mar 2022 11:46:07 GMT, Marius Hanl wrote:
> Might make sense to also adjust the TreeTableView sizing implementation?
Yes I think that may be a good idea. True to the idea of specific, narrow
commits I've not integrated this into this PR but would be willing to open a
new issue /
This fix respects a row factory, if present.
It will put the cell that is used to measure the column width as child below
the row.
In that way the row's style will be used.
-
Commit messages:
- 8251480: TableColumnHeader: calc of cell width must respect row styling
Changes:
On Thu, 23 Sep 2021 13:48:44 GMT, Robert Lichtenberger
wrote:
> This PR fixes JDK-8274137 by removing the optimization from updateHbar() that
> will no-op the method in case the VirtualFlow is invisible or currently has
> no scene.
> Since changes to the hBar's value can
On Mon, 27 Sep 2021 05:27:25 GMT, Robert Lichtenberger
wrote:
>> This PR fixes JDK-8274137 by removing the optimization from updateHbar()
>> that will no-op the method in case the VirtualFlow is invisible or currently
>> has no scene.
>> Since changes to the hBar
synchronisation between hBar and clipX must happen all
> the time.
>
> A test agains VirtualFlow has been added that will fail before the change and
> pass afterwards.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the last revision:
8
On Fri, 24 Sep 2021 11:22:22 GMT, Kevin Rushforth wrote:
>> Robert Lichtenberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274137: TableView scrollbar/header misaligned when reloading data
>>
synchronisation between hBar and clipX must happen all
> the time.
>
> A test agains VirtualFlow has been added that will fail before the change and
> pass afterwards.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the last revision:
8
This PR fixes JDK-8274137 by removing the optimization from updateHbar() that
will no-op the method in case the VirtualFlow is invisible or currently has no
scene.
Since changes to the hBar's value can happen even if the VirtualFlow is not
currently visible, the synchronisation between hBar and
is, the problem will probably vanish with JavaFX 17.
But the question remains whether the fix should be backported, since a
lot of JavaFX applications will not work correctly under various modern
Linux distributions.
Best regards,
Robert
Am 6/2/21 um 12:43 PM schrieb Robert Lichtenberger:
Using
Using this testapplication:
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.image.Image;
import javafx.scene.image.ImageView;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;
public class ImageTest extends Application {
@Override
I would like this, I am not a big fan of CSS everywhere and this would make
small examples easier to read/write.
Am Do., 22. Apr. 2021 um 15:47 Uhr schrieb Nir Lisker :
> Hi,
>
> Many times when I want to create a simple solid Background or Border, it is
> quite a hassle because of the
I have tried to import OpenJFX to eclipse under Windows today for the first
time and having the exakt same problem.
Am Mo., 17. Aug. 2020 um 13:52 Uhr schrieb Nir Lisker :
> They are not required if you use the command line interface, but I find
> that they do make things easier since I can run
On Tue, 23 Feb 2021 15:32:17 GMT, Robert Lichtenberger
wrote:
> Reverting to the old way of showing the context menu but with application
> of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct
> size measurement of the menu.
This pull request has now been i
On Tue, 23 Feb 2021 15:32:17 GMT, Robert Lichtenberger
wrote:
> Reverting to the old way of showing the context menu but with application
> of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct
> size measurement of the menu.
I've finally managed to build Jav
On Mon, 15 Mar 2021 09:11:41 GMT, Robert Lichtenberger
wrote:
>> Reverting to the old way of showing the context menu but with application
>> of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct
>> size measurement of the menu.
>
> Yes I can try to l
On Fri, 12 Mar 2021 13:59:07 GMT, Kevin Rushforth wrote:
>> Marked as reviewed by aghaisas (Reviewer).
>
> This fixes the bug in question, although I see a slight regression in
> behavior on Windows with 125% pixel scaling (it doesn't reproduce with any
> other scaling value that I tried).
Reverting to the old way of showing the context menu but with application
of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct
size measurement of the menu.
-
Commit messages:
- 8261840: Submenus close to screen borders are no longer repositioned
Changes:
I think I can comment from the perspective of a successful user of JavaFX
(we have been running an administration application for our medical
software for over 5 years now) as well as a part-time contributor to the
JavaFX project (with the help of Kevin Rushforth and Ajit Ghaisas my pull
request
On Thu, 21 Jan 2021 06:42:19 GMT, Robert Lichtenberger
wrote:
> By using the anchor location facility of PopupWindows we can avoid
> miscalculation of the
> menu's height entirely.
> This fix also cleans up some documentation issues.
> This fix introduces tests that ch
withCSS reproduces the problem that is fixed with this patch.
> The other test_position_ cases serve as "proof" that no regressions are
> introduces.
> They work before and after the fix is introduced.
Robert Lichtenberger has updated the pull request incrementally with one
addi
On Wed, 27 Jan 2021 11:21:19 GMT, Ajit Ghaisas wrote:
>> Robert Lichtenberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8228363: ContextMenu.show with side=TOP does not work the first time in
On Wed, 27 Jan 2021 10:41:25 GMT, Ajit Ghaisas wrote:
>> Robert Lichtenberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8228363: ContextMenu.show with side=TOP does not work the first time in
withCSS reproduces the problem that is fixed with this patch.
> The other test_position_ cases serve as "proof" that no regressions are
> introduces.
> They work before and after the fix is introduced.
Robert Lichtenberger has updated the pull request incrementally with one
addi
On Fri, 22 Jan 2021 18:54:35 GMT, Kevin Rushforth wrote:
>> Robert Lichtenberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8228363: ContextMenu.show with side=TOP does not work the first time in
On Fri, 22 Jan 2021 19:01:13 GMT, Kevin Rushforth wrote:
>> Robert Lichtenberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8228363: ContextMenu.show with side=TOP does not work the first time in
withCSS reproduces the problem that is fixed with this patch.
> The other test_position_ cases serve as "proof" that no regressions are
> introduces.
> They work before and after the fix is introduced.
Robert Lichtenberger has updated the pull request incrementally with one
addi
On Fri, 22 Jan 2021 11:02:29 GMT, Robert Lichtenberger
wrote:
>> While trying to come up with a good documentation I've detected a real
>> change in behaviour in connection with the NodeOrientation of the anchor
>> node.
>> Although this has nev
On Fri, 22 Jan 2021 10:53:00 GMT, Robert Lichtenberger
wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/ContextMenu.java
>> line 241:
>>
>>> 239: * the {@code ContextMenu} such that its top-left (0,0) position
>>> would be attac
On Thu, 21 Jan 2021 23:07:23 GMT, Kevin Rushforth wrote:
>> By using the anchor location facility of PopupWindows we can avoid
>> miscalculation of the
>> menu's height entirely.
>> This fix also cleans up some documentation issues.
>> This fix introduces tests that check the correct
On Thu, 21 Jan 2021 23:15:09 GMT, Kevin Rushforth wrote:
>> By using the anchor location facility of PopupWindows we can avoid
>> miscalculation of the
>> menu's height entirely.
>> This fix also cleans up some documentation issues.
>> This fix introduces tests that check the correct
On Thu, 21 Jan 2021 23:11:44 GMT, Kevin Rushforth wrote:
>> By using the anchor location facility of PopupWindows we can avoid
>> miscalculation of the
>> menu's height entirely.
>> This fix also cleans up some documentation issues.
>> This fix introduces tests that check the correct
On Thu, 21 Jan 2021 06:37:59 GMT, Robert Lichtenberger
wrote:
>> Regarding the spec change, I was thinking of this section, which you removed:
>>
>> * To clarify the purpose of the {@code hpos} and {@code vpos}
>> parameters,
>> * consider that they a
By using the anchor location facility of PopupWindows we can avoid
miscalculation of the
menu's height entirely.
This fix also cleans up some documentation issues.
This fix introduces tests that check the correct positioning (test_position_)
test_position_withCSS reproduces the problem that is
On Wed, 20 Jan 2021 16:49:35 GMT, Kevin Rushforth wrote:
> Regarding the spec change, I was thinking of this section, which you removed:
>
> ```
> * To clarify the purpose of the {@code hpos} and {@code vpos} parameters,
> * consider that they are relative to the anchor node. As such,
On Wed, 20 Jan 2021 11:57:04 GMT, Robert Lichtenberger
wrote:
> By using the anchor location facility of PopupWindows we can avoid
> miscalculation of the
> menu's height entirely.
> This fix also cleans up some documentation issues.
> This fix introduces tests that ch
withCSS reproduces the problem that is fixed with this patch.
> The other test_position_* cases serve as "proof" that no regressions are
> introduces.
> They work before and after the fix is introduced.
Robert Lichtenberger has refreshed the contents of this pull request, an
On Wed, 20 Jan 2021 16:37:04 GMT, Kevin Rushforth wrote:
> This changes the specification in a way that will require prior discussion,.
> It also will need a CSR.
My hope is that it really doesn't change the specification in any way. All it
should do is fix the bug.
What part of the spec do
On Wed, 20 Jan 2021 16:39:45 GMT, Kevin Rushforth wrote:
> I recommend that you follow the instructions in the earlier comment about
> pushing these changes to a new branch, resetting your master branch, and
> creating a new PR from your new branch.
Ah yes, will try to do so tomorrow.
By using the anchor location facility of PopupWindows we can avoid
miscalculation of the
menu's height entirely.
This fix also cleans up some documentation issues.
This fix introduces tests that check the correct positioning (test_position_*)
test_position_withCSS reproduces the problem that is
On Thu, 5 Mar 2020 16:01:10 GMT, Robert Lichtenberger
wrote:
> This PR fixes JDK-8176270 by clamping the end index of the selected text to
> the length of the text.
This pull request has now been integrated.
Changeset: e2d1c021
Author:Robert Lichtenberger
Committer: Kevin Rushfort
On Thu, 2 Jul 2020 23:39:58 GMT, Kevin Rushforth wrote:
>> seeing that you are working at it (and still without too close a look, sry
>> ;) - we need more tests about the
>> notifications of all properties involved: text, selectedText, indexRange
>> (anything else?). The things to test are
>>
> This PR fixes JDK-8176270 by clamping the end index of the selected text to
> the length of the text.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the last revision:
8176270: Adding ChangeListener to TextField.selectedTextProperty
On Thu, 9 Jul 2020 20:29:51 GMT, Kevin Rushforth wrote:
>> Robert Lichtenberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8176270: Adding ChangeListener to TextField.selectedTextProperty causes
>&
On Tue, 30 Jun 2020 23:05:40 GMT, Kevin Rushforth wrote:
>> Robert Lichtenberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8176270: Adding ChangeListener to TextField.selectedTextProperty causes
>&
> This PR fixes JDK-8176270 by clamping the end index of the selected text to
> the length of the text.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the last revision:
8176270: Adding ChangeListener to TextField.selectedTextProperty
ew tests. If it's just a case where the test
> coverage is poor, it might make sense for a follow-on test bug to add
> new tests.
>
> I know that this isn't a definitive answer, but hopefully it will
> provide some general guidance.
>
> -- Kevin
>
>
> On 6/15/20
> This PR fixes JDK-8176270 by clamping the end index of the selected text to
> the length of the text.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the last revision:
8176270: Adding ChangeListener to TextField.selectedTextProperty
While discussing my Pull Request ([1]) for JDK-8176270 ([2]) with Jeanette
Winzenburg I came across two questions that I would like to ask the
community regarding test cases:
1) How fine-grained to we want tests to be? Is it ok to test two (somewhat
similiar) things at once or should a separate
Please ignore my previous mail. I forgot to update my fork of OpenJFX so I
was operating on a Mid-March version. After really updating everything
worked fine.
Am Mo., 15. Juni 2020 um 10:12 Uhr schrieb Robert Lichtenberger <
r.lichtenber...@gmail.com>:
> I haven't built in a while bu
> This PR fixes JDK-8176270 by clamping the end index of the selected text to
> the length of the text.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the last revision:
8176270: Adding ChangeListener to TextField.selectedTextProperty
I haven't built in a while but today I pulled the current master branch and
tried to build OpenJFX.
Unfortunately, the task :graphics:ccLinuxGlassGlassgtk2 fails like this:
:graphics:ccLinuxGlassGlassgtk2 (Thread[Daemon worker Thread 2,5,main])
started.
Starting process 'command 'gcc''. Working
On Thu, 11 Jun 2020 14:39:08 GMT, Jeanette Winzenburg
wrote:
> good direction, I think :)
>
> Didn't look too closely, just added your changes and run the tests - getting
> a StringIndexOutofBounds at
> TextInputControlTest.test_jdk_8171229_replaceText(TextInputControlTest.java:1862)
> (no
On Wed, 27 May 2020 12:11:48 GMT, Robert Lichtenberger
wrote:
>> you are hacking around ;)
>>
>> doSelect _must not_ be called somewhere "in-between" changing the text: the
>> api doc clearly states that the
>> caret/anchor coordinates are the _new_ co
> This PR fixes JDK-8176270 by clamping the end index of the selected text to
> the length of the text.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the last revision:
8176270: Adding ChangeListener to TextField.selectedTextProperty
On Wed, 27 May 2020 10:09:52 GMT, Jeanette Winzenburg
wrote:
>> Clearing the selection temporarily works fine to prevent the
>> StringOutOfBoundsException but will also change
>> selectionProperty to reflect the selection being 0/0 for a short time.
>
> you are hacking around ;)
>
> doSelect
> This PR fixes JDK-8176270 by clamping the end index of the selected text to
> the length of the text.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the last revision:
8176270: Adding ChangeListener to TextField.selectedTextProperty
On Wed, 27 May 2020 07:37:13 GMT, Robert Lichtenberger
wrote:
>> We're in the process of finishing our products' release. If I find time
>> I will try and give this (rather nasty) Problem another shot.
>>
>> On 2020-05-08 20:51, Kevin Rushforth wrote:
>>>
>
> This PR fixes JDK-8176270 by clamping the end index of the selected text to
> the length of the text.
Robert Lichtenberger has updated the pull request incrementally with one
additional commit since the last revision:
8176270: Adding ChangeListener to TextField.selectedTextProperty
On Mon, 11 May 2020 04:54:31 GMT, Robert Lichtenberger
wrote:
>> @effad I just closed PR #73 due to inactivity. If you are interested
>> interested in pursuing this, go ahead and reopen
>> this (although you would need to address the feedback that clamping is
>>
On Fri, 8 May 2020 18:50:57 GMT, Kevin Rushforth wrote:
>> I wasn't aware of PR #73, I only saw the (very old) issue in the JDK Bug
>> System and started to look into the issue.
>> The fact that two different people start to look into the same issue shows
>> it is important however :-).
>>
On Thu, 5 Mar 2020 16:01:10 GMT, Robert Lichtenberger
wrote:
> This PR fixes JDK-8176270 by clamping the end index of the selected text to
> the length of the text.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jfx/pull/138
On Thu, 5 Mar 2020 18:00:25 GMT, Kevin Rushforth wrote:
>> why a second pr for the same issue (see
>> https://github.com/openjdk/jfx/pull/73)? particularly one that doesn't do
>> much more/else/better (than clamping, which isn't good enough)?
>
> I have exactly the same question.
>
> In
This PR fixes JDK-8176270 by clamping the end index of the selected text to the
length of the text.
-
Commits:
- e78e8793: 8176270: Adding ChangeListener to TextField.selectedTextProperty
causes StringOutOfBoundsException
- d849c67c: Merge remote-tracking branch 'upstream/master'
> Test simulates a single mouse-released event.
> Fix simply guards against the null case.
The pull request has been updated with 1 additional commit.
-
Added commits:
- 39a61821: 8237372: NullPointerException in TabPaneSkin.stopDrag
Changes:
- all:
On Tue, 28 Jan 2020 12:38:32 GMT, Ambarish Rapte wrote:
>> The pull request has been updated with 1 additional commit.
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TabPaneTest.java
> line 57:
>
>> 56: import javafx.scene.input.KeyEvent;
>> 57: import
On Fri, 24 Jan 2020 15:41:20 GMT, Kevin Rushforth wrote:
>> The pull request has been updated with 1 additional commit.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java
> line 1994:
>
>> 1993: private ListChangeListener childListener = new
>>
> Test simulates a single mouse-released event.
> Fix simply guards against the null case.
The pull request has been updated with 1 additional commit.
-
Added commits:
- a54a5306: 8237372: NullPointerException in TabPaneSkin.stopDrag
Changes:
- all:
> Test simulates a single mouse-released event.
> Fix simply guards against the null case.
The pull request has been updated with 1 additional commit.
-
Added commits:
- 30290116: 8237372: NullPointerException in TabPaneSkin.stopDrag
Changes:
- all:
On Wed, 22 Jan 2020 08:01:49 GMT, Ambarish Rapte wrote:
>> The pull request has been updated with 1 additional commit.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java
> line 2216:
>
>> 2215: // Animate tab header being dragged to its final
Test simulates a single mouse-released event.
Fix simply guards against the null case.
-
Commits:
- 923a63b2: 8237372: NullPointerException in TabPaneSkin.stopDrag
Changes: https://git.openjdk.java.net/jfx/pull/89/files
Webrev: https://webrevs.openjdk.java.net/jfx/89/webrev.00
I have a testcase + fix ready for JDK-8237372 (A null pointer exception in
TabPaneSkin if only a mouse release event is sent to the skin).
To avoid the kind of confusion I created with my last pull request ;-)
* For what branch should I create the pull request? (From my point of view
jfx14 is
This looks good to me.
Thanks,
Robert
Am Mi., 15. Jan. 2020 um 07:15 Uhr schrieb Nir Lisker :
> I updated the eclipse instructions. Have a look.
>
> Thanks,
> Nir
>
> On Tue, Jan 14, 2020 at 1:01 PM Robert Lichtenberger <
> r.lichtenber...@gmail.com> wrote:
>
On Tue, 14 Jan 2020 14:43:03 GMT, Kevin Rushforth wrote:
>> Partially reviewed, Need to re-check after the change of branch.
>
> Oh, I see the problem. In addition to rebasing you need to exclude any
> commits that are from the `master` branch and are not your. So what you
> really need to do
> As documented in JDK-8236912, WebView did not check whether the idMap really
> contained a mapping for the given button, making it prone to errors, when
> things are extended (as has happened here).
>
> The fix consists of two test cases that show the problem in unfixed WebViews
> and a fix
On Tue, 14 Jan 2020 14:00:08 GMT, Kevin Rushforth wrote:
>> I've rebased my branch like this:
>> git fetch upstream
>> git rebase upstream/jfx14
>> git pull
>> git push
>> and changed the base branch of this PR to jfx14. Hope that was the correct
>> way to do this ;-).
>
> Your branch still
> As documented in JDK-8236912, WebView did not check whether the idMap really
> contained a mapping for the given button, making it prone to errors, when
> things are extended (as has happened here).
>
> The fix consists of two test cases that show the problem in unfixed WebViews
> and a fix
> As documented in JDK-8236912, WebView did not check whether the idMap really
> contained a mapping for the given button, making it prone to errors, when
> things are extended (as has happened here).
>
> The fix consists of two test cases that show the problem in unfixed WebViews
> and a fix
into a separate branch (of my fork), maybe that was the problem. If there
is anything else I did wrong, please tell me ;-).
The Changes-Link and the Webrev correctly show that only two files are
changed.
Am Di., 14. Jan. 2020 um 13:02 Uhr schrieb Robert Lichtenberger <
rlich...@openjdk.java.
As documented in JDK-8236912, WebView did not check whether the idMap really
contained a mapping for the given button, making it prone to errors, when
things are extended (as has happened here).
The fix consists of two test cases that show the problem in unfixed WebViews
and a fix which works
1 - 100 of 131 matches
Mail list logo
