Closed Bug 1387718 Opened 2 years ago Closed 2 years ago

Dragging a tab past the sides of the tabs strip, the tab stops moving to the right or moves too slow to the left

Categories

(Firefox :: Tabbed Browser, defect, P1, major)

57 Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 57
Iteration:
57.3 - Sep 19
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 --- unaffected
firefox57 - fixed

People

(Reporter: nivtwig, Assigned: dao)

References

(Blocks 1 open bug)

Details

(Keywords: perf, Whiteboard: [reserve-photon-performance])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170804193726

Steps to reproduce:

Open Firefox with many tabs. Pick a middle/center tab to drag so that there are many tabs to the right and left of the tab strip, tabs that are not visible on the screen. 
Drag the tab to the left of the tabs strip, to make it the first tab.
Drag the tab to the right of the tab strip, to make it the last tab. When dragging right move your mouse to the right of the right arrow on the tab strip, to hover over where the new tab icon (+) is or where the tabs dropdown list arrow is.



Actual results:

When dragging right, moving the mouse to the right of the right arrow, the tab stops moving and you can't move it past that position or to be the last tab

When dragging right, moving the mouse so that it hovers over the right arrow, but not to the right of it, or when dragging to the left :
The tab doesn't stop moving, but moves very slowly, too slow. The tab strip keeps moving/scrolling very slowly, but the tab doesn't change its position relative to the other tabs . Reaching the first or last tab with that speed will take ages.


Expected results:

