can't drag tab to other place on tabbar

VERIFIED FIXED in Firefox 3.6a1

Status

()

Firefox
Tabbed Browser
--
major
VERIFIED FIXED
9 years ago
7 years ago

People

(Reporter: Peter6, Assigned: Natch)

Tracking

({regression, verified1.9.1})

3.5 Branch
Firefox 3.6a1
regression, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090123 Minefield/3.2a1pre ID:20090123033224

repro:
select a tab
try to drag it a position left or right

result:
nada happens

Updated

9 years ago
Flags: blocking-firefox3.1?
Version: Trunk → 3.1 Branch
WFM with a build that has this patch but might not include some other patches which landed today. I

Updated

9 years ago
Target Milestone: --- → Firefox 3.1b3
Duplicate of this bug: 475046
1. Pick one of your open tabs and attempt to move to the right or left one tab
position.
2. Note it does not move
3. Now take that same tab and move it past one tab either right or left, and it
now moves to the correct position, one tab to the right of where you wanted to
move it.
(Assignee)

Comment 4

9 years ago
Nearly positive this was caused by bug 457651, specifically the second children tag.
Depends on: 457651
(Assignee)

Updated

9 years ago
Blocks: 457651
No longer blocks: 471499
No longer depends on: 457651

Updated

9 years ago
OS: Windows XP → All
Hardware: x86 → All
More likely caused by the comments.  See bug 474964 comment 7.
Assignee: nobody → highmind63

Comment 6

9 years ago
For anyone having trouble reproducing this with a new profile, you initially need three or more tabs open.  With the three (unique) tabs open, attempt to drag and drop the first tab between the second and third tab.

Comment 7

9 years ago
I think this isuue is the CORE problem.
It is because the value of  gBrowser.mTabs[i].boxObject.screenX  is wrong. 

for (var i=0; i<gBrowser.mTabs.length; i++){
  alert(gBrowser.mTabs[i].boxObject.screenX);
}

A result does not increase sequentially.

Comment 8

9 years ago
(In reply to comment #7)
> I think this isuue is the CORE problem.
> It is because the value of  gBrowser.mTabs[i].boxObject.screenX  is wrong. 
> 
> for (var i=0; i<gBrowser.mTabs.length; i++){
>   alert(gBrowser.mTabs[i].boxObject.screenX);
> }
> 
> A result does not increase sequentially.

shouldn't there be a semicolon after i++?

Comment 9

9 years ago
(In reply to comment #8)
> (In reply to comment #7)
> > for (var i=0; i<gBrowser.mTabs.length; i++){
>
> shouldn't there be a semicolon after i++?

No

Comment 10

9 years ago
Although a basis is scarce I think the following will fix the issue. 
Line 253 in scrollbox.xml
-var elements = this.hasChildNodes() ?
+var elements = (this.hasChildNodes() && this.childNodes.length > 1 ) ?

Comment 11

9 years ago
I am sorry, I wrote the wrong place. 
Please ignore Comment #10 .

Comment 12

9 years ago
I also think it is the bug of core components. When four tabs <A>, <B>, <C> and <D> open and I move <D> between <A> and <B>, then, DOM Inspector sais:
<xul:box>
  #comment ( This is a hack to circumvent bug 472020, otherwise ... )
  <xul:tab/> (A)
  <tab/> (D)
  <tab/> (B)
  <tab/> (C)
  #comment ( This is to ensure anything extensions put here will ... )
  <xul:toolbarbutton/>
</xul:box>
but actual layout is <D><A><B><C>.
So was this fixed by the first patch in bug 474964 (landed 2009-01-23 16:48:05 PST)?

Comment 14

9 years ago
(In reply to comment #13)
> So was this fixed by the first patch in bug 474964 (landed 2009-01-23 16:48:05
> PST)?

No. I've merged the patch to my local Shiretoko, but it doesn't fix this bug.

Comment 15

9 years ago
I did some tests.

--------------------
gBrowser.removeAllTabsBut(gBrowser.selectedTab);
gBrowser.addTab('about:');
gBrowser.addTab('about:config');
gBrowser.addTab('about:buildconfig');
var tabs = gBrowser.mTabs;
var tab = gBrowser.mTabContainer.removeChild(tabs[2]);
tabs = gBrowser.mTabs;
gBrowser.mTabContainer.insertBefore(tab, tabs[1]);
--------------------
Then, the actual layout of tabs were broken. The inserted tab became leftmost tab unexpectedly.

--------------------
gBrowser.removeAllTabsBut(gBrowser.selectedTab);
gBrowser.addTab('about:');
gBrowser.addTab('about:config');
gBrowser.addTab('about:buildconfig');
var tabs = gBrowser.mTabs;
var tab = gBrowser.mTabContainer.removeChild(tabs[2]);
gBrowser.mTabContainer.appendChild(tab);
--------------------
Then, the actual layout was correct.

I think Gecko has a serious bug about layouting insertBefore()ed nodes.
(Reporter)

Comment 16

9 years ago
(In reply to comment #13)
> So was this fixed by the first patch in bug 474964 (landed 2009-01-23 16:48:05
> PST)?

Yes, works with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090124 Minefield/3.2a1pre ID:20090124024054

Updated

9 years ago
Duplicate of this bug: 475154

Comment 18

9 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090124 Shiretoko/3.1b3pre

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090124 Shiretoko/3.1b3pre

Yes, this is fixed in the latest nightly now.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Updated

9 years ago
Depends on: 474964
Flags: blocking-firefox3.1?
Keywords: fixed1.9.1
Target Milestone: Firefox 3.1b3 → Firefox 3.2a1

Comment 19

9 years ago
I don't suppose some tests could be written for this?

Updated

9 years ago
Duplicate of this bug: 475192

Comment 21

9 years ago
Now both tests in comment #15 work correctly.
(Windows 2000, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b3pre) Gecko/20090124 Shiretoko/3.1b3pre)
Verified on trunk and 1.9.1 with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090125
Shiretoko/3.1b3pre (.NET CLR 3.5.30729) ID:20090125052901

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre)
Gecko/20090126 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090126020313

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090125
Minefield/3.2a1pre ID:20090125034316

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
Gecko/20090126 Minefield/3.2a1pre ID:20090126020316

It's already covered by Litmus:
https://litmus.mozilla.org/show_test.cgi?id=5973
Status: RESOLVED → VERIFIED
Flags: in-litmus+
Keywords: fixed1.9.1 → verified1.9.1
Duplicate of this bug: 475513
You need to log in before you can comment on or make changes to this bug.