Spatial Navigation: Make non-SVG elements with event listener not focusable.

Spatial Navigation: Make non-SVG elements with event listener not focusable.

Making sptnav stop on elements with event listener has both positive and negative
impacts on the user experience. It's good to simplify the case.
In addition, the original patch only meant to support SVG elements and this patch
does not affect SVG.

[c.shu, 2014-12-17 20:04:15]

c.shu@samsung.com changed reviewers:
+ ed@opera.com, fs@opera.com, rob.buis@samsung.com

[Erik Dahlström (inactive), 2014-12-18 11:52:06]

Could you elaborate on why you want to make this change? What exactly are the
cases where it impacts UX negatively / positively? Should we add these as
testcases?

I don't think the original patch meant to include just svg elements, IIRC the
support for svg elements was added to what was previously there only for HTML
elements.

[c.shu, 2014-12-18 16:43:50]

c.shu@samsung.com changed reviewers:
+ kolczyk@opera.com

[c.shu, 2014-12-18 16:48:47]

On 2014/12/18 11:52:06, Erik Dahlström wrote:
> Could you elaborate on why you want to make this change? What exactly are the
> cases where it impacts UX negatively / positively? Should we add these as
> testcases?

One negative example in my mind is if a node has an event listener simply
counting clicks and we stop on it.
But my patch breaks positive example such as the event listener expands
the content on clicks.

> I don't think the original patch meant to include just svg elements, IIRC the
> support for svg elements was added to what was previously there only for HTML
> elements.

My bad. I thought your patch added these lines but it was added way back to
2013 in 4e45bee9 by Krysztof.

[Krzysztof Olczyk, 2014-12-19 08:41:38]

On 2014/12/18 at 16:48:47, c.shu wrote:
> On 2014/12/18 11:52:06, Erik Dahlström wrote:
> > Could you elaborate on why you want to make this change? What exactly are
the
> > cases where it impacts UX negatively / positively? Should we add these as
> > testcases?
> 
> One negative example in my mind is if a node has an event listener simply
> counting clicks and we stop on it.
> But my patch breaks positive example such as the event listener expands
> the content on clicks.
> 
> > I don't think the original patch meant to include just svg elements, IIRC
the
> > support for svg elements was added to what was previously there only for
HTML
> > elements.
> 
> My bad. I thought your patch added these lines but it was added way back to
> 2013 in 4e45bee9 by Krysztof.

Yes, I never considered SVG elements. My patch was for HTML elements that have
onClick, etc.

Can you come with some live web page where this behavior brings negative impact?
We have this approach also previously in Presto-based products and turned out
to serve quite well. 
Authors of web pages very often do not think about the mouse-less devices.
But if they register handler for onclick it will almost definitely mean
that want this element to be clicked/pressed by the user. 
I don't think your example will appear in the actual web pages, but if it does,
why wouldn't we allow user to click that element to see this counter go up?

[c.shu, 2014-12-29 23:17:44]

> Can you come with some live web page where this behavior brings negative
impact?

On news.google.com, the spatial navigation is able to focus on the "news block",
which is the positive side;
however, it stops "twice" on the block, because of two layers of divs, and this
brings the negative impact.