Some chrome javascript code breaks function of scrolling by drag thumb

RESOLVED FIXED in mozilla10

Status

()

Core
Layout
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Alice0775 White, Assigned: tnikkel)

Tracking

({regression})

10 Branch
mozilla10
x86
All
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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
(Reporter)

Comment 1

6 years ago
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
OS: Windows 7 → All
(Assignee)

Comment 2

6 years ago
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.
OS: All → Windows 7
(Assignee)

Comment 3

6 years ago
Created attachment 571239 [details] [diff] [review]
patch

Let's just do a partial backout of the regressing bug. Let's keep using views here. See comment 2 for reasoning.
Assignee: nobody → tnikkel
Attachment #571239 - Flags: review?(roc)
(Assignee)

Updated

6 years ago
OS: Windows 7 → All
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?
Attachment #571239 - Flags: review?(roc) → review+
(Assignee)

Comment 5

6 years ago
(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.
(Assignee)

Comment 6

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/961921808d93
https://hg.mozilla.org/mozilla-central/rev/961921808d93
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in before you can comment on or make changes to this bug.