Closed Bug 698266 Opened 8 years ago Closed 8 years ago

Some chrome javascript code breaks function of scrolling by drag thumb

Categories

(Core :: Layout, defect)

10 Branch
x86
All
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla10

People

(Reporter: alice0775, Assigned: tnikkel)

References

Details

(Keywords: regression)

Attachments

(1 file)

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
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
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
Attached patch patchSplinter Review
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)
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+
(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.
https://hg.mozilla.org/mozilla-central/rev/961921808d93
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in before you can comment on or make changes to this bug.