698266 - Some chrome javascript code breaks function of scrolling by drag thumb

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Alice0775 White]

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/dfbe9a0fbf97
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111028 Firefox/10.0a1 ID:20111028182330

After landing Bug 658001,
The following chrome code breaks function of scrolling by drag thumb.


window.addEventListener("mousedown", function(event){
document.getElementById("aHTMLTooltip").style.setProperty("display", "none", "important");
}, true);

window.addEventListener("mouseup", function(event){
document.getElementById("aHTMLTooltip").style.removeProperty("display");
}, true);

Reproducible: Always

Steps to Reproduce:
1. Start Firefox with clean profile
2. set devtools.chrome.enabled to true
3. Open Scratchpad (Shift+F4)
4. Environment > Browser
5. Paste the following Javascript Code.

window.addEventListener("mousedown", function(event){
  document.getElementById("aHTMLTooltip").style.setProperty("display", "none", "important");
}, true);
window.addEventListener("mouseup", function(event){
  document.getElementById("aHTMLTooltip").style.removeProperty("display");
}, true);

6. Execute > Run

7. Open any page (Ex. http://www.mozilla.org/projects/firefox/prerelease.html )
8. Try to scroll by by drag thumb

Actual Results:
  Nothing happens

Expected Results:
  Page should be scrolled

Comment 1

[Alice0775 White]

This occurs on ubuntu too
http://hg.mozilla.org/mozilla-central/rev/abdbf0646a21
Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111030 Firefox/10.0a1 ID:20111030031101

Comment 2

[Timothy Nikkel (:tnikkel)]

We call ClearMouseCapture from the view destructor, by which point the client data of the view has been cleared. So we go up the view hierarchy looking for one that has a frame and this makes us go too high in the view hierarchy and we kill mouse capture when we shouldn't.

Comment 3

[Timothy Nikkel (:tnikkel)]

Attachment: patch

Let's just do a partial backout of the regressing bug. Let's keep using views here. See comment 2 for reasoning.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 571239 [details] [diff] [review]
patch

Review of attachment 571239 [details] [diff] [review]:
-----------------------------------------------------------------

OK. I presume the next thing to do then is to move mouse capturing from views to frames and then reinstate this?

Comment 5

[Timothy Nikkel (:tnikkel)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #4)
> OK. I presume the next thing to do then is to move mouse capturing from
> views to frames and then reinstate this?

We don't mouse capture on views or frames. We mouse capture on content nodes. When we remove the remaining views we will just need to add appropriate ClearMouseCapture calls when we would have hidden the view or destroyed the view. The view in this case was a popup view.

Comment 6

[Timothy Nikkel (:tnikkel)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/961921808d93

Comment 7

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/961921808d93