Open Bug 674925 Opened 13 years ago Updated 20 days ago

Improve UI of detaching tabs

Categories

(Firefox :: Tabbed Browser, enhancement, P4)

enhancement
Points:
13

Tracking

()

People

(Reporter: dao, Unassigned)

References

(Depends on 10 open bugs, Blocks 6 open bugs)

Details

(Whiteboard: [reserve-photon-animation][tabs-p4])

Attachments

(1 file, 9 obsolete files)

Use drag & drop API for tab detaching in order to fix various glitches with the mouse-event based implementation.
Blocks: 674913
Depends on: 533460
Blocks: 674487, 674789, 674831
Depends on: 666864
Blocks: 675340
Blocks: 675393
Wasn't the drag & drop API ditched for the reasons mentioned by Frank Yan at bug 455694, comment 184?

https://bugzilla.mozilla.org/show_bug.cgi?id=455694#c184
(In reply to comment #1)
> Wasn't the drag & drop API ditched for the reasons mentioned by Frank Yan at
> bug 455694, comment 184?

We have to use the drag&drop API to properly support dragging tabs to different windows in the taskbar for example. Using simple mouse events sounds like a bad hack IMO.
Blocks: 675438
Blocks: 675444
No longer blocks: 675438
No longer blocks: 675444
Blocks: 675863
Should bug 455694 be backed out to use d&d api?
I don't think we want to completely back out bug 455694. We could just modify the code to use the drag&drop API for detached tabs.
Blocks: 674823
Blocks: 674723
Blocks: 675860
Assignee: nobody → fryn
Keywords: regression
Status: NEW → ASSIGNED
Blocks: 676686
Depends on: 685702
Depends on: 689575
Blocks: 689575
No longer depends on: 689575
Blocks: 690227
Blocks: 676304
This bug has so many dependencies... Frank, could you, please, start working on fixing this bug?
(In reply to Sean Newman from comment #5)
> This bug has so many dependencies... Frank, could you, please, start working
> on fixing this bug?

Sean, this kind of comment isn't helpful. Unless you're adding new information to a bug, please don't comment. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Depends on: 505521
Depends on: 693279
No longer depends on: 693279
These two bugs [url=https://bugzilla.mozilla.org/show_bug.cgi?id=672085]672085[/url] and [url=https://bugzilla.mozilla.org/show_bug.cgi?id=682559]682559[/url] should be blocking the actual release of this bug.
Please add an option in "about:config" to activate the implementation of bug 455694 optional, I like this feature and I want to use it. It's too long to wait until Firefox 10/11(oder later?) Is it possible to realize?
(In reply to Jukens from comment #9)
> Please add an option in "about:config" to activate the implementation of bug
> 455694 optional, I like this feature and I want to use it.

Indeed, it would be nice to have an about:config option to enable current tab-animation implementation for users who don't use any tab-related add-ons.
(In reply to Marat Tanalin | tanalin.com from comment #11)
> (In reply to Jukens from comment #9)
> > Please add an option in "about:config" to activate the implementation of bug
> > 455694 optional, I like this feature and I want to use it.
> 
> Indeed, it would be nice to have an about:config option to enable current
> tab-animation implementation for users who don't use any tab-related add-ons.

The code for the deficient tab animation implementation has been removed from beta, aurora and nightly builds. There is nothing there that an option could turn on or off.
(In reply to Erunno from comment #12)
> The code for the deficient tab animation implementation has been removed
> from beta, aurora and nightly builds.

Thanks, it's quite clear, but does not prevent us from desire for such option (this means that, instead of full backout, existing implementation could be just hidden behind the option as a more appropriate and flexible solution for advanced users).
(In reply to Marat Tanalin | tanalin.com from comment #13)
> (In reply to Erunno from comment #12)
> > The code for the deficient tab animation implementation has been removed
> > from beta, aurora and nightly builds.
> 
> Thanks, it's quite clear, but does not prevent us from desire for such
> option (this means that, instead of full backout, existing implementation
> could be just hidden behind the option as a more appropriate and flexible
> solution for advanced users).

To add such an option, we would need to (a) re-add the problematic code, (b) add a preference and code to handle turning it on/off (c) maintain that code. So we will not be doing that.
(In reply to Jukens from comment #9)
> Please add an option in "about:config" to activate the implementation of bug
> 455694 optional, I like this feature and I want to use it. It's too long to
> wait until Firefox 10/11(oder later?) Is it possible to realize?

Firefox 20+ is more realistic.
(In reply to speciesx from comment #15)
 
> Firefox 20+ is more realistic.

Comments like this are not helpful, and only serve to further delay work.

This isn't a forum -- Bugzilla is for the people doing the work. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Attached patch WIP patch - ~90% done (obsolete) — Splinter Review
Dão, I'd appreciate your feedback on this patch. It's mostly done. The incomplete parts are:
- _getDropIndex() needs a separate code path for tab dragging.
- _animateTabMove() handles some cases poorly.
- dragend/drop should animate tab movement within the tab strip.
- the drag image should be horizontally centered under the cursor.

In particular, I'm not sure what the best approach is for handling all the cases of dragging normal/app tabs in underflow/overflow modes in _animateTabMove() without it getting messy. If you have ideas, please let me know, or even feel free to take the bug and build on my patch.
Attachment #574321 - Flags: feedback?(dao)
Also, bug 666864 is still a problem. It causes a non-dragged, non-selected tab occasionally to flicker during or immediately before/after drags. I'm not sure how best to fix this besides setting pointer-events: none on non-selected tabs during drags.

---

>  /* WIP: We have to offset the drag image like this, or the panel will
>          capture all the events, and the scroll buttons will not work.
>          Setting allowevents="false" doesn't help at all here. */
>  dt.setDragImage(panel, -1, -1);

Neil, could you help me with this? We'd like the panel to be horizontally centered under the cursor, but once the panel is under the cursor, it captures all the events, and the tab strip scroll buttons no longer work during drags, since they rely on receiving dragover events. A last-resort workaround would be to calculate manually whether the cursor is inside each button's rect, but that is gross and unmaintainable.
(In reply to Frank Yan (:fryn) from comment #18)
> Neil, could you help me with this? We'd like the panel to be horizontally
> centered under the cursor, but once the panel is under the cursor, it
> captures all the events, and the tab strip scroll buttons no longer work
> during drags, since they rely on receiving dragover events. A last-resort
> workaround would be to calculate manually whether the cursor is inside each
> button's rect, but that is gross and unmaintainable.

Did you set <panel type="drag"> ?
This still disables dropping to the bookmarks toolbar, right? That was one of the major complaints of the new approach, which issues should still we fix to allow at least the toolbar as a drop target with this version of the patch?
Attached patch WIP patch 2 - ~90% done (obsolete) — Splinter Review
(In reply to Neil Deakin from comment #19)
> Did you set <panel type="drag"> ?

No, I forgot that. I added it to this iteration and then tried changing the offsets in setDragImage to positive values, but it appeared to break in the same way that it did without type="drag".

(In reply to Marco Bonardo [:mak] from comment #20)
> This still disables dropping to the bookmarks toolbar, right? That was one
> of the major complaints of the new approach, which issues should still we
> fix to allow at least the toolbar as a drop target with this version of the
> patch?

It doesn't make sense to allow the toolbar as a drop target for drags that didn't begin with a modifier key. You can try out this patch, and you'll see why. When you drag the tab downwards, you appear to pull its entire contents into a panel, so then it's no longer intuitive to drop it as a bookmark, since you're directly manipulating the tab itself.
Attachment #574321 - Attachment is obsolete: true
Attachment #574321 - Flags: feedback?(dao)
Attachment #574340 - Flags: feedback?(dao)
(In reply to Frank Yan (:fryn) from comment #21)
> (In reply to Marco Bonardo [:mak] from comment #20)
> > This still disables dropping to the bookmarks toolbar, right? That was one
> > of the major complaints of the new approach, which issues should still we
> > fix to allow at least the toolbar as a drop target with this version of the
> > patch?
> 
> It doesn't make sense to allow the toolbar as a drop target for drags that
> didn't begin with a modifier key.

I already got this in the previous version but still, from the newsgroup discussion, Shaver said we may accept drops to the bookmarks toolbar. As this is still the change that got more negative feedback in input.m.o on the previous version, I think we should re-evaluate the decision. Consistency is a good value, but is it worth to replace functionality with an undiscoverable one?
(In reply to Frank Yan (:fryn) from comment #21)
> It doesn't make sense to allow the toolbar as a drop target for drags that
> didn't begin with a modifier key. You can try out this patch, and you'll see
> why. When you drag the tab downwards, you appear to pull its entire contents
> into a panel, so then it's no longer intuitive to drop it as a bookmark,
> since you're directly manipulating the tab itself.

How about the drag-and-dropped "tab" morphs itself into a dragged bookmark when hovered above bookmarks menu? It could then change back to its "tab" display/behavior if the user drags it away from the bookmarks menu. I think that wouldn't be too far from usual file manager drap-and-drop actions (where dragging a file from a folder executes move if the target is on the same volume/media and copy if the target is on another volume/media).
@Mikko
I hadn't noticed it was volume dependant for copy/move, but I did know it changed back and forth. (The reason is moving a file on the same volume is just a change in the $msft, moving between volumes requires you to move the file on the disk)
Dão and Neil, you both observed in bug 685702 that the drag&drop testcase was as fast as the mouse-events testcase for you. Is this patch just as fast for you as the mouse events one? It's clearly not the case for me and Limi, especially when dragging around the detach preview panel.

Neil, what can I do to address the panel events issue, or is that something you are looking into?
(In reply to Frank Yan (:fryn) from comment #17)
> Created attachment 574321 [details] [diff] [review] [diff] [details] [review]
> WIP patch - ~90% done
> 
> Dão, I'd appreciate your feedback on this patch. It's mostly done. The
> incomplete parts are:

Is this supposed to be functional yet? Dragging seems completely broken to me on Linux.

> - _getDropIndex() needs a separate code path for tab dragging.

Is this different from what dolske reviewed in bug 455694? Is it just that you're not happy with that code?
(In reply to Marco Bonardo [:mak] from comment #22)
> (In reply to Frank Yan (:fryn) from comment #21)
> > (In reply to Marco Bonardo [:mak] from comment #20)
> > > This still disables dropping to the bookmarks toolbar, right? That was one
> > > of the major complaints of the new approach, which issues should still we
> > > fix to allow at least the toolbar as a drop target with this version of the
> > > patch?
> > 
> > It doesn't make sense to allow the toolbar as a drop target for drags that
> > didn't begin with a modifier key.
> 
> I already got this in the previous version but still, from the newsgroup
> discussion, Shaver said we may accept drops to the bookmarks toolbar. As
> this is still the change that got more negative feedback in input.m.o on the
> previous version, I think we should re-evaluate the decision. Consistency is
> a good value, but is it worth to replace functionality with an
> undiscoverable one?

If it's going to be capable to drag a tab to the bookmarks bar then a modifier key makes very little sense to me. A modifier emplies that it has something to do with that particular tab in my mind. Why would u hold down a button and then try and drag it? This seems almost boggy in my mind. 

What would be more fluid is if it recondensed when over the tab bar as well as pushed away the other bookmarks for the space. Then uncondensed when moved away. This would show that you could drop it there and that it wouldn't open a new window. 

However dragging a tab inside itself makes no real sense. Personal Opinion is panorama should show when you drag a tab putting your windows intro groups, and you tab groups into sub groups of that window. Then the bookmarks bar could show up at the top by search, and you could daily move windows and tabs around.
Ignore daily in the last paragraph, typo.
(In reply to Dão Gottwald [:dao] from comment #26)
> (In reply to Frank Yan (:fryn) from comment #17)
> > Dão, I'd appreciate your feedback on this patch. It's mostly done. The
> > incomplete parts are:
> 
> Is this supposed to be functional yet? Dragging seems completely broken to
> me on Linux.

Is it really? It works rather well on OS X. I will test it on Linux then.

> > - _getDropIndex() needs a separate code path for tab dragging.
> 
> Is this different from what dolske reviewed in bug 455694? Is it just that
> you're not happy with that code?

I haven't written any new code for that yet. If you think that the _getDropIndex code that dolske reviewed looks okay, I'll just add that in. If not, please let me know what you think would work better.
(In reply to Frank Yan (:fryn) from comment #29)
> > > - _getDropIndex() needs a separate code path for tab dragging.
> > 
> > Is this different from what dolske reviewed in bug 455694? Is it just that
> > you're not happy with that code?
> 
> I haven't written any new code for that yet.

Is what _getDropIndex *needs* to do different from what dolske reviewed in bug 455694?
I.e. why would you write mew code? I assumed you'd mostly build on what you did in bug 455694. I'm missing the motivation for rewriting it.

> If you think that the
> _getDropIndex code that dolske reviewed looks okay, I'll just add that in.
> If not, please let me know what you think would work better.

I haven't closely reviewed it, but apparently you and dolske thought it was okay at that time. Have you changed your mind?

(In reply to Frank Yan (:fryn) from comment #21)
> (In reply to Marco Bonardo [:mak] from comment #20)
> > This still disables dropping to the bookmarks toolbar, right? That was one
> > of the major complaints of the new approach, which issues should still we
> > fix to allow at least the toolbar as a drop target with this version of the
> > patch?
> 
> It doesn't make sense to allow the toolbar as a drop target for drags that
> didn't begin with a modifier key. You can try out this patch, and you'll see
> why. When you drag the tab downwards, you appear to pull its entire contents
> into a panel, so then it's no longer intuitive to drop it as a bookmark,
> since you're directly manipulating the tab itself.

Fun story: My mom, aunt and grandparents (all bloody novices) somehow managed to populate the bookmarks toolbar with their own stuff. They must have quickly learned from me when I set up webmail for them, or maybe the had the kids do it for them, but those aren't experts either. I'm certain that they didn't use the folder picker for this, and they shouldn't have to. I'm also certain that they wouldn't think of holding Ctrl while dragging. (By the way, they wouldn't rearrange or detach tabs either, so it's not even like we'd give them something in return.)

Combined with the desire to remove the favicon from the location bar, I think we need to keep supporting this. Frankly, I don't care if it looks a little funky, the basic functionality should be there.
Attachment #574340 - Flags: feedback?(dao)
(In reply to Dão Gottwald [:dao] from comment #30)
> Combined with the desire to remove the favicon from the location bar, I
> think we need to keep supporting this. Frankly, I don't care if it looks a
> little funky, the basic functionality should be there.

Just to note here, removing the favicon from the location bar is still going to keep the behavior of dragging to the bookmarks bar, desktop, tab strip, etc. See bug 588270 for more information.
Any chance of this being fixed for Firefox 12?
Tried the patch on Linux here.  It's a problem with the drag image, more precisely with displaying the content of the panel used as the drag image.  A ctrl+drag (copy operation), which uses the favicon as the drag image, works fine.  So does an empty panel.  

Tried to use an xul:image as the content, which also failed, so it seems likely that it's not the specific content that's a problem.
So when the panel shows on Linux, it is grabbed, which cancels the drag.  

When the panel is built, it triggers gtk2/nsWindow.cpp's CaptureRollupEvents(), which happens before the first "drag_motion" signal (which causes nsWindow::sLastDragMotionWindow to be set, which in turn would stop CaptureRollupEvents() from making a grab).  

I found that setting the panel attribute 'noautohide="true"' fixes that, as it prevents the CaptureRollupEvents() from being triggered.  That should be sufficient in this case, as it shouldn't be possible to click while dragging?

Not sure the best remedy if the underlying cause is a bug in its own right (that the nsWindow::sLastDragMotionWindow isn't set fast enough).

I also noticed the content of the panel only gets set if and when the drag enters the content area.  Until then it contains either whatever was beneath the panel when it became visible or it is gray.
Do you know why CaptureRollupEvents is called?
Is it necessary for anything or should it not be called for drag panels?

You may find that the implementation of DragInProgress() from attachment 512375 [details] [diff] [review] works better.
No, CaptureRollupEvents isn't needed for drag panels.
Depends on: 693827
Attached patch WIP patch 3 (obsolete) — Splinter Review
Attachment #574340 - Attachment is obsolete: true
How soon we'll see try-builds with animation?
There are great ideas that have came (should come) to Chrome : http://www.chromium.org/developers/design-documents/tabtastic-2-requirements
The UI animations were a P1 priority and since regression it seems that they are completely forgotten. Firefox is the only browser not to provide tab animations...
(In reply to Guillaume C. [:GE3K0S] from comment #40)
> The UI animations were a P1 priority and since regression it seems that they
> are completely forgotten. Firefox is the only browser not to provide tab
> animations...

This enhancement is no longer a top priority. It will come when we've got other higher priority changes finished.
Attached patch patch (obsolete) — Splinter Review
Things that this patch leaves to followups due to complexity:
- Dragging tabs between the app tab and non-app tabs regions
- Animating a tab to its final position upon its release
- Animating a detached tab into a window
- Hiding the window frame when a lone tab is dragged out of it
Attachment #596834 - Attachment is obsolete: true
Attachment #610902 - Flags: review?(dao)
hm, I thought we decided to keep accepting drops to bookmarks since the favicon is going aways from the locationbar.
(In reply to Marco Bonardo [:mak] from comment #43)
> hm, I thought we decided to keep accepting drops to bookmarks since the
> favicon is going aways from the locationbar.

We should accept dropping the contents of the URL bar to any Places drop target.
This patch also enables copying the tab (including history) to another location in the tab bar or to a Places drop target by beginning a drag with a modifier.
I really don't want to implement anything that confuses the conceptual model.
(In reply to Frank Yan (:fryn) from comment #42)
> - Animating a detached tab into a window
This concerns stealing focus from moved tab as Google chrome does ?
>- Dragging tabs between the app tab and non-app tabs regions
The animation should also be present with the contextual menu action.

Will this patch be pushed to UX branch ?
(In reply to Frank Yan (:fryn) from comment #44)
> We should accept dropping the contents of the URL bar to any Places drop
> target.

we do only if the whole address is selected, not much helpful. Maybe we should also allow to do that if there is no selection, at least.

> This patch also enables copying the tab (including history) to another
> location in the tab bar or to a Places drop target by beginning a drag with
> a modifier.

that was already discussed as a bad solution cause it's undiscoverable

We are basically removing all discoverable ways to bookmark with drag&drop
(In reply to Marco Bonardo [:mak] from comment #46)
> (In reply to Frank Yan (:fryn) from comment #44)
> > This patch also enables copying the tab (including history) to another
> > location in the tab bar or to a Places drop target by beginning a drag with
> > a modifier.
> 
> that was already discussed as a bad solution cause it's undiscoverable
> 
> We are basically removing all discoverable ways to bookmark with drag&drop
Trade-off are to be made. People should use the star instead.
(In reply to Guillaume C. [:GE3K0S] from comment #47)
> > We are basically removing all discoverable ways to bookmark with drag&drop
> Trade-off are to be made. People should use the star instead.

I do hope I misunderstand this.

The star doesn't even let people select where the bookmark should appear. It just lets people pop up a tunnel vision-dialog and select a folder in which they later on have try to clean up the mess. Instead of one single click using drag & drop the star may require like 10 clicks to do the same thing.
(In reply to Guillaume C. [:GE3K0S] from comment #47)
> (In reply to Marco Bonardo [:mak] from comment #46)
> > (In reply to Frank Yan (:fryn) from comment #44)
> > > This patch also enables copying the tab (including history) to another
> > > location in the tab bar or to a Places drop target by beginning a drag with
> > > a modifier.
> > 
> > that was already discussed as a bad solution cause it's undiscoverable
> > 
> > We are basically removing all discoverable ways to bookmark with drag&drop
> Trade-off are to be made.

Well, sure. I'm not convinced that tab reordering and detaching is (or is going to be) more popular than dragging tabs to the bookmarks toolbar, though.
(In reply to Marco Bonardo [:mak] from comment #43)
> hm, I thought we decided to keep accepting drops to bookmarks since the
> favicon is going aways from the locationbar.

Not until bug 588270 is fixed. Dragging the site-identity block is much more prominent and pushback on removing that feature should take place in bug 588270.

(In reply to Marco Bonardo [:mak] from comment #46)
> We are basically removing all discoverable ways to bookmark with drag&drop

(In reply to Dão Gottwald [:dao] from comment #49)
> Well, sure. I'm not convinced that tab reordering and detaching is (or is
> going to be) more popular than dragging tabs to the bookmarks toolbar,
> though.

We should defer to UX here as they should own all the interactions of the browser. If the UX team decides that this patch is the direction that we want to go in, then we should follow that.
(In reply to Jared Wein [:jaws] from comment #50)
> Not until bug 588270 is fixed. Dragging the site-identity block is much more
> prominent

Are we going to have a site identity block on any uri, even common http ones? The example there is a secure page.

(In reply to Jared Wein [:jaws] from comment #50)
> We should defer to UX here as they should own all the interactions of the
> browser

No doubt, though last time we pushed this, we got a ton of negative feedback on the bookmarks regression, we should also listen to that.  I absolutely love tabs animations, but the price/gain balance is still functionality/animations.
(In reply to Jared Wein [:jaws] from comment #50)
> (In reply to Marco Bonardo [:mak] from comment #43)
> > hm, I thought we decided to keep accepting drops to bookmarks since the
> > favicon is going aways from the locationbar.
> 
> Not until bug 588270 is fixed. Dragging the site-identity block is much more
> prominent and pushback on removing that feature should take place in bug
> 588270.

URLs will be drag/drop-capable, and site identity block too.

> (In reply to Dão Gottwald [:dao] from comment #49)
> > Well, sure. I'm not convinced that tab reordering and detaching is (or is
> > going to be) more popular than dragging tabs to the bookmarks toolbar,
> > though.
> 
> We should defer to UX here as they should own all the interactions of the
> browser. If the UX team decides that this patch is the direction that we
> want to go in, then we should follow that.

Reordering tabs is a lot more common than bookmarking via drag & drop. We also don't ship the bookmarks toolbar enabled by default since Firefox 4, so we're already in a tiny percentage of the population here. 

Reordering takes precedence over bookmarking.
In other words, patch as described in comment 42 is what we want.
(In reply to Alex Limi (:limi) — Firefox UX Team from comment #52)
> Reordering tabs is a lot more common than bookmarking via drag & drop.

Do we actually know that? (I have no doubt that it's executed more often. I have doubts that more users do it.)

> We
> also don't ship the bookmarks toolbar enabled by default since Firefox 4, so
> we're already in a tiny percentage of the population here. 

Good point about the bookmarks toolbar not being enabled by default. This means that we're not even talking about what the more popular action for all users is, but only for those who have the bookmarks toolbar enabled.
Dão, I understand your design & usability concerns, but are you willing/planning to review the patch on its technical merits despite these? (Not expecting an immediate review of course, and there almost certainly are things I need to fix technically after this first pass.) If not, I can ask another Fx peer for feedback.
(In reply to Alex Limi (:limi) — Firefox UX Team from comment #53)
> In other words, patch as described in comment 42 is what we want.

Make perfect sense. If I don't misunderstood it's exactly the same that Chrome does (in fact the best approach in current browsers).
(In reply to Dão Gottwald [:dao] from comment #54)
> (In reply to Alex Limi (:limi) — Firefox UX Team from comment #52)
> > Reordering tabs is a lot more common than bookmarking via drag & drop.
> 
> Do we actually know that? (I have no doubt that it's executed more often. I
> have doubts that more users do it.)
> 
> > We
> > also don't ship the bookmarks toolbar enabled by default since Firefox 4, so
> > we're already in a tiny percentage of the population here. 
> 
> Good point about the bookmarks toolbar not being enabled by default. This
> means that we're not even talking about what the more popular action for all
> users is, but only for those who have the bookmarks toolbar enabled.

I presume we haven't actively disabled the toolbar for existing users with non-default bookmarks inside of it. It's entirely possible we have a crowd of users for whom the change in defaults did not make a difference at all.
You might want to take this into consideration.

On prior Fx versions before the New Bookmarks Menu was place on the nav-bar, users fell into 3 categories:
Those that used the bookmarks toolbar, those that used the bookmarks sidebar, and those that didn't use either.

With the Bookmarks SideBar being removed off the nav-bar and the New Bookmarks Menu Button placed on the nav-bar.

New or average Fx users mistaken the new Bookmarks Menu button for Bookmarks Sidebar button, and those that don't know about the "Customize Toolbar" options or don't ask where the Bookmark Sidebar button went, settle for using the option in the New Bookmarks Menu button for using the Bookmarks Toolbar. So, I would think that with this happening of more new or average Fx users using the Bookmarks Toolbar more than the Bookmarks Sidebar you would reconsider this bug effects it will have on bookmark users.

Without another Test Pilot study being done regarding Bookmark toolbar's and Bookmark Sidebar usage since the landing of the New Bookmarks Menu, you inadvertently may do more harm with landing Bug 674925.

Note: From Fx 1.5 to Fx 4.0 I used the Bookmarks Sidebar, but I have now converted to using the Bookmarks Toolbar, I figure I'm not the only above average Fx user that has done so. So with more average and above average Fx users using the Bookmarks Toolbar you may need do a new Test Pilot study to know for certain.
I always used drag and drop for bookmarking. Because that's the fastest way to get the bookmark where I want it. I suspect a significant amount of people also do. Why is the desperation to make bookmarking cumbersome?

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #52)
> Reordering takes precedence over bookmarking.
If you can have both why axe one feature?

(In reply to Marco Bonardo [:mak] from comment #46)

> We are basically removing all discoverable ways to bookmark with drag&drop

True. Having only the url d&d is as good as nothing. You have to select the whole thing and it uses the url as the bookmark name instead of the page title, so useless.
(In reply to Marco Bonardo [:mak] from comment #51)
> No doubt, though last time we pushed this, we got a ton of negative feedback
> on the bookmarks regression, we should also listen to that.  I absolutely
> love tabs animations, but the price/gain balance is still
> functionality/animations.

I'm sure you will get a ton again and then some, if you remove the other ways to drag too.
What does it hurt to let people be able to drag and drop into bookmark toolbar ?
From what I read people against it are people saying bookmark toolbar is not display for a lot of user. It doesn't make a difference for most people to implement it but make a lot for those who do. Does it really add great complexity ?

Beside is there away to know which percentage of users :

- are actually reordering tabs ? I would think it's a minority ?
If users on average have only a few tab (7/8 ?) won't it be surprising if they needed reordering tabs ?

- have bookmark toolbar displayed and reorder tabs ?
- have bookmark toolbar displayed and drag and drop tabs into it ?
I don't see why we have want to drop the favicon from location bar (while also moving the star to more logical place to the bookmarks toolbar menu button), but I for sure would not expect that the average user will understand the identity block will be D&D discoverable and able to D&D to the bookmarks toolbar and more so frustrating users of that functionality if you do.  If you remove that, well then I would hate having to lose that functionality just so I can reorder my tabs which has nothing to do with reordering bookmarks or dragging my favicon to the bookmarks toolbar which is super fast compared with having to star/edit/select folder/ok.
My thoughts : I've always used D&D tabs to bookmark tabs even thought i've never used the bookmark toolbar. I've been using this feature ever since i first started using the internet with fx2, so i'm clearly against removing it. 

Animations/design should never outweigh features especially, such as these which used very often and apparently by a lot of users.
(In reply to Alex Limi (:limi) — Firefox UX Team from comment #52)
> Reordering tabs is a lot more common than bookmarking via drag & drop. We
> also don't ship the bookmarks toolbar enabled by default since Firefox 4, so
> we're already in a tiny percentage of the population here. 

Having the bookmark toolbar enabled isn't necessary to use bookmarking via drag & drop. I haven't the toolbar enabled but I drag & drop tabs in the bookmark menu button, that is enabled by default.
Just curious, would it be acceptable in the eyes of Fryn and Limi to simply have hover delay? If a user wants to drop a tab onto the bookmarks toolbar they would be required to hover over the toolbar for a brief moment before the tab transforms into a drop indicator.

That would mean that people who want to drag it elsewhere won't see the transformation and people who are expecting to be able to drop it on the toolbar will probably hover long enough to learn the new interaction. I think it's a compromise worth thinking about.
(In reply to Lozzy from comment #64)
> Just curious, would it be acceptable in the eyes of Fryn and Limi to simply
> have hover delay? If a user wants to drop a tab onto the bookmarks toolbar
> they would be required to hover over the toolbar for a brief moment before
> the tab transforms into a drop indicator.
> 
> That would mean that people who want to drag it elsewhere won't see the
> transformation and people who are expecting to be able to drop it on the
> toolbar will probably hover long enough to learn the new interaction. I
> think it's a compromise worth thinking about.

It may be a good solution. But why not simply add ability to D&D to the bookmarks toolbar and other places which used to work before? Isn't there enough space to D&D onto for creating new windows (I mean a whole content area)? What are the limitations?
I also don't use the bookmarks panel. I usually open bookmarks in the sidebar via a shortcut or a mouse gesture and D&D onto it. Some extensions (Scrapbook+) behave the same. In any case breaking it looks like a step backwards in usability.
(In reply to avada from comment #59)
> (In reply to Alex Limi (:limi) — Firefox UX Team from comment #52)
> > Reordering takes precedence over bookmarking.
> If you can have both why axe one feature?

I, for one, am annoyed when a tab I'm reordering gets bookmarked.  The tab bar (as a long-time user, I'm still using tabs on bottom) is really close to the bookmarks toolbar, and it's really easy for your tabs to become bookmarks without noticing.  When I really want to bookmark something, I drag the identity box into the bookmarks toolbar (I'm aware the identity box is going away, even though I wish it could stay - I've been using that for quite a while - but that's handled elsewhere so I will say no more).  I was happy when this was pushed last time, as I finally could reorder tabs without worrying about them getting into my bookmarks toolbar (and getting a visual feedback of the operation I was about to do.

Perhaps I represent a minority of the Fx user base, but it's just to say not everyone agrees to some of the comments above.

(In reply to Lozzy from comment #64)
> Just curious, would it be acceptable in the eyes of Fryn and Limi to simply
> have hover delay? If a user wants to drop a tab onto the bookmarks toolbar
> they would be required to hover over the toolbar for a brief moment before
> the tab transforms into a drop indicator.
> 
> That would mean that people who want to drag it elsewhere won't see the
> transformation and people who are expecting to be able to drop it on the
> toolbar will probably hover long enough to learn the new interaction. I
> think it's a compromise worth thinking about.

That would be great to me.  It would be okay for my tabs being dragged around to become bookmarks, if there was a delay (say 1 second) and a visual feedback of what would happen.  And by visual feedback, I don't mean the barely visible drop indicator we currently have, I'd rather prefer seeing the tab taking the shape of a bookmark bar entry AND seeing the "+" indicator next to the mouse pointer, as it happens in Safari and in Chrome (not sure about the Windows version, I've only ever tried the Mac one) when you drag the favicon to the bookmarks toolbar for example. (on a side note, Chrome no longer seems to have a favicon, but it has a "globe" icon that behaves like the Fx identity box, that you can still drag.)
Some thoughts about the implementation as seen in the 31 march UX build.
-The dragged tab appears as a miniature when you click on the tab. It should appears only when dragged out of the tab strip.
-The thumbnail was better in the previous implementation. Partial thumbnail is a bit weird to see. Have the whole window represented was better. A trade off - complete site thumbnail with the tab strip represented (exactly like in Google Chrome)- could be the solution.
-Bug when a plugin has stolen page focus (Flash for example). The dragged tab isn't visible.
- Drag and drop between windows has the same issue. The dragged tab disappears.

I also had a strange bug with dragged text (or even objects like in the new tab page) that always tried to load a URL when drag and drop on the page. But I don't if that was related to this bug.
Can you post the changes in the patch that just got pushed to UX branch ?
Attached patch patch v2 (obsolete) — Splinter Review
Changed detach threshold to cover the entire #navigator-toolbox rect, so that tabs can be dropped onto the bookmarks toolbar if it exists. The reattach threshold is still the tabstrip rect itself.

This patch is causing two test timeouts on Linux, due to GTK asserting and probably actually breaking, but I won't have time to debug this until next week.
Attachment #610902 - Attachment is obsolete: true
Attachment #610902 - Flags: review?(dao)
Attachment #611795 - Flags: review?(dao)
To clarify (if further needed), the problem is not just the toolbar.
there are many use-cases we are breaking:
1. drop to the toolbar
2. drop to the toolbar overflow area
3. drop to the menubar
4. drop to the bookmarks button
5. drop to the library button
6. drop to the bookmarks sidebar (quick organize into folders)
7. drop to the Library
the patch is just supporting (1), right?
hm or maybe even (2), iirc the parent is still the toolbar for the chevron menu.
(In reply to Guillaume C. [:GE3K0S] from comment #67)
> Some thoughts about the implementation as seen in the 31 march UX build.
> -The dragged tab appears as a miniature when you click on the tab. It should
> appears only when dragged out of the tab strip.
> -The thumbnail was better in the previous implementation. Partial thumbnail
> is a bit weird to see. Have the whole window represented was better. A trade
> off - complete site thumbnail with the tab strip represented (exactly like
> in Google Chrome)- could be the solution.
> -Bug when a plugin has stolen page focus (Flash for example). The dragged
> tab isn't visible.
> - Drag and drop between windows has the same issue. The dragged tab
> disappears.
> 
> I also had a strange bug with dragged text (or even objects like in the new
> tab page) that always tried to load a URL when drag and drop on the page.
> But I don't if that was related to this bug.

Still a problem in the last UX build.
There could also be nice enhancements : in Chrome when you drag a tab to the border of the window you have a nice animation and you can drop the tab here to have the two side to side.
Blocks: 485105
Blocks: 590297
Blocks: 597989
Can you land the patch back to the UX, please?
Dao: is there anything still holding up beginning review of this patch?
Comment on attachment 611795 [details] [diff] [review]
patch v2

I was told that Frank is working on an updated patch addressing some feedback.
Attachment #611795 - Flags: review?(dao)
Attached patch patch v3 (obsolete) — Splinter Review
Attachment #611795 - Attachment is obsolete: true
Attachment #635529 - Flags: review?(dao)
On Windows Aero:

Open two windows with a single tab
Make window A maximized
Make window B restored
Tear off the tab from window B
Window B is now only glass
Release the tab on top of window A.
window B appears beneath window A (and therefore cannot be seen without altering window order)

Expected results:
window B does not turn in to all glass (drag should probably not be allowed in this case)
window B stays on top of window A
I talked with Felipe about this and he told me that dragging a standalone tab to another window is necessary for merging that tab in to another tabstrip. The other issue I found should just be pushed to a followup bug so that it doesn't make this patch larger/more complicated.
Attached patch patch v3 w/ fixed ifdef (obsolete) — Splinter Review
fixed ifdef logic
Attachment #635529 - Attachment is obsolete: true
Attachment #635529 - Flags: review?(dao)
Attachment #635593 - Flags: review?(dao)
Nice but there is still a bug with this implementation : when you drag and drop content on the page itself (texte, link, etc.) the browser try to go to the page or search a corresponding address for the text.
I just have downloaded the latest-ux build, and I must say that this "Tab Animation" performance is still laggy and this state is unacceptable.
Even IE9 has better Tab Animation - it feels smooth and easy to drap tabs, while in Firefox it's only pain in the ass.

I don't know if it's based on the same Drag&Drop mechanism as New Tab Page, but if it is, devs should first fix performance problems with that mechanism.
I found an interesting problem:
Close Fx w/ more than one tab, and save the session. Then reopen the browser. Try to move a tab (not the actual). When you click on it to move, the tab will load, and you cannot move it, because the ui locks. That's very bad ux. :(

The other thing, when you want to move the last tab from a window to another, you cannot, because the window wont be hidden, just a full glass thing. But i guess that's a known problem.
(In reply to Michał from comment #82)
> I just have downloaded the latest-ux build, and I must say that this "Tab
> Animation" performance is still laggy and this state is unacceptable.

The performance issues aren't due to the patch here, but need to be fixed in a lower level area. Getting this bug fixed will elevate the priority of fixing the performance issues :)
May the other tabs move following the same accelerate-decelerate-pattern that the smooth scrolling ?
also the tab when picked out of the bar doesn't look the same as before (no fade)

Sorry for my bad english
Another useful thing : tabs dragged from the tab strip to create a new window shouldn't appear in maximized mode, even if the parent window is maximized. Currently only Internet Explorer does it that way, but I think it is an important feature.
Frank, have you had a chance to fix some of the issues that have been mentioned in the previous comments?
(In reply to Jared Wein [:jaws] from comment #87)
> Frank, have you had a chance to fix some of the issues that have been
> mentioned in the previous comments?

Which of the issues?
I don't think most of them need to be fixed in this bug, and I haven't reproduced Csaba's first issue.
(In reply to Guillaume C. [:ge3k0s] from comment #81)
> Nice but there is still a bug with this implementation : when you drag and
> drop content on the page itself (texte, link, etc.) the browser try to go to
> the page or search a corresponding address for the text.

I still see this one with a new profile and all.
(In reply to Guillaume C. [:ge3k0s] from comment #81)
> Nice but there is still a bug with this implementation : when you drag and
> drop content on the page itself (texte, link, etc.) the browser try to go to
> the page or search a corresponding address for the text.

This issue is unrelated to tab detaching. As far as I can remember the browser would navigate to the address of the text which has been dropped onto it, unless the page itself explicitly handles the drop.

If you want this to change I suggest filing a new bug with how you think it should work, if there is not already a bug about it.
(In reply to Hugh Nougher [:Hughman] from comment #90)
> (In reply to Guillaume C. [:ge3k0s] from comment #81)
> > Nice but there is still a bug with this implementation : when you drag and
> > drop content on the page itself (texte, link, etc.) the browser try to go to
> > the page or search a corresponding address for the text.
> 
> This issue is unrelated to tab detaching. As far as I can remember the
> browser would navigate to the address of the text which has been dropped
> onto it, unless the page itself explicitly handles the drop.
> 
> If you want this to change I suggest filing a new bug with how you think it
> should work, if there is not already a bug about it.

This is a regression introduced by this patch. To reproduce, perform the following stpes:

1) open a webpage with an image on it <https://msujaws.wordpress.com/2012/06/18/get-a-sneak-preview-at-the-new-australis-tabs-windows-only/>
2) drag the image located in the blog post and release it on the web content

Expected:
the user should see a circle with line through it saying that it can't be dropped there

Actual:
dropping it on the page navigates to the image. this was introduced by this patch and should be removed.
(In reply to Jared Wein [:jaws] from comment #91) 
> This is a regression introduced by this patch. To reproduce, perform the
> following stpes:
> 
> 1) open a webpage with an image on it
> <https://msujaws.wordpress.com/2012/06/18/get-a-sneak-preview-at-the-new-
> australis-tabs-windows-only/>
> 2) drag the image located in the blog post and release it on the web content
> 
> Expected:
> the user should see a circle with line through it saying that it can't be
> dropped there
> 
> Actual:
> dropping it on the page navigates to the image. this was introduced by this
> patch and should be removed.

There is a step zero in that you must first rearrange tabs. The event handlers don't seem to be cleaned up properly in this case.
(In reply to Frank Yan (:fryn) from comment #88)
> (In reply to Jared Wein [:jaws] from comment #87)
> > Frank, have you had a chance to fix some of the issues that have been
> > mentioned in the previous comments?
> 
> Which of the issues?
> I don't think most of them need to be fixed in this bug, and I haven't
> reproduced Csaba's first issue.

I just tried again w/ the latest UX build. I can still reproduce my issue. When clicking on the other tab to move, it'll start to load, and makes the browser irresponsible, so you cannot move the tab/moving is very-very slow. I'm on Windows 7. A possible solution is to load the tab only after it was moved and released by the user.
There is also a lack of consistency between OSX and Windows implementation. The dragged thumbnail on mac has an header containing the title of the tab. This doesn't appear on Windows and so the thumbnail looks weird. OSX implementation should be the reference in this case.
Attached image Tab Detach Mockup (obsolete) —
What about something like this?
Attachment #639550 - Flags: ui-review?(shorlander)
(In reply to Chris Lee (:cleer) from comment #95)
> Created attachment 639550 [details]
> Tab Distach Mockup
> 
> What about something like this?

This looks good and current OSX implementation looks like this (without the favicon), but I keep thinking that a more talking tab representation could be better (current Chrome implementation or first interaction mockup : http://www.stephenhorlander.com/images/blog-posts/tab-animation/animation-tab-tear-off.html )
The latest patch in the UX is very good. It has one bug though.
If you have 2 tabs (or more) on tab strip. Say [0][1] .
You start dragging 0 to the right of 1, it works perfectly and the tab moves with your mouse, but in that draging, without leaving the drag if you tryo to bring back the tab 0 to the left of 1, the tab stop following the mouse as soon as your mouse comes over tab 1.

That is if you started grabbing tab 0 from the middle of the tab (horizontally middle), move it to the right of tab 1, then try to move it back to its original position, it will stop at its position as soon as its half over tab 1.
Patch is broken for me on the last UX branch. Detaching the tab from the tab strip doesn't work anymore : the thumbnail doesn't appear.
Can reproduce Comment 98. Detach doesn't work for me either. Undetached animatin is the same as in Comment 97.
Comment on attachment 635593 [details] [diff] [review]
patch v3 w/ fixed ifdef

I can reproduce the issues mentioned in comment 97 and comment 98 in the UX branch nightly on Windows. Not sure if this is due to a real bug or a messed up merge. Anyway, trying to reproduce this by applying the patch myself brought my attention to the panel being hidden intentionally on Linux, which doesn't seem like an acceptable user experience for a tier-1 platform.
Attachment #635593 - Flags: review?(dao) → review-
Depends on: 782811
(In reply to Dão Gottwald [:dao] from comment #100)
> I can reproduce the issues mentioned in comment 97 and comment 98 in the UX
> branch nightly on Windows. Not sure if this is due to a real bug or a messed
> up merge.

My guess is merge, because I haven't changed the patch since I posted it.

> Anyway, trying to reproduce this by applying the patch myself
> brought my attention to the panel being hidden intentionally on Linux, which
> doesn't seem like an acceptable user experience for a tier-1 platform.

If that's not acceptable, we'll need a platform fix, before we can move forward here.
Assignee: fryn → nobody
Status: ASSIGNED → NEW
Comment on attachment 635593 [details] [diff] [review]
patch v3 w/ fixed ifdef

Dao: Actually, I think it would be most helpful if you made a full review pass on this, even in the current state.  This is a priority for Australis, and I want to shake out any remaining review issues ASAP. This bug has unfortunately languished for far too long, so it's worth some extra effort to get it back on track. Getting a full review pass will help clarify what other changes may be needed -- I don't want to do that one slow step at a time.

If a bad merge or other change makes this not work right on current-trunk, let's at least get a pass going with the Hg changeset this patch was based on.
Attachment #635593 - Flags: review- → review?
Comment on attachment 635593 [details] [diff] [review]
patch v3 w/ fixed ifdef

(grr, I fail at flags)
Attachment #635593 - Flags: review? → review?(dao)
Comment on attachment 635593 [details] [diff] [review]
patch v3 w/ fixed ifdef

Frank, please merge this to mozilla-central tip to rule out or confirm that this only stopped working on Windows due to the patch having been misapplied when landing on the UX branch.

Secondly, while I can make comments on the code, I won't be able to grant this review since I don't think it ever worked on Linux.

Finally, I'd generally appreciate if the issues pointed out by various testers over the last few months would get more attention.
Attachment #635593 - Flags: review?(dao)
While looking at bug 782811 using the patch here, I ran into a separate (related?) bug.  Even when working around that bug, the panel wasn't showing, except a brief flicker when a drag began.  Tracked it down to the style:

(patched version) browser/base/content/browser.css:91:

.tab-drag-panel:not([drag=detach]):not([drag=drop]) {
  opacity: 0;
}

Not sure if this is a problem with |drag| attribute inheritance or something else yet.
Comment on attachment 635593 [details] [diff] [review]
patch v3 w/ fixed ifdef

As I noted before, this should be ready for review on the changeset it was originally built upon: e240d6e43c9a675ecbaea450d96cf55601ea0119

My expectation is that as a large patch, you should be able to identify any other significant issues with it, so that when we produce an updated patch (rebased to current-trunk and with those comments addressed), there will be a minimum of further changes to be done before landing. [With the usual caveat that an r+ is hard to predict as the number of currently needed changes goes up.]

In other words, we know the current patch is an r- based on (1) linux issues and (2) the UX-branch merge possibly being wrong.  But is that it? What is the total best-effort list of issues (large and small) that this patch needs to address before landing?

I know this is is an unusual path to be taking, but I think it's what we need to do to help get this out of the months-long rut this patch has been stuck in awaiting review. There's no easy path here, alas.

Frank is going to be focusing on some other tasks now, but I'll find a new owner for this ASAP. Having a list of to-dos from a reviewer will make that hand-off more successful.

Additionally, if you'd rather have someone else take this review that's fine. I've asked this go to your queue simply because you know tab-related code and had concerns about the previously landed-but-now-backed-out patch. We have other competent reviewers to share the burden -- just let me know. :)

Let's chat if there are any further concerns.
Attachment #635593 - Flags: review?(dao)
(In reply to Justin Dolske [:Dolske] from comment #106)
> In other words, we know the current patch is an r- based on (1) linux issues
> and (2) the UX-branch merge possibly being wrong.  But is that it?

The problem is not that the UX branch merge is possibly wrong, but that the patch was possibly applied /correctly/, meaning that there's a deeper issue with it regardless of whether it worked against an old revision. And then, skimming through the last bunch of comments, I can identify issues (3) and (4) in comment 83 and (5) in comment 91. Any of these points may require invasive changes.
This may or may not suffer from the same breakage that's currently on the UX branch. I haven't tested this yet.
Attachment #652374 - Attachment is obsolete: true
Comment 97 is definitely not due to the merge but an issue with this patch. I ran into it again and solved it in bug 783282.
Depends on: 783282
Just as info there is a new flag in the last Chrome dev build to enable a complete view (as a window) of distached tab instead of thumbnail. I think it should be considered for Firefox too.
No longer depends on: 693827
Attachment #635593 - Attachment is obsolete: true
Attachment #635593 - Flags: review?(dao)
Comment on attachment 639550 [details]
Tab Detach Mockup

In bug 455694, I had already implemented this kind of interaction with UX approval, so there doesn't need to be any more UX review regarding this mockup.

I no longer have a screencast of that particular interaction available, but here are some related links:
a prototype from two years ago:
https://bug455694.bugzilla.mozilla.org/attachment.cgi?id=463283
a screencast of an early patch showing tab detach on Windows:
https://bug455694.bugzilla.mozilla.org/attachment.cgi?id=545132
Attachment #639550 - Attachment description: Tab Distach Mockup → Tab Detach Mockup
Attachment #639550 - Attachment filename: distach-borderless.png → detach-borderless.png
Attachment #639550 - Attachment is obsolete: true
Attachment #639550 - Flags: ui-review?(shorlander)
Keywords: regression
Currently this (http://www.chromium.org/developers/design-documents/tabtastic-2-requirements) is being implemented to Chrome on Windows (I think it's already done on OSX). It's a more modern way to handle drag and drop.
So, this is essentially the behavior we are trying to achieve. https://www.dropbox.com/s/e321ubedrr67t96/Safari.mov

That is what Safari does on OS X, and looks quite nice. We should shoot for a similar experience.
(In reply to Josiah [:JosiahOne] from comment #116)
> So, this is essentially the behavior we are trying to achieve.
> https://www.dropbox.com/s/e321ubedrr67t96/Safari.mov
> 
> That is what Safari does on OS X, and looks quite nice. We should shoot for
> a similar experience.

I personnaly prefer IE and Chrome behaviour (especially IE since the moved content stays in restored mode even if the browser is maximized).
(In reply to Guillaume C. [:ge3k0s] from comment #117)
> (In reply to Josiah [:JosiahOne] from comment #116)
> > So, this is essentially the behavior we are trying to achieve.
> > https://www.dropbox.com/s/e321ubedrr67t96/Safari.mov
> > 
> > That is what Safari does on OS X, and looks quite nice. We should shoot for
> > a similar experience.
> 
> I personnaly prefer IE and Chrome behaviour (especially IE since the moved
> content stays in restored mode even if the browser is maximized).

After looking at this, I agree that IE's behavior is the probably ideal.
Depends on: 982990
Whiteboard: [feature] p=0 → p=0
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
Summary: Use drag & drop API for tab detaching → Improve UI of detaching tabs
Depends on: 1019736
Depends on: 1019738
Depends on: 1019742
Depends on: 1019746
Depends on: 1019758
Depends on: 1019760
Depends on: 1019763
Depends on: 1019767
No longer depends on: 505521
Depends on: 1019778
Adding bug 563540 to "see also", wasn't able to add it as a dependency due to the fact that it would create a circular dependency.
See Also: → 563540
Whiteboard: p=0 [qx] → p=0 [qx:spec]
Whiteboard: p=0 [qx:spec] → [photon-animation]
Points: --- → 13
Flags: firefox-backlog+
Flags: qe-verify+
Priority: -- → P2
QA Contact: jwilliams
Depends on: 1328485
Placing into reserve backlog for now.
Priority: P2 → P3
Whiteboard: [photon-animation] → [reserve-photon-animation]
Depends on: 1365694
Priority: P3 → P4
Whiteboard: [reserve-photon-animation] → [reserve-photon-animation][tabs-p4]
Blocks: 450915
QA Contact: jwilliams → stefan.georgiev
No longer blocks: 450915
Type: defect → enhancement
Blocks: 1637238
No longer blocks: 1352117
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.