Bug 80536 – REGRESSION: When Safari is not frontmost, pages should not get mouse moves or hover

• Status: RESOLVED
• Resolution: FIXED
• Component: UI Events

[Beth Dakin]

On Lion with legacy-style scrollbars enabled in System Preferences, load http://www.webkit.org/ in a window in Safari, then bring another app to the front, but leave the Safari window visible. Now hover over the Safari window; you'll see that the links show hover feedback. This should not happen; pages in the background should not be able to spy on my mouse movement.

This regressed with http://trac.webkit.org/changeset/101619/trunk which removed code from EventHandler to perform a read only hit test when onlyUpdateScrollbars is true

<rdar://problem/10940970>

[Jeremy Apthorp]

Is it possible to add a failing test for this?

[Beth Dakin]

(In reply to comment #1)
> Is it possible to add a failing test for this?

Off the top of my head I am not sure how to test this, but there may very well be a way.

[Ryosuke Niwa]

(In reply to comment #2)
> (In reply to comment #1)
> > Is it possible to add a failing test for this?
> 
> Off the top of my head I am not sure how to test this, but there may very well be a way.

Can we add layoutTestController or internals method to emulate this situation?

[Beth Dakin]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Is it possible to add a failing test for this?
> > 
> > Off the top of my head I am not sure how to test this, but there may very well be a way.
> 
> Can we add layoutTestController or internals method to emulate this situation?

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Is it possible to add a failing test for this?
> > 
> > Off the top of my head I am not sure how to test this, but there may very well be a way.
> 
> Can we add layoutTestController or internals method to emulate this situation?

Well the situation should be emulated if you can make a test have legacy style scrollbars (which I think they all do by default still anyway), and if you can make the window the test is in not key. From there, you would want to hover the mouse over something that would normally change if the window were key and test whether or not it changed. I do not know which of these things currently is or is not possible in the tests.

[Adele Peterson]

Jeremy, any progress on resolving this regression?

[Jeremy Apthorp]

Does this also happen on Snow Leopard?

[Beth Dakin]

(In reply to comment #6)
> Does this also happen on Snow Leopard?

No. It affects Lion and post-Lion only.

[Beth Dakin]

Created attachment 137929 [details]
Patch

Unfortunately this is tricky to test in the test harness, but this is the fix.

[Adele Peterson]

Comment on attachment 137929 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=137929&action=review

> Source/WebCore/ChangeLog:10
> +

extra line here?

[Simon Fraser (smfr)]

Is this testable?

[Beth Dakin]

http://trac.webkit.org/changeset/114661

In answer to Simon's question, so far I have been unsuccessful at creating a test, but it really should be possible. We need a test that has legacy scrollbars with a window that is not key. Then we need hover-able elements, and we need to hover them, and then we need to detect if they changed hover appearance or not. So, lots of moving parts, but it is theoretically possible.

[Beth Dakin]

Ooo, I think I made a test!

[Beth Dakin]

Created attachment 137979 [details]
Test

Test!

[Beth Dakin]

Comment on attachment 137979 [details]
Test

nm, this fails in WK2