Re: Pointer Events 2 results

I ran some of the tests to reduce down the less-than-2 list. Here is the PR
<https://github.com/w3c/test-results/pull/183>.

There are a few tests that they appear due to failure. For example

   - touch No other events should be recieved by capturing node after
   release
   - Double entry pointerenter@target0
   - Double exit pointerleave@target0

These are only failing in Edge and they appear as single failures and not
appearing at all for other browsers (which in this case means passing for
them).
I believe we shouldn't have such a test but for the time being I wasn't
sure to ignore those as there is only one failing implementation.


On Tue, Jul 10, 2018 at 5:04 PM Navid Zolghadr <nzolghadr@chromium.org>
wrote:

> Regarding the tangentialPressure and twist what Patrick sees is indeed a
> bug in Chrome. A few months ago we switched the behavior of the pen in
> Chrome to do scrolling when touching the screen on Windows to match the
> platform behavior. That change caused a few bugs including this twist
> tangentialPressure.
> More precisely when you touch the screen we changed the routing of the
> events in Chrome which is the situation that you see the bug. Note that
> tangentialPressure itself is always zero I believe when hovering similar to
> pressure. We are going to fix this soon. As a side note both of these
> attributes work just fine on Mac currently.
>
> As far as the testing is concerned, you are correct that we don't have
> tests to check the values of pressure, twist, and tangentialPressure. I
> believe we wanted to avoid tying the tests to devices too much as some
> devices just don't support some of these attributes. For example if you
> only have a symmetric tip for Wacom it only reports zero for twist. So it
> would make such a test that checks for different values of twist that much
> harder to run. I'm hoping to address these issues in our automated APIs for
> input injection so we can add all these sort of tests.
>
>
> On Tue, Jul 10, 2018 at 3:57 PM Philippe Le Hégaret <plh@w3.org> wrote:
>
>>
>>
>> On 7/10/2018 11:16 AM, Navid Zolghadr wrote:
>> > Awesome. Thanks Philippe for taking the time and run the tests on all
>> the
>> > browsers. I have done it for Chrome in the past and I know it is such a
>> > pain.
>> >
>> > I also want to mention that we have some tests that pass with different
>> > pointer types (like with both touch and mouse) but they output different
>> > test names which caused more tests in the less-than-2 bucket. So not the
>> > best test suite here :).
>>
>> Yes, I didn't look into the tests themselves since I was simply focusing
>> on getting some results. I can attempt to propose some improvements but
>> not sure when I would get to it yet.
>>
>> >
>> > Note that some of them are tricky to run. For example
>> >
>> http://www.w3c-test.org/pointerevents/pointerevent_pointerleave_pen-manual.html
>> > you
>> > need to leave the pen from the range of the digitizer while you are
>> still
>> > keeping the pen on top of the element. If you just leave it from the
>> > boundaries it would fail. I brought this up because I just tested this
>> > single one on Edge, Chrome and FF on a surface tablet with its own pen
>> and
>> > also external Wacom and both Chrome and Edge passed even though the
>> test is
>> > listed in less-than-2
>> > <http://w3c.github.io/test-results/pointerevents/less-than-2.html>.
>> Note
>> > that Firefox still didn't pass it.
>>
>> Feel free to update the results. It is indeed tricky to run some of them.
>>
>> > There are a few tests like the one above. Aside from those there are
>> some
>> > tests that we punted on like
>> >
>> http://www.w3c-test.org/pointerevents/pointerevent_click_during_capture-manual.html
>> > as
>> > currently browsers don't agree on a behavior and we tried it once to
>> spec
>> > it consistently with other behaviors but after Chrome implemented the
>> new
>> > behavior it caused some compat issues and we had to revert it. So we
>> agreed
>> > to address it later V3. Not sure where to put these sort of tests for
>> now.
>> > Should we just leave it there in the main directory and keep a list?
>>
>> Yes. The tests should definitively stay but we could remove them from
>> the report in the meantime (using filter.js). Do you/can you have a list
>> of the tests to remove from the report?
>>
>> Note that Patrick main concern is on twist and tangentialPressure. We
>> don't have test (besides IDL ones) and it doesn't look like we have
>> enough implementation...
>>
>> As a side, I did some musing around UI events today:
>>    https://www.w3.org/2018/07/uievents.html
>>
>> You can limit this to Pointer Events only:
>>    https://www.w3.org/2018/07/uievents.html?filterTypes=pointer
>>
>> Philippe
>>
>> >
>> >
>> > On Tue, Jul 10, 2018 at 5:45 AM Patrick H. Lauke <
>> redux@splintered.co.uk>
>> > wrote:
>> >
>> >> Folks, Philippe has kindly helped with trying to run the tests/compile
>> >> results. However, there seem to be some gaps here with browser support.
>> >> It would be REALLY good if you could check/clarify what the current
>> >> state of these things is, if possible?
>> >>
>> >> Currently, our progression with the spec along the W3C track is likely
>> >> stalled and we may have to see if we can get a further extension of the
>> >> charter, but only if there's still activity/interest in carrying on.
>> >>
>> >> On 09/07/2018 18:44, Philippe Le Hégaret wrote:
>> >>   > (feel free to forward this message to a public place if needed)
>> >>   >
>> >>   > I ran all of the tests the best I was able to:
>> >>   > http://w3c.github.io/test-results/pointerevents/all.html
>> >>   >
>> >>   > I ended up with a 4.42% failure level:
>> >>   > http://w3c.github.io/test-results/pointerevents/less-than-2.html
>> >>   >
>> >>   > The subtest names aren't consistently generated. It affects most
>> >>   > pointerevent_attributes_hoverable_pointers-manual.html and
>> generates a
>> >>   > semibogus report consequently.
>> >>   >
>> >>   > I also suspect some of the tests to potentially have some browser
>> >>   > specific quirks/behaviors (eg
>> >> pointerevent_pointerleave_pen-manual.html).
>> >>   >
>> >>   > Focusing on Pointer Events 2 additions:
>> >>   >
>> >>   > - We don't have much test for tangentialPressure and twist. I also
>> don't
>> >>   > have a device that makes use of those so I wasn't able to test
>> these
>> >>   > twos. Both chrome and Firefox claims to support however as shown
>> in the
>> >>   > tests
>> >>
>> >> As I have some devices, I suggested that I could help out with some of
>> >> the pen testing.
>> >>
>> >> On 09/07/2018 19:58, Philippe Le Hégaret wrote:
>> >> [...]
>> >>> Can you generate non-zero values for tangentialPressure and twist in
>> the
>> >>> following pointer events monitor:
>> >>> https://www.w3.org/2018/07/pointerevents.html
>> >>
>> >> Ok, tried those using my Wacom Intuos S under Win 10 - the art pen/felt
>> >> pen has a twist sensor, and the airbrush pen has an additional wheel
>> >> that's supposed to work as tangential/barrel pressure setting.
>> >>
>> >> Results so far:
>> >>
>> >> * Edge doesn't seem to have implemented twist nor tangentialPressure
>> >> support at all - the properties are missing in generated pointer
>> events;
>> >> they attributes thankfully are present in Chrome and Firefox.
>> >>
>> >> * Chrome correctly supports twist (turning the art pen along its axis /
>> >> rolling it between my fingers gives me values from 0-359); one oddity
>> is
>> >> that this only works when the pen is hovering over the digitizer
>> surface
>> >> - as soon as I set the pen down on the digitizer surface, twist resets
>> >> to zero and doesn't react to any pen rolling. As I see this also
>> >> apparently happening when I'm using Photoshop and the Wacom, I suspect
>> >> this MAY be hardware-based limitation (similar to something like palm
>> >> rejection), but can't be sure without having a way to see the actual
>> >> data/values passed from the hardware/the system API.
>> >>
>> >> * Although Chrome does have the tangentialPressure property, but I
>> can't
>> >> seem to get any value other than zero when using the airbrush pen. Not
>> >> sure if this is something to do with a bug/imperfect implementation in
>> >> Chrome, or perhaps the driver software for the Wacom. I did manage to
>> >> check that the wheel on the airbrush does indeed work in Photoshop, but
>> >> the way it works maybe is unusual: turning the wheel itself doesn't
>> seem
>> >> to change anything directly, but the position of the wheel does
>> >> influence other aspects once the pen clicks/touches the digitizer. So
>> >> for instance, setting up Photoshop correctly, I can use an airbrush
>> >> tool, and while the pen touches the digitizer/presses down, I can use
>> >> the wheel to determine the strength of the pressure (see
>> >> https://www.youtube.com/watch?v=t85gxJTN_MQ for instance). Not sure
>> how
>> >> this is reflected in terms of values passed on via the hardware/system
>> >> API though...wondering if Chrome expects values to come in a certain
>> >> way, but instead they're only generated in some other way? Or the
>> >> plumbing just isn't connected behind the scenes?
>> >>
>> >> * Firefox's PE implementation seems a bit broken still. I noticed, for
>> >> one, that hovering a pen/stylus over the digitizer works correctly (and
>> >> the pointer is identified as as hovering "pen"), but as soon as the pen
>> >> touches the digitizer it's all of a sudden reported as "touch". The
>> >> pressure attribute doesn't seem to change either. This happened both
>> >> when testing the Wacom and the basic stylus on Surface 3.
>> >>
>> >> * In Firefox, both twist and tangentialPressure are present but remain
>> >> zero.
>> >>
>> >> P
>> >> --
>> >> Patrick H. Lauke
>> >>
>> >> www.splintered.co.uk | https://github.com/patrickhlauke
>> >> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> >> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> >>
>> >>
>> >
>>
>>