536481 - scrollbar moves with mouse when no mouse buttons pressed with change of focus

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Timothy Nikkel (:tnikkel)]

Click on scrollbar and hold. Move mouse far enough away from scrollbar so that the scrollbar doesn't respond to movements of the mouse anymore. Alt-tab to another application. Release mouse. Go back to Firefox window. Scrollbar still responds to mouse movements, when it should not because there are no mouse buttons down.

Regression range is
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=90d3e6d2cbb9&tochange=4430cae50dad

Based on that bug 178324 seems most likely.

Comment 1

[Neil Deakin]

It think it may be the case that the call to ClearMouseCapture in nsViewManager.cpp isn't called. Likely, a call to ClearMouseCapture is needed within nsFocusManager::WindowLowered instead.

When testing this, I saw this bug on Firefox 3.5 as well, but only managed to reproduce it a couple of times, and not since.

Comment 2

[Neil Deakin]

Attachment: clear capture when window is lowered

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 419009 [details] [diff] [review]
clear capture when window is lowered

A testcase would be great.

Comment 4

[Neil Deakin]

Attachment: this patch adds a test and adds a check for tab switching as well

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

I'm not sure about the nsSubDocumentFrame change.
Changing type attribute doesn't necessarily mean hiding the iframe/browser.

Would it work if presshell used some helper method to check that
capturing content has a frame in a currently visible presshell, which is in the
currently active window? And it not, release capturing content.

For the WindowLowered case setting capturing content explicitly null is probably needed.

Comment 6

[Neil Deakin]

In reply to comment #5)
> I'm not sure about the nsSubDocumentFrame change.
> Changing type attribute doesn't necessarily mean hiding the iframe/browser.

I added it here only to accompany the call to HidePopupsInDocShell which should be called in the same situation. Is there a better suitable place to call these when a tab/window is being hidden?

> Would it work if presshell used some helper method to check that
> capturing content has a frame in a currently visible presshell

Do you mean check this in HandleEvent? What 'currently visible presshell' check were you thinking of here?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #6)
> Do you mean check this in HandleEvent?
Right

> What 'currently visible presshell' check were you thinking of here?
Could checking viewmanager's rootview's visibility be enough, maybe
iterating parent presshell's viewmanagers too.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Enn, are you going to update the patch?

Comment 9

[Neil Deakin]

(In reply to comment #7)

> > What 'currently visible presshell' check were you thinking of here?
> Could checking viewmanager's rootview's visibility be enough

There's already a call to clear the capture if needed when a view is hidden in nsView::NotifyEffectiveVisibilityChanged

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Ah. Well why do we need the a bit strange change to nsFrameFrame.cpp?

Comment 11

[Neil Deakin]

Attachment: what we need here is to check docshell visibility which checks the right things

Comment 12

[Neil Deakin]

http://hg.mozilla.org/mozilla-central/rev/6b8dfb7407fd