When the tab is dragged, tab movement should not stop, and should not move slowly, but move faster in a relatively fast constant speed, or accelerate with time.
Component: Untriaged → Tabbed Browser
I set importance to "Critical" because the tab dragging functionality currently seems broken or almost useless when trying to drag to near the first or last tab, when there are many tabs.
Severity: normal → critical
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1387861
Err, in fact, probably bug 1387084.
Duplicate of bug: 1387084
(In reply to :Gijs from comment #3)
> Err, in fact, probably bug 1387084.

I don't think this is a duplicate of  bug 1387084

1. I updated to current Nightly 57.0a1 (2017-08-07) (64-bit), but this bug still exists although bug 1387084 should have been fixed for about a day. 
Is it supposed to be fixed in the current Nightly (2017-08-07) ? (I don't have a trackpad so I can't check)

2. This bug is about dragging a tab, but bug 1387084 is about scrolling the tab strip , not dragging a tab.

3. Even if bug 1387084 is also about dragging a tab, not just scrolling the tab strip, this bug also is also about the tab dragging being stopped completely (not just being slow) when dragging to the right. Bug 1387084 is only about slow scrolling or dragging, no mention of the dragging being stopped.
Blocks: 1356705
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Whiteboard: [photon-visual][triage]
Blocks: 1388295
Not photon-visual related.
Severity: critical → major
Whiteboard: [photon-visual][triage]
Duplicate of this bug: 1387721
When dragging a tab, and there are pinned tabs, the tab stops moving also to the left (not only to the right, as in the original bug report) when the mouse is moved left to the left arrow, and being held above the pinned tabs.

Without pinned tabs, there is no area left to the tab bar's left arrow, so the tab dragging to the left is slow, but doesn't stop.
A try of bugzilla.mozilla.org - setting the platform fields , unrelated to the bug.
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
OS: Windows 10 → All
Hardware: x86_64 → All
Workaround userChrome.css that restores functionality at the expense of smooth scrolling:

> .tabbrowser-arrowscrollbox > scrollbox {
>   scroll-behavior: unset;
> }
Alternative workaround is to increase toolkit.scrollbox.scrollIncrement from 20 to 100 and restart.
(In reply to Kestrel from comment #10)
> Alternative workaround is to increase toolkit.scrollbox.scrollIncrement from
> 20 to 100 and restart.

Thanks.
But I should note that it doesn't solve the other problem noted in the bug where the dragging stops to the left and right if your mouse isn't over the arrow button, but more to the right or left.
(In reply to nivtwig from comment #11)
> dragging stops to the left and right if your mouse isn't over the arrow button

That part sounds like a dupe of Bug 604772, the recent slow tab dragging regression is more of an issue right now. Bug 1390188 and Bug 1389914 appear to be dupes for the slow dragging issue.
[Tracking Requested - why for this release]: Regression
Status: REOPENED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: perf
Whiteboard: [photon-visual] [triage]
Whiteboard: [photon-visual] [triage]
:dao, can you triage/assign a priority here?  There's a number of duplicates, and it's a new regression in 57.  Thanks.
Flags: needinfo?(dao+bmo)
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Flags: needinfo?(dao+bmo) → qe-verify+
Whiteboard: [photon-performance]
Priority: -- → P1
QA Contact: adrian.florinescu
Whiteboard: [photon-performance] → [reserve-photon-performance]
I suspect some overlap between this bug and bug 1387130 (marked resolved fixed); it may suggest an approach to a solution.

See  bugzilla.mozilla.org/show_bug.cgi?id=1387130#c27

The description is almost the same as https://bugzilla.mozilla.org/show_bug.cgi?id=1387718#c0

____
To demonstrate:
get lots of tabs up, sufficient that the < scroll arrow appears.
lock on a tab with the mouse, attempt to move the tab left (say), outside of currently visible row of tabs

- the move initially seems to hit barriers, and once it starts working the move is slow & jerky as per 'inchworm'

This is close to unusable
[ also it is not possible to drag a tab from the drop-down list ].

Moving a tab within the visible range seems fluent & fine now.

_____
Also, from earlier observations, this too may suggest where the roots lie:

Pursuant to my earlier merged report on this topic, wide web-pages similarly display less than optimal behaviour when using keyboard < > to scroll laterally. Not quite 'right' but possibly acceptable.

Get a web-page and magnify it ctrl+ until it exceeds the screen-width, and (ideally but not always) the horizontal scroll bar appears.
Try to scroll laterally using the -> & <- keys

I find the scrolling is slow to get started, then sometimes makes a single 'word' jump, then moves quite fast (enough) but with noticeable granularity.
Comment on attachment 8907522 [details]
Bug 1387718 - Use instant scroll behavior when dragging something over the tab strip scroll buttons.

https://reviewboard.mozilla.org/r/179234/#review184462

Thanks!
Attachment #8907522 - Flags: review?(mconley) → review+
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/dc2bacb89a6b
Use instant scroll behavior when dragging something over the tab strip scroll buttons. r=mconley
https://hg.mozilla.org/mozilla-central/rev/dc2bacb89a6b
Status: ASSIGNED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Iteration: --- → 57.3 - Sep 19
There seem to be a plethora of similar concerns
 all essentially related to faulty lateral scrolling of tabs.

Unfortunately most seem to be marked resolved, when clearly they aren't

Bug  604772
Bug 1387084
Bug 1387130
Bug 1387718
Bug 1389914 
Bug 1390188

Just sayin'

It might help if there was clear focus on the root of the problems, if that is at all possible
Yes, scrolling is obviously broken since the new tab system landed.

Havent bothered to file a bug because it is so obvious.

Too slow, no momentum, jerky/glitchy.


Also after bookmarking a page the tab strip gets into a broken state, thinks you are at the beginning.

Positioning is broken...

I can go on.


Maybe I'll file bugs, probably not, no time, too much work.
Are you sure you're using the latest Nightly build? In my testing FF57 tabstrip scrolling is about parity with FF55. Arrow scrolling is a bit slow and drag scrolling is jumpy but no worse than before.
(In reply to Kestrel from comment #24)
> Are you sure you're using the latest Nightly build? In my testing FF57
> tabstrip scrolling is about parity with FF55. Arrow scrolling is a bit slow
> and drag scrolling is jumpy but no worse than before.

Yes. I am using the latest Nightly.

It's been broken since the new system landed. I have seen complaints elsewhere as well, I guess we will see just how annoyed people are with the new behaviour once it gets to stable.
(In reply to 6lobe from comment #23)
> Maybe I'll file bugs, probably not, no time, too much work.

You seem to have the time to complain here in the comments, yet without any specifics that would allow others to reproduce.

(In reply to 6lobe from comment #25)
> It's been broken since the new system landed. I have seen complaints
> elsewhere as well,

Again, no links or anything.

> I guess we will see just how annoyed people are with the
> new behaviour once it gets to stable.

We'd prefer to fix issues before they hit stable, but if nobody else is able to reproduce them, there's effectively nothing for us to fix.

It's pretty clear that the "new system" addressed actual issues with the previous code, so backing it out without evidence/specifics of what (if anything) it broke isn't going to happen.
(In reply to Kestrel from comment #24)
> Are you sure you're using the latest Nightly build? In my testing FF57
> tabstrip scrolling is about parity with FF55. Arrow scrolling is a bit slow
> and drag scrolling is jumpy but no worse than before.

"..no worse than before" isn't much of an endorsement. Is that your aim in life? 
The rest is quibbling. 
As is being aggressive towards a new entrant giving a useful subjective opinion (confirmation). Are you sure you were using the best approach there, 6lobe?
I've just collapsed all that.


Lets see if we can improve things, shall we?

Scrolling is (or has been) "obviously" broken since maybe Bug 604772. (See my comment 22)

Across the many previous reports of manifestations of this, there have been demonstrations & confirmations, and a delusion it was fixed.

But poor scrolling just rolls on. 
Certainly in recent weeks it has been worse to unusable, but symptoms are on the mend.

Confession: I've been uncomfortable that some of my previous reports have not been exactly focused, for just that reason that I feel the root problem is elsewhere & simply manifesting.


Appeal: Someone needs to get a grip (sadly it isn't me, my knowledge is insufficient)
and to find the root problems and deficiencies with tab handling, rather than patching the symptoms. 

Please.
57.0a1 (2017-09-20) (32-bit)

Improved, got worse again.

Recently tried to drag to left, too slow & jerky again.

Keyboard arrows are nonchalantly ignored.

 NEW (to me)
Tried to drag to right, tab halts at the > endstop
If released, does not move. If placed short of endstop, does move.

Nothing is movable from the drop-down tab list. Which would be a useful feature (I don't recall..)


Grip still needed.
Flags: needinfo?(dao+bmo)
(In reply to Bill his name from comment #28)
> 57.0a1 (2017-09-20) (32-bit)
> 
> Improved, got worse again.

Please file a new bug with steps to reproduce and maybe even a regression range. Thanks!
Flags: needinfo?(dao+bmo)
I managed to reproduce this issue on Firefox 57.0a1 (2017-08-05), under Windows 10x64.
On Firefox 58.0a1 (2017-10-26) and on Firefox 57.0b11 the tabs are moved faster to left or right, but the movement is not smooth and if releasing the mouse click over the + button, the tab is moved to the recent position and a new tab is opened. 
Note that the issue with releasing the mouse click button over the + button and creating a new tab is also reproducible on Firefox 56.0.2.
You need to log in before you can comment on or make changes to this bug.