Re: Pointer Events 2 results

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
>>>
>>>
>>
> 


-- 
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 14:22:56 UTC