Re: Pointer Events 2 results

Sorry, haven't had time to run tests, and I'm planning to be on vacation next week or so.


On 07/12/2018 05:22 PM, Patrick H. Lauke wrote:
> Olli, any news on the state of Firefox here?
> 
> Thanks,
> 
> P
> 
> On 10/07/2018 20:56, Philippe Le Hégaret 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
>>>>
>>>>
>>>
>>
> 
>

Received on Thursday, 12 July 2018 15:18:42 UTC