<div dir="ltr"><div dir="ltr">Hi Sergey,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 18, 2018 at 3:35 AM, Sergey Bylokhov <span dir="ltr"><<a href="mailto:Sergey.Bylokhov@oracle.com" target="_blank">Sergey.Bylokhov@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 17/10/2018 07:12, Martin Balao wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Have you tried Laurent's test case on Mac? (the version previous to my refactorings, so we eliminate the OS layer). This bug should manifest there too. Unfortunately, I don't have such environment to test and debug.<br>
</blockquote>
<br></span>
Yes, it is not reproduced on macos, at-least not so easy like on win/lin.<br></blockquote><div><br></div><div>I should have said, the first version of Laurent's test [1]. Perhaps some tweaks are still needed; we need a test that artificially injects the events and does not depend on the OS UI subsystem. But the problem should be there too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    __2.__I’m not sure if I agree to your proposal of dispatching non-SequencedEvents, from the queue. The events arriving after a particular SequencedEvent could be dependent on this event – for example, the current SequencedEvent could be a focus change event, and the subsequent events could be Key events. So, as per your solution, if we dispatch them, there is a possibility that the intended component may not receive those events.<br>
</blockquote>
<br>
An explanation of SequencedEvent above is correct, we need to block the thread until another SequencedEvent will be dispatched or for some reason will be dropped. This is a functional which allow synchronize execution between different EDT(per Appcontex). This is a rare case, which mostly related to the "focus" functionality, because the java can have only one focused element at a time, and we need to manage it between different applications inside jvm. One application is webstart itself and another is the user's application.</blockquote><div><br></div><div>I'll give an example to further illustrate. Let's suppose that we inject a sequence of 3 windows focus events on different app contexts and 1 keystroke in-between. We will wrap each windows focus event on a SequencedEvent event -so there is a specific order that has to be honored- and the keystroke event will not be wrapped. Previous to the proposed patch, the keystroke event would have been discarded while the EDT is blocked on the filter -waiting for other SequencedEvent events to be dispatched before-. With the proposed patch, the keystroke is considered an asynchronous event (not part of the sequence, not wrapped in a SequencedEvent) and is dispatched when it comes. My understanding is that if we want the keystroke to be part of the sequence (synchronized), it has to be wrapped with a SequencedEvent.</div><div><br></div><div>Having said that, I'll further investigate what are the assumptions clients are having, which events are wrapped on SequencedEvent events and which are not. At this point, I'm not completely sure if hardware generated events like keystrokes are wrapped or not.</div><div><br></div><div>Going back to Krishna's comment, my understanding is that the Key event (assuming it's a non-SequencedEvent event) would have been lost previous to this change if the EDT is blocked waiting for a SequencedEvent event.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My understanding is that if you want hard-dependency enforcements, you have to wrap events under SequencedEvent events. All other asynchronous events have absolutely no guarantees. Blocking the EDT should not be done and that's the reason why we dispatch non-SequencedEvent events in the meanwhile. Please note that the only events that are put on hold and re-posted lated are SequencedEvent events that, if dispatched, would violate the sequence rule.<br>
</blockquote>
<br></span>
It is still unclear what is going wrong, based on the stack trace it is clear that a few SequencedEvent waits each other, but why the last(or first) SequencedEvent, which should flush this queue, was not dispatched? Is it possible that this event was dropped for some reason, like its source was disposed, the appcontext itself was disposed, any other reasons?<span class="gmail-HOEnZb"><font color="#888888"><br><br></font></span></blockquote><div><br></div><div>What is going wrong where? Which stack trace do you mean?</div><div><br></div><div>Kind regards,</div><div>Martin.- </div></div><br></div><div class="gmail_extra">--</div><div class="gmail_extra">[1] - <a href="http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014429.html">http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014429.html</a></div></div></div>