648477 - In case of disabled Tabs on Top,Detaching tab is not performed when I dropped the tab onto the contents area

Status: RESOLVED INCOMPLETE

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Alice0775 White]

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/385684ad7eed
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110406
Firefox/4.2a1pre ID:20110406030427

In case of disabled Tabs on Top ,
Detaching tab is not performed when I drag a tab downward(do not drag horizontally) and dropped the tab onto the contents area.
And detaching tab is executed suddenly when mouse hover over Status Panel, Addon Bar or FindBar.


Reproducible: Always

Steps to Reproduce#1:
1. Start Minefield with new profile
2. Un check "Tabs on Top"
3. Open several tabs
4. Drag a tab downward (DO NOT DRAG HORIZONTALLY)
5. Drop the tab on content area
   -- Detaching tab is not performed.
6. Mouse hover over Status Panel, addon Bar or FindBar.
   -- Detaching tab is executed suddenly.

Actual Results:
 Detaching tab is not performed when I dropped the tab onto the contents area.
 And detaching tab is executed suddenly when mouse hover over Status Panel, Addon Bar or FindBar.

Expected Results:
 Detaching tab should be performed after step 5 immediately.

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/01fa971e62ee
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827
Firefox/4.0b5pre ID:20100827190212
fails:
http://hg.mozilla.org/mozilla-central/rev/0886ad6e6aaa
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827
Firefox/4.0b5pre ID:20100827190555
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=01fa971e62ee&tochange=0886ad6e6aaa

In local build:
Build from 7804b5cf4313 : fails
Build from 687b70fea4d0 : fails
Build from 4722b491cd0d : works

I guess landing of Bug 130078 causes the problem.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I'm not able to reproduce this issue with a clean profile and Mozilla/5.0 (Windows NT 5.1; rv:2.2a1pre) Gecko/20110407 Firefox/4.2a1pre or Mozilla/5.0 (Windows NT 6.1; rv:2.2a1pre) Gecko/20110407 Firefox/4.2a1pre

Have you already tested with a fresh profile? Not sure if another pref could cause this?

Comment 2

[Alice0775 White]

(In reply to comment #1)
> I'm not able to reproduce this issue with a clean profile and Mozilla/5.0
> (Windows NT 5.1; rv:2.2a1pre) Gecko/20110407 Firefox/4.2a1pre or Mozilla/5.0
> (Windows NT 6.1; rv:2.2a1pre) Gecko/20110407 Firefox/4.2a1pre
> 
> Have you already tested with a fresh profile? Not sure if another pref could
> cause this?

I tested Clean profile, just Disabled Tabs on top.

See http://technet.microsoft.com/en-us/library/cc978610.aspx
it happens if DragHeight was more than 20. (Some mouse utilities change the value)

Comment 3

[Karl Tomlinson (:karlt back Feb 10)]

Can reproduce on Linux by hiding the navigation bar and starting the drag with the pointer near the bottom of the tab.

The drag begins after the mouse button is released when the pointer returns to over the tab bar or surrounding chrome).  Similar behaviour on Win 7.  The drag ends shortly after in builds without bug 750061.

Comment 4

[Karl Tomlinson (:karlt back Feb 10)]

This seems to be the chrome version of bug 603550.
Since bugs 352093 and 130078 we no longer have auto mouse capturing from widget.

The DragGesture code is designed assuming that mouse events between button down and button up are sent to the same ESM.  The chrome ESM gets all confused when it loses events to content ESM(s).

I guess either mouse capture is required ("Opera" behavior in bug 603550) or the DragGesture code needs to be rewritten using static GestureDown variables instead of per-ESM variables.