Cannot drag & drop Tabs to Bookmark Toolbar in Firefox 9

1518 views
Skip to first unread message

Malcolm Turmel

unread,
Aug 21, 2011, 4:25:07 AM8/21/11
to
I cannot drag and drop Tabs to the Bookmark Toolbar in Firefox 9.

The only way I can bookmark stuff now is by pressing the Star button.

How do I get the drag and drop function back in Firefox 9 nightly?


James May

unread,
Aug 21, 2011, 7:22:39 AM8/21/11
to mozilla.dev....@googlegroups.com, dev-apps...@lists.mozilla.org
I ran into that too, but I found these:

https://bugzilla.mozilla.org/show_bug.cgi?id=675451
https://bugzilla.mozilla.org/show_bug.cgi?id=675444
https://bugzilla.mozilla.org/show_bug.cgi?id=674732
https://bugzilla.mozilla.org/show_bug.cgi?id=675438

As it stands, you have to hold down control before you start dragging in
order to do these things again.

Hope this helps,
James

Matt Brubeck

unread,
Aug 21, 2011, 11:16:44 AM8/21/11
to Malcolm Turmel
On 08/21/2011 01:25 AM, Malcolm Turmel wrote:
> I cannot drag and drop Tabs to the Bookmark Toolbar in Firefox 9.
>
> The only way I can bookmark stuff now is by pressing the Star button.

You can also still drag the favicon from the address bar to the bookmark
toolbar.

Dietrich Ayala

unread,
Aug 23, 2011, 1:06:46 PM8/23/11
to James May, Frank Yan, dev-apps...@lists.mozilla.org, mozilla dev apps firefox
Frank, is there a reason why we can't have the detached tab snap back to it's original spot when dropped on an undroppable spot (toolbar, text field) yet *still* have the URL dropped?

That would allow the behavior that has existed for so long to continue for those that use it, while also providing a cohesive model to build upon for the future detaching scenarios you reference in the bug.

We've spent years convincing people that Firefox answers to no-one but them... but then with functional regressions like this we've decided we know better. While these changes might make sense to us implementers, some of our biggest cheerleaders feel like they got punched in the face.

----- Original Message -----
> I ran into that too, but I found these:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=675451
> https://bugzilla.mozilla.org/show_bug.cgi?id=675444
> https://bugzilla.mozilla.org/show_bug.cgi?id=674732
> https://bugzilla.mozilla.org/show_bug.cgi?id=675438
>
> As it stands, you have to hold down control before you start dragging
> in
> order to do these things again.
>
> Hope this helps,
> James
>
> On 21 August 2011 18:25, Malcolm Turmel <malcolm...@gmail.com>

> wrote:
>
> > I cannot drag and drop Tabs to the Bookmark Toolbar in Firefox 9.
> >
> > The only way I can bookmark stuff now is by pressing the Star
> > button.
> >

> > How do I get the drag and drop function back in Firefox 9 nightly?
> >
> >

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox

Gervase Markham

unread,
Aug 24, 2011, 5:13:57 AM8/24/11
to
On 23/08/11 18:06, Dietrich Ayala wrote:
> Frank, is there a reason why we can't have the detached tab snap back
> to it's original spot when dropped on an undroppable spot (toolbar,
> text field) yet *still* have the URL dropped?

Dietrich,

Not sure which "Frank" you are addressing, but this seems like a good
fix to me. Can you open a bug?

Gerv

Daniel Johansson

unread,
Aug 24, 2011, 2:59:28 PM8/24/11
to
> Not sure which "Frank" you are addressing, but this seems like a good
> fix to me. Can you open a bug?

Frank Yan who wrote the patch for bug 455694.

I like Dietrich's solution as well.

Drugoy

unread,
Aug 26, 2011, 9:59:29 AM8/26/11
to
The bug was already created: https://bugzilla.mozilla.org/show_bug.cgi?id=675444
And it was marked as WONTFIX three times by now.
So now you are are going to confirm it? A great win for the users,
thank you Dietrich for your wise decision.

P.S.: here was discussed only one case, where we drag a tab to
Bookmarks toolbar, but it also doesn't work anymore if we drag the tab
to Bookmarks button.

Alex Faaborg

unread,
Aug 29, 2011, 6:04:50 PM8/29/11
to Dietrich Ayala, mozilla dev apps firefox, James May, dev-apps...@lists.mozilla.org, Frank Yan
>
> is there a reason why we can't have the detached tab snap back to it's
> original spot when dropped on an undroppable spot (toolbar, text field) yet
> *still* have the URL dropped?
>

Not really, it makes tab tear off a more difficult UI operation because it
introduces a number of targets that all behave different (create a new
window, create a bookmark, etc.) We made a design decision that tab tear
off was a more important operation for the user and should take precedence.
Now obviously not every user is the same, and since this is a direct trade
off some people will disagree, but that's the nature of making high level
design decisions. I should also note that while Frank implemented this, it
was the UX team's call to focus the interaction purely on tab tear off.

-Alex


On Tue, Aug 23, 2011 at 10:06 AM, Dietrich Ayala <diet...@mozilla.com>wrote:

> Frank, is there a reason why we can't have the detached tab snap back to
> it's original spot when dropped on an undroppable spot (toolbar, text field)
> yet *still* have the URL dropped?
>

Dao

unread,
Aug 30, 2011, 2:11:12 AM8/30/11
to Alex Faaborg
On 30.08.2011 00:04, Alex Faaborg wrote:
> We made a design decision that tab tear
> off was a more important operation for the user and should take precedence.

Is this describing, based on actual observations / data, or prescribing,
based on an idea how users /should/ interact with Firefox?

If it's describing, I'm pretty sure it's false. Lots of users don't even
seem to want multiple windows.

If it's prescribing, I'm not sure it makes sense, as I wouldn't /want/
users with <10 tabs (i.e. the majority) to mess with multiple windows.

Peter Lairo

unread,
Aug 30, 2011, 6:15:35 AM8/30/11
to
On Di. 30.08.2011 08:11, Dao wrote:
> On 30.08.2011 00:04, Alex Faaborg wrote:
>> We made a design decision that tab tear
>> off was a more important operation for the user and should take
>> precedence.
>
> If it's describing, I'm pretty sure it's false. Lots of users don't even
> seem to want multiple windows.

Datapoint: I *only* dragged tabs to create bookmarks. I *never* use it
to create a new window.

To create a bookmark, the current design forces me to find and target
the much smaller favicon at the beginning of the URL. (I don't like the
"two clicks on the yellow Star" method because the folder selection UI
sucks)

> If it's prescribing, I'm not sure it makes sense, as I wouldn't /want/
> users with <10 tabs (i.e. the majority) to mess with multiple windows.

Agreed. And users who open >10 tabs will know how to use context menus
("Move to new window").

I suspect this is a classic case of "I figured out how to show this cool
thumbnail of the web page while dragging it. I'll put it into the
drag-tab-function so everyone can see how cool I am and how cool Firefox
is".
--
Regards,
Peter Lairo

Bugs I think are important:
https://bugzilla.mozilla.org/show_bug.cgi?id=250539
https://bugzilla.mozilla.org/show_bug.cgi?id=391057
https://bugzilla.mozilla.org/show_bug.cgi?id=436259
https://bugzilla.mozilla.org/show_bug.cgi?id=446444

Islam: http://www.jihadwatch.org/islam101/
Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Anthropogenic Global Warming skepsis: http://tinyurl.com/AGW-Skepsis

Martijn

unread,
Aug 30, 2011, 6:55:43 AM8/30/11
to Peter Lairo, dev-apps...@lists.mozilla.org
On Tue, Aug 30, 2011 at 12:15 PM, Peter Lairo <Pe...@lairo.com> wrote:
> On Di. 30.08.2011 08:11, Dao wrote:
>>
>> On 30.08.2011 00:04, Alex Faaborg wrote:
>>>
>>> We made a design decision that tab tear
>>> off was a more important operation for the user and should take
>>> precedence.
>>
>> If it's describing, I'm pretty sure it's false. Lots of users don't even
>> seem to want multiple windows.
>
> Datapoint: I *only* dragged tabs to create bookmarks. I *never* use it to
> create a new window.

I sometimes use it nowadays, because I often have too many tabs open
and with a new window, I can easily find that page.
That being said, I very occassionally use it.

Regards,
Martijn

> To create a bookmark, the current design forces me to find and target the
> much smaller favicon at the beginning of the URL. (I don't like the "two
> clicks on the yellow Star" method because the folder selection UI sucks)
>
>> If it's prescribing, I'm not sure it makes sense, as I wouldn't /want/
>> users with <10 tabs (i.e. the majority) to mess with multiple windows.
>
> Agreed. And users who open >10 tabs will know how to use context menus
> ("Move to new window").
>
> I suspect this is a classic case of "I figured out how to show this cool
> thumbnail of the web page while dragging it. I'll put it into the
> drag-tab-function so everyone can see how cool I am and how cool Firefox
> is".
> --
> Regards,
> Peter Lairo
>
> Bugs I think are important:
> https://bugzilla.mozilla.org/show_bug.cgi?id=250539
> https://bugzilla.mozilla.org/show_bug.cgi?id=391057
> https://bugzilla.mozilla.org/show_bug.cgi?id=436259
> https://bugzilla.mozilla.org/show_bug.cgi?id=446444
>
> Islam:  http://www.jihadwatch.org/islam101/
> Israel: http://www.jewishvirtuallibrary.org/jsource/myths2/
> Church of the Flying Spaghetti Monster:  http://www.venganza.org/
> Anthropogenic Global Warming skepsis:    http://tinyurl.com/AGW-Skepsis

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>

--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22

Mike Shaver

unread,
Aug 30, 2011, 7:20:59 AM8/30/11
to Dao, Alex Faaborg, dev-apps...@lists.mozilla.org
On Tue, Aug 30, 2011 at 2:11 AM, Dao <d...@design-noir.de> wrote:
> If it's prescribing, I'm not sure it makes sense, as I wouldn't /want/ users
> with <10 tabs (i.e. the majority) to mess with multiple windows.

I rarely have > 10 tabs other than app tabs, and never multiple
windows for organizing them, but I routinely drag off a tab in order
to be able to see two pages at once. (Also to let my daughter watch a
youtube video while I do something else. That parallel media
consumption is also a very common pattern in China AIUI, and probably
for some other people who are neither me nor Chinese.)

Mike

Dao

unread,
Aug 30, 2011, 7:37:45 AM8/30/11
to mike....@gmail.com

Would you be annoyed by the bookmarks toolbar accepting dragged tabs and
thereby preventing tab detaching? (I.e. the Firefox 3.5-7 way.)

If no, we don't have a problem. If yes, at least the shaver and China
cases could be covered by a hidden pref, I guess. My gut feeling is
still that dragging tabs to the bookmarks toolbar is more popular than
detaching.

Boris Zbarsky

unread,
Aug 30, 2011, 9:27:40 AM8/30/11
to
On 8/30/11 6:15 AM, Peter Lairo wrote:
> Datapoint: I *only* dragged tabs to create bookmarks. I *never* use it
> to create a new window.

Counter-datapoint (or rather counter-anecdote): I never drag tabs to
create bookmarks. I create bookmarks by hitting Cmd-D. I sometimes
drag tabs to reorder them, or much more commonly to drag them out to a
new window because I need to split up a task into two subtasks. This
last part sadly being pretty broken on Mac right now. :(

Also, I'd like to echo Shaver here: dragging a tab out so I can have a
youtube window for my kids to watch next to the window I'm reading an
article in is a _very_ common workflow for me. I think those without
children may underestimate how common it is for those with children,
though I am probably overestimating how common it is for people with
small screens.

That said, I've never had it be a problem that the bookmark toolbar was
not a tearoff drop target for my use cases, because I typically want to
drag to a totally different screen location, outside the current browser
window.

-Boris

Alex Faaborg

unread,
Aug 30, 2011, 9:48:43 AM8/30/11
to Boris Zbarsky, dev-apps...@lists.mozilla.org
Individual data points are of course, individual. We can pull metrics on
the exact usage of current drag and drop of tabs onto targets like the
bookmarks toolbar and text fields. The only way to build a fair comparison
though is to have this feature landed for awhile (so that people get used to
it), and then compare to the usage of tab tear off for the purpose of
tearing off tabs and moving them around.

A less metrics and more principled way to think about this would be to note
that IE / Chrome / Safari all have this style of tab tear off, so users
switching over to Firefox are going to come in with strong expectations of
behavior.

Another aspect is that the tab is visually represented as a thing (with
mass) so should the notion of it transforming into a string in a text field
is kind of strange. The URL however starts as a string, so when it is
dragged to a text field it does not have to go through an unexpected
transformation.

-Alex

> ______________________________**_________________
> dev-apps-firefox mailing list
> dev-apps-firefox@lists.**mozilla.org <dev-apps...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-apps-firefox<https://lists.mozilla.org/listinfo/dev-apps-firefox>
>

Mike Shaver

unread,
Aug 30, 2011, 9:54:17 AM8/30/11
to Boris Zbarsky, dev-apps...@lists.mozilla.org
On Tue, Aug 30, 2011 at 9:27 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> That said, I've never had it be a problem that the bookmark toolbar was not
> a tearoff drop target for my use cases, because I typically want to drag to
> a totally different screen location, outside the current browser window.

I find it to be a bit of a problem because the new window doesn't
appear where I drag, so the smallest motion is as good as the most
extravagant relocation of the tab, but I just disabled the bookmark
toolbar and now I don't randomly file my pages.

Mike

Boris Zbarsky

unread,
Aug 30, 2011, 9:59:52 AM8/30/11
to Mike Shaver, dev-apps...@lists.mozilla.org
On 8/30/11 9:54 AM, Mike Shaver wrote:
> On Tue, Aug 30, 2011 at 9:27 AM, Boris Zbarsky<bzba...@mit.edu> wrote:
>> That said, I've never had it be a problem that the bookmark toolbar was not
>> a tearoff drop target for my use cases, because I typically want to drag to
>> a totally different screen location, outside the current browser window.
>
> I find it to be a bit of a problem because the new window doesn't
> appear where I drag

On current trunk, it actually does.

-Boris

Mike Shaver

unread,
Aug 30, 2011, 10:03:48 AM8/30/11
to Boris Zbarsky, dev-apps...@lists.mozilla.org

Ah, it just won't let the window be partially off-screen. Nonetheless, better!

Mike

Dao

unread,
Aug 30, 2011, 10:43:27 AM8/30/11
to
On 30.08.2011 15:48, Alex Faaborg wrote:
> Individual data points are of course, individual. We can pull metrics on
> the exact usage of current drag and drop of tabs onto targets like the
> bookmarks toolbar and text fields. The only way to build a fair comparison
> though is to have this feature landed for awhile (so that people get used to
> it), and then compare to the usage of tab tear off for the purpose of
> tearing off tabs and moving them around.

What's a while? Should we ship it and sit out the looming outcry?

> A less metrics and more principled way to think about this would be to note
> that IE / Chrome / Safari all have this style of tab tear off, so users
> switching over to Firefox are going to come in with strong expectations of
> behavior.

I'd be more concerned about promoting the transition *to* other browsers
right now...

> Another aspect is that the tab is visually represented as a thing (with
> mass) so should the notion of it transforming into a string in a text field
> is kind of strange. The URL however starts as a string, so when it is
> dragged to a text field it does not have to go through an unexpected
> transformation.

Yes, I do not think we should support this. We didn't support it in the
past anyway, did we? I think we should support dragging to the bookmarks
toolbar and probably to the sidebar (niche anyway), with appropriate
visual feedback.

Robert Kaiser

unread,
Aug 30, 2011, 12:01:05 PM8/30/11
to
Alex Faaborg schrieb:

> Not really, it makes tab tear off a more difficult UI operation because it
> introduces a number of targets that all behave different

We already have differently behaving targets, btw: dragging a tab to the
tab bar is not creating a new window but reordering tabs. ;-)

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

Alex Faaborg

unread,
Aug 30, 2011, 1:22:32 PM8/30/11
to Dao, dev-apps...@lists.mozilla.org
>
> Should we ship it and sit out the looming outcry?
>

looking at the percent of users who drag the tab to the bookmarks toolbar
and text fields, I think we can estimate ahead of time how looming the
outcry might be. The assumption is that the outcry will be whatever the
opposite of looming is.

Normally we just launch test pilot studies on things that are controversial
or need more exploration. In this case the UX team quickly and unanimously
came to the conclusion that tearing off to create a window (or move a tab to
another window) should be the dominant use case. The bookmarks toolbar is
off by default, and dragging a tab into a text field is at best a 1% use
case.

A test pilot study would verify if our assumptions were correct, but also at
the cost of taking resources away from considerable more interesting and
relevant test pilot studies that are being created.

-Alex

Dao

unread,
Aug 30, 2011, 1:48:59 PM8/30/11
to
On 30.08.2011 19:22, Alex Faaborg wrote:
> Normally we just launch test pilot studies on things that are controversial
> or need more exploration. In this case the UX team quickly and unanimously
> came to the conclusion that tearing off to create a window (or move a tab to
> another window) should be the dominant use case.

I asked this before: What does "should be" mean? Is it not the dominant
use case right now but we want to make it so?

> The bookmarks toolbar is off by default,

Right, any change we'd make here would only affect users who enabled the
bookmarks toolbar. I don't see how this is a counter argument.

> and dragging a tab into a text field is at best a 1% use case.

Not sure how and why this entered the discussion.

Alex Faaborg

unread,
Aug 30, 2011, 2:25:36 PM8/30/11
to Dao, dev-apps...@lists.mozilla.org
>
> What does "should be" mean?
>

It means without having immediate access to the data we are making an
informed speculation. Of course if you phrase it that way it basically
sounds like guessing, but the informed part gives us a much higher chance of
being correct than random chance.

here's a our pseudo data:

dragging a tab to another window / creating a window: pretty common-ish
dragging a tab to create a bookmark: pretty uncommon-ish (based on the known
percent of users who bookmark, and the known percent of users who have
turned the toolbar back on)
dragging a tab to a text field: probably <1%-ish

Benjamin Smedberg

unread,
Aug 30, 2011, 2:30:29 PM8/30/11
to Alex Faaborg, Dao, dev-apps...@lists.mozilla.org
On 8/30/2011 2:25 PM, Alex Faaborg wrote:
>> here's a our pseudo data:
>>
>> dragging a tab to another window / creating a window: pretty common-ish
>> dragging a tab to create a bookmark: pretty uncommon-ish (based on the known
>> percent of users who bookmark, and the known percent of users who have
>> turned the toolbar back on)
>> dragging a tab to a text field: probably<1%-ish
Since this decision only affects users who have the bookmarks toolbar
on, the relevant data would be "among users who have enabled the
bookmarks toolbar, how many of them are used to dragging the tab to the
toolbar to create a bookmark", right?

I personally drag the favicon to the bookmarks toolbar to create a
bookmark, not the tab, but that may be due to ancient muscle memory from
pre-Firefox.

--BDS

Adam Kowalczyk

unread,
Aug 30, 2011, 2:35:02 PM8/30/11
to
On 2011-08-30 00:04, Alex Faaborg wrote:
>>
>> is there a reason why we can't have the detached tab snap back to it's
>> original spot when dropped on an undroppable spot (toolbar, text field) yet
>> *still* have the URL dropped?
>>
>
> Not really, it makes tab tear off a more difficult UI operation because it
> introduces a number of targets that all behave different (create a new
> window, create a bookmark, etc.)

I disagree with this assertion. It is very common for dragging to
perform different actions depending on drop location. On your desktop
dragging an mp3 file and dropping it onto a folder moves it to that
folder, dropping it onto an media player application plays it, while
dropping it onto the Recycle Bin deletes it. It is intuitive that the
action is determined by the drop location and this flexibility is
actually the main advantage of dragging as a UI operation. I think you'd
agree that "take something and throw it anywhere on the screen" is a
less common pattern, so I think it's backwards to choose it for the sake
of simplicity.

Let's focus on the use case at hand, though. When you want to put a link
on the Bookmarks Bar, dragging is more convenient than clicking on the
star in the Location Bar and using the drop-down folder picker. In fact,
it's particularly convenient for casual users, such as my parents, who
have only a handful of bookmarks and keep them all on the Bookmarks Bar.
Dragging is the solution I taught them and they find it the easiest.

Again, I don't see why it would be confusing for dragging tabs to
perform different actions depending on where they are dropped, as long
as visual feedback is provided.

- Adam

Dao

unread,
Aug 30, 2011, 2:41:47 PM8/30/11
to
On 30.08.2011 20:25, Alex Faaborg wrote:
>> What does "should be" mean?
>
> It means without having immediate access to the data we are making an
> informed speculation. Of course if you phrase it that way it basically
> sounds like guessing, but the informed part gives us a much higher chance of
> being correct than random chance.
>
> here's a our pseudo data:
>
> dragging a tab to another window / creating a window: pretty common-ish

Could you provide some insight here?

I've never seen people in the wild do this, but I probably don't observe
people long enough. What's maybe more relevant is that I can't recall
having seen laptops or private desktops with multiple windows.
Workstations might be different, but I heard those aren't our focus :)

Do we have data on how often users have more than one full browser
window? I know we do have data on the average tab count being quite low.

> dragging a tab to create a bookmark: pretty uncommon-ish (based on the known
> percent of users who bookmark, and the known percent of users who have
> turned the toolbar back on)

Again, data that suggests most people don't have the toolbar doesn't
suggest that the toolbar shouldn't accept dragged tabs when it's turned
on...

Alex Faaborg

unread,
Aug 30, 2011, 2:44:23 PM8/30/11
to Benjamin Smedberg, Dao, dev-apps...@lists.mozilla.org
>
> how many of them are used to dragging the tab to the toolbar to create a
> bookmark", right?
>

we don't want to dive into a boundary case covering a small fraction of the
overall population of users, but rather design for the entire mainstream
audience. So the assumption is that the filter:

-user who creates bookmarks
-user who turned the bookmark toolbar back on
-user who attempted to drag a tab onto the bookmark toolbar

ends up in the realm of "pretty uncommon-ish" relative to the full
population of users.


On Tue, Aug 30, 2011 at 11:30 AM, Benjamin Smedberg
<benj...@smedbergs.us>wrote:

> On 8/30/2011 2:25 PM, Alex Faaborg wrote:
>

>> here's a our pseudo data:
>>>
>>> dragging a tab to another window / creating a window: pretty common-ish

>>> dragging a tab to create a bookmark: pretty uncommon-ish (based on the
>>> known
>>> percent of users who bookmark, and the known percent of users who have
>>> turned the toolbar back on)

Alex Faaborg

unread,
Aug 30, 2011, 2:46:10 PM8/30/11
to Adam Kowalczyk, dev-apps...@lists.mozilla.org
>
> Again, I don't see why it would be confusing for dragging tabs to perform
> different actions depending on where they are dropped, as long as visual
> feedback is provided.
>

The bookmarks toolbar is directly under the tab strip (by default), so the
visual feedback is of a tab turning into a window momentarily, and then
turning into a bookmark, and then turning back into a window. This ends up
feeling kind of random if you aren't aware that the bookmarks toolbar is
actually a special target.

Alex Faaborg

unread,
Aug 30, 2011, 2:46:49 PM8/30/11
to Adam Kowalczyk, dev-apps...@lists.mozilla.org
>
> The bookmarks toolbar is directly under the tab strip (by default)
>

and of course by directly I mean kind of close, under the navigation
toolbar.


On Tue, Aug 30, 2011 at 11:46 AM, Alex Faaborg <faa...@mozilla.com> wrote:

> Again, I don't see why it would be confusing for dragging tabs to perform
>> different actions depending on where they are dropped, as long as visual
>> feedback is provided.
>>
>

> The bookmarks toolbar is directly under the tab strip (by default), so the
> visual feedback is of a tab turning into a window momentarily, and then
> turning into a bookmark, and then turning back into a window. This ends up
> feeling kind of random if you aren't aware that the bookmarks toolbar is
> actually a special target.
>
>
>
>
> On Tue, Aug 30, 2011 at 11:35 AM, Adam Kowalczyk <adam-ko...@o2.pl>wrote:
>

Alex Faaborg

unread,
Aug 30, 2011, 2:52:25 PM8/30/11
to Dao, dev-apps...@lists.mozilla.org
>
> I've never seen people in the wild do this, but I probably don't observe
> people long enough. What's maybe more relevant is that I can't recall having
> seen laptops or private desktops with multiple windows.
>

Data on Firefox users (prior to us landing this change) wouldn't be useful
as the action was previously undiscoverable and clunky. I've observed
enough Safari / Chrome / IE users interacting with their tab strips in this
way that I think it's become expected behavior for those users coming over.

Dao

unread,
Aug 30, 2011, 2:52:51 PM8/30/11
to
On 30.08.2011 20:44, Alex Faaborg wrote:
>> relevant data would be "among users who have enabled the bookmarks toolbar,
>> how many of them are used to dragging the tab to the toolbar to create a
>> bookmark", right?
>
> we don't want to dive into a boundary case covering a small fraction of the
> overall population of users, but rather design for the entire mainstream
> audience. So the assumption is that the filter:
>
> -user who creates bookmarks
> -user who turned the bookmark toolbar back on
> -user who attempted to drag a tab onto the bookmark toolbar
>
> ends up in the realm of "pretty uncommon-ish" relative to the full
> population of users.

Supporting a minority without affecting a majority doesn't defeat
designing for the entire mainstream audience. Benjamin is asking exactly
the right question.

Dao

unread,
Aug 30, 2011, 3:05:17 PM8/30/11
to
On 30.08.2011 20:52, Alex Faaborg wrote:
>> I've never seen people in the wild do this, but I probably don't observe
>> people long enough. What's maybe more relevant is that I can't recall having
>> seen laptops or private desktops with multiple windows.
>
> Data on Firefox users (prior to us landing this change) wouldn't be useful
> as the action was previously undiscoverable and clunky. I've observed
> enough Safari / Chrome / IE users interacting with their tab strips in this
> way that I think it's become expected behavior for those users coming over.

I didn't ask for data on tab tear-off, but tab tear-off is just a means
to managing multiple windows. So I was asking for data for getting an
idea of how many users want multiple windows. It should be discoverable
enough and wildly known how to create new windows, open links in new
windows, etc.. We could of course still assume that that data would be
an understatement because of improper tab tear-off support, but probably
not by an order of magnitude.

Alex Faaborg

unread,
Aug 30, 2011, 4:20:18 PM8/30/11
to Dao, dev-apps...@lists.mozilla.org
>
> Supporting a minority without affecting a majority doesn't defeat designing
> for the entire mainstream audience. Benjamin is asking exactly the right
> question.
>

Launching a test pilot study to determine user behavior after they have
already modified the default UI feels like a waste of resources to me.

Additionally the number of bookmarks one can create directly on the
bookmarks toolbar is artificially limited by the physical size of the
toolbar. So assuming people don't delete their bookmarks that often, we can
assume with some level of confidence that the number of actions is going to
be low.

Dao

unread,
Aug 30, 2011, 4:41:32 PM8/30/11
to
On 30.08.2011 22:20, Alex Faaborg wrote:
>> Supporting a minority without affecting a majority doesn't defeat designing
>> for the entire mainstream audience. Benjamin is asking exactly the right
>> question.
>
> Launching a test pilot study to determine user behavior after they have
> already modified the default UI feels like a waste of resources to me.

Why? It's one of the more popular modifications / an inherited default
setting. We didn't hide the bookmarks toolbar for users that had put
bookmarks on it.

> Additionally the number of bookmarks one can create directly on the
> bookmarks toolbar is artificially limited by the physical size of the
> toolbar. So assuming people don't delete their bookmarks that often, we can
> assume with some level of confidence that the number of actions is going to
> be low.

The number of users doing this at all seems more interesting than the
frequency. I don't think people are complaining because they want to do
this ten times a day, but when they do it once every couple of days,
they still expect it to work.

Hasse

unread,
Aug 30, 2011, 5:00:40 PM8/30/11
to
In article <mailman.7953.1314735653.4544.dev-apps-
fir...@lists.mozilla.org>, Alex Faaborg wrote...


> Additionally the number of bookmarks one can create directly on the
> bookmarks toolbar is artificially limited by the physical size of the
> toolbar. So assuming people don't delete their bookmarks that often, we can
> assume with some level of confidence that the number of actions is going to
> be low.

Have you heard of folders? You can drop as many bookmarks as you like
since folders on the bookmarks toolbar will spring open when you hold
the dragged link over them.

--
Hasse
sv-SE l10n team

Adam Kowalczyk

unread,
Aug 30, 2011, 5:06:18 PM8/30/11
to
On 2011-08-30 22:20, Alex Faaborg wrote:
>>
>> Supporting a minority without affecting a majority doesn't defeat designing
>> for the entire mainstream audience. Benjamin is asking exactly the right
>> question.
>>
>
> Launching a test pilot study to determine user behavior after they have
> already modified the default UI feels like a waste of resources to me.
>
> Additionally the number of bookmarks one can create directly on the
> bookmarks toolbar is artificially limited by the physical size of the
> toolbar. So assuming people don't delete their bookmarks that often, we can
> assume with some level of confidence that the number of actions is going to
> be low.
>

Folders?

I used to modify contents of Bookmarks Toolbar a lot. I had a folder
called Check Out Later that I would often put stuff in, I had temporary
folders related to research I was doing. Dragging is by far the quickest
way of putting bookmarks in a particular place. I use Panorama for this
purpose now but we know not everyone likes it.

It's worth explaining why I prefer dragging tabs to dragging the favicon
from the Location bar. In part it's just a habit, sure, but I think
there is more to it. When I want to bookmark a web page by dragging, I
want to drag the object that instinctively represents a "web page" in my
mind - and in the realm of Firefox UI, that's a tab. I operate on tabs
all the time: open them, close them, select them, reorder them. I hardly
ever interact with the favicon.

And weren't we removing the favicon from the Location Bar, anyway?

- Adam

Barry van Oudtshoorn

unread,
Aug 30, 2011, 8:52:53 PM8/30/11
to dev-apps...@lists.mozilla.org
On 31/08/11 02:46, Alex Faaborg wrote:
> The bookmarks toolbar is directly under the tab strip (by default), so
> the visual feedback is of a tab turning into a window momentarily, and
> then turning into a bookmark, and then turning back into a window.
> This ends up feeling kind of random if you aren't aware that the
> bookmarks toolbar is actually a special target.

Perhaps it'd be worth creating a smaller target on the bookmarks toolbar
when you start dragging a tab -- a greyed-out dotted-bordered box with a
star that says "Drop to add a bookmark", for example. I would also
suggest that the tab "morph" into a bookmark only after a second or so
of the pointer being over this target. This way, users can still easily
create bookmarks from tabs, we reduce the risk of this happening
unexpectedly or unintentionally, and the dragged tab doesn't change too
much as it's dragged.

--
Barry van Oudtshoorn
www.barryvan.com.au

Not sent from my Apple πPhone.

Christian Legnitto

unread,
Aug 30, 2011, 9:06:20 PM8/30/11
to Barry van Oudtshoorn, dev-apps...@lists.mozilla.org

I'm not saying we should change anything, but why not make holding control or option while dropping the tab switch behavior to not opening a new window? Seems like that wouldn't trip up people moving from other browsers but lets that < 1% of users have their bookmark and textarea tab dropping feature with minimal migration pain. Mode switching sucks, but it is at least similar to how Finder and Explorer moves/copies (drag with no key down = often used behavior 1, do the same thing with key down = less used behavior 2).

I feel like someone suggested this already in the thread but I can't seem to find it right now. I also rarely tear off tabs so I don't know if this key combo is already used.

Thanks,
Christian

Adam Kowalczyk

unread,
Aug 30, 2011, 9:58:58 PM8/30/11
to
On 2011-08-31 03:06, Christian Legnitto wrote:
> I'm not saying we should change anything, but why not make holding control or option while dropping the tab switch behavior to not opening a new window? Seems like that wouldn't trip up people moving from other browsers but lets that< 1% of users have their bookmark and textarea tab dropping feature with minimal migration pain. Mode switching sucks, but it is at least similar to how Finder and Explorer moves/copies (drag with no key down = often used behavior 1, do the same thing with key down = less used behavior 2).
>
> I feel like someone suggested this already in the thread but I can't seem to find it right now. I also rarely tear off tabs so I don't know if this key combo is already used.
>
> Thanks,
> Christian

It already works but, judging by reactions among nightly testers, this
isn't discoverable enough for those migrating users. And there is a
caveat, you have to press CTRL before you click, as pressing it while
dragging doesn't work. I trip on this every time and I have to cancel
the drag and start over. There was a bug to enable pressing CTRL while
already dragging but even that request was WONTFIXed. By the way,
cancelling dragging is particularly annoying because you can't do it
with ESC - in order to avoid detaching you must manually drag the tab
back to the tab bar (?!).

- Adam

Dao

unread,
Aug 31, 2011, 2:31:37 AM8/31/11
to
On 31.08.2011 03:06, Christian Legnitto wrote:
> but lets that< 1% of users have their bookmark and textarea tab dropping feature with minimal migration pain.

This figure is bogus, please don't reproduce it :/

This thread isn't about textareas and I'll assert more than 1% of our
users drop tabs on the bookmarks toolbar, unless someone has opposing data.

Mike Ratcliffe

unread,
Aug 31, 2011, 4:42:19 AM8/31/11
to dev-apps...@lists.mozilla.org
I tear off tabs often in order to open e.g. documentation in a new
window. and also drag into the bookmarks toolbar very often. If
Panorama was a visual representation of bookmarks in folders (like the
bookmarks toolbar) I would use that instead.

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox

Robert Kaiser

unread,
Aug 31, 2011, 1:05:09 PM8/31/11
to
Alex Faaborg schrieb:

> dragging a tab to a text field: probably<1%-ish

And tearing off to a new window is a >1% case? I already doubt that. But
then, I'm no UX researcher and I have no data - other than having never
had any complaints that I read in any relevant channels that SeaMonkey
doesn't support tear-off at all.

Alex Faaborg

unread,
Aug 31, 2011, 2:13:15 PM8/31/11
to Christian Legnitto, Barry van Oudtshoorn, dev-apps...@lists.mozilla.org
>
> why not make holding control or option while dropping the tab switch
> behavior to not opening a new window?
>

Interactively that's fine (main concern we are trying to avoid is confusion
and accidental bookmark creation for people who are expecting to tear the
tab off). The only downside would be the extra implementation effort and
code complexity, but those aren't aspects that I spend time caring about.

-Alex

On Tue, Aug 30, 2011 at 6:06 PM, Christian Legnitto
<cleg...@mozilla.com>wrote:

>
> On Aug 30, 2011, at 5:52 PM, Barry van Oudtshoorn wrote:
>
> > On 31/08/11 02:46, Alex Faaborg wrote:
> >> The bookmarks toolbar is directly under the tab strip (by default), so
> the visual feedback is of a tab turning into a window momentarily, and then
> turning into a bookmark, and then turning back into a window. This ends up
> feeling kind of random if you aren't aware that the bookmarks toolbar is
> actually a special target.
> >
> > Perhaps it'd be worth creating a smaller target on the bookmarks toolbar
> when you start dragging a tab -- a greyed-out dotted-bordered box with a
> star that says "Drop to add a bookmark", for example. I would also suggest
> that the tab "morph" into a bookmark only after a second or so of the
> pointer being over this target. This way, users can still easily create
> bookmarks from tabs, we reduce the risk of this happening unexpectedly or
> unintentionally, and the dragged tab doesn't change too much as it's
> dragged.
> >
>

> I'm not saying we should change anything, but why not make holding control
> or option while dropping the tab switch behavior to not opening a new
> window? Seems like that wouldn't trip up people moving from other browsers

> but lets that < 1% of users have their bookmark and textarea tab dropping

> feature with minimal migration pain. Mode switching sucks, but it is at
> least similar to how Finder and Explorer moves/copies (drag with no key down
> = often used behavior 1, do the same thing with key down = less used
> behavior 2).
>
> I feel like someone suggested this already in the thread but I can't seem
> to find it right now. I also rarely tear off tabs so I don't know if this
> key combo is already used.
>
> Thanks,
> Christian

alex_mayorga

unread,
Sep 1, 2011, 3:17:50 PM9/1/11
to
This was supposedly fixed on https://bugzilla.mozilla.org/show_bug.cgi?id=465608 but pressing ESC on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:9.0a1) Gecko/20110901 Firefox/9.0a1 ID:20110901030807 doesn't seem to cancel tab tearing.

Alex

Drugoy

unread,
Sep 1, 2011, 9:44:56 PM9/1/11
to
On Aug 31, 10:13 pm, Alex Faaborg <faab...@mozilla.com> wrote:
> > why not make holding control or option while dropping the tab switch
> > behavior to not opening a new window?
>
> Interactively that's fine (main concern we are trying to avoid is confusion
> and accidental bookmark creation for people who are expecting to tear the
> tab off).

Why don't you try to avoid confusion and accidental tab tearing the
tab off for people who are expecting to create a bookmark?

harshid

unread,
Sep 2, 2011, 5:36:16 AM9/2/11
to

I agree with Adam, the LEAST you cant do is add the ability to press
CTRL (mid-drag!!) and be able to add a tab to as a bookmark. People
who use Firefox and have been using it for long time expect things to
work in a certain way. You've improved look and feel of an existing
feature. Well done. But you've also regressed the feature to the point
where its actually broken for many users. Firefox currently allows you
to BOTH drag a tab to the bookmark toolbar or drag it outside the
window to create a new window. When dropping one feature for another,
you should at the very least make it easy for users to adjust to a new
way of doing things!

The way things are right now is really half-assed and its not
something people expect from Mozilla.

Adam Kowalczyk

unread,
Sep 2, 2011, 10:49:21 AM9/2/11
to
Hi Alex, I see bug 674723 has been definitely wontfixed and I respect
the decision even if I don't agree. There are still a few loose ends
from the discussion and I'd appreciate if you could give your final word
on them.

There are a couple of regressions that make migration more frustrating
than it has to be. A decision needs to be made on bug 675438 - "Cannot
duplicate tab if started holding CTRL key AFTER you started dragging the
tab". I trip on this every time and I have to cancel the drag and start
over. This is exacerbated by a regression that makes it impossible to
cancel detaching by pressing Escape (bug 674789). There doesn't seem to
be any controversy whether the latter bug should be fixed, so can we
please at least make it a priority to fix that?

The current combination of intentional changes and accidental
regressions is so unfortunate that it seems designed to annoy users who
relied on dragging to bookmark.

My final concern is the ability to drag the favicon in the Location Bar.
There are long-standing plans to redesign the identity button and remove
the favicon, which would presumably remove the ability to drag it. I
think I recall this concern was brought up and the response was that
you'd still be able to drag the tab instead... Could you comment on the
current status of that?

- Adam

On 2011-08-30 00:04, Alex Faaborg wrote:
>>
>> is there a reason why we can't have the detached tab snap back to it's
>> original spot when dropped on an undroppable spot (toolbar, text field) yet
>> *still* have the URL dropped?
>>
>
> Not really, it makes tab tear off a more difficult UI operation because it
> introduces a number of targets that all behave different (create a new

> window, create a bookmark, etc.) We made a design decision that tab tear
> off was a more important operation for the user and should take precedence.
> Now obviously not every user is the same, and since this is a direct trade
> off some people will disagree, but that's the nature of making high level
> design decisions. I should also note that while Frank implemented this, it
> was the UX team's call to focus the interaction purely on tab tear off.
>
> -Alex

ty.m...@gmail.com

unread,
Oct 9, 2011, 11:21:59 AM10/9/11
to Dietrich Ayala, James May, dev-apps...@lists.mozilla.org, Frank Yan
I actually use drag tab to bookmark everyday. This is a ridiculous change. I've been using Firefox for nearly 10 years and I feel the design decisions chosen for the last 3-4 years have been detrimental to the user experience. If I wanted more windows, I'd just use Internet Explorer.

ty.m...@gmail.com

unread,
Oct 9, 2011, 11:31:21 AM10/9/11
to Dao, dev-apps...@lists.mozilla.org
You just said, "looking at the percent of users who drag the tab to the bookmarks toolbar and text fields, I think we can estimate ahead of time how looming the
outcry might be."

Then, you followed it by saying, "A test pilot study would verify if our assumptions were correct..."

So what you are actually saying is, you made this decision based on how the designers use Firefox and now how your actual customers use it.

ty.m...@gmail.com

unread,
Oct 9, 2011, 11:44:00 AM10/9/11
to Dao, dev-apps...@lists.mozilla.org
You are presenting a false argument. It is true that only a limited number of bookmarks can be seen on the bookmarks toolbar, but that is not the only option for dragging tabs to a create a bookmark. Users were also able to drag a tab into a folder or subfolder on the bookmarks toolbar or into the folder tree in the bookmarks sidebar.

You cannot excuse your decision to take away useful functionality by falsely claiming the functionality wasn't very useful.

Why not just tell current Firefox users that you do not actually care how they use Firefox, if all you really care about is making Firefox exactly the same as every other browser to attract new users?

Of course the fallacy with this decision is that people switch to Firefox not because it is the same, but because it is better. If it is just like the browser they are already using, they don't have any incentive to switch.

ty.m...@gmail.com

unread,
Oct 9, 2011, 12:36:18 PM10/9/11
to
Hi, I just want to say, I'm done. For the past several years, I've put up with one detrimental change after another from the Firefox design team without any noticeable improvements. Firefox is more bloated than ever and extensions still require Firefox to be restarted. These two changes people of actually clamored for for years. Instead we get UI redesigns that do not enhance an already functional browser.

There are very few things that I actually want from a browser.
1. '/' to search within page
2. drag tabs to create bookmarks
3. extensions that are not broken every six weeks by browser updates

Up until about year ago, that's what Firefox gave me. Now the only one left is number 1. I refuse to switch to Chrome, because it does not support '/' to search. And at the rate Firefox is changing to be more like Chrome, I expect it to be gone in 6 months.

Firefox 8 does away with number 2, so I'm done with Firefox. It's been a good run. I've loyally supported Firefox since 2004. I've promoted it to family and friends and convinced people to convert. Other than Microsoft Word, there is no computer program I have used longer. I hate to change now, but I just can't put up with it any more.

It feels like the designers suffer from the same arrogance lots of businesses display. I feel like the Firefox designers care more about the customers they are trying to get than the customers they already have.

Firefox 8 gave the impetus to see what other browsers fit my needs. Opera 11 does that, so I am switching. I just wanted you to know why you have driven one loyal user away.

Asa Dotzler

unread,
Oct 9, 2011, 3:57:25 PM10/9/11
to

Ty, that's not what's being said here.

It's clear that you disagree with the change, and I'm not going to try
to convince you that it's the right change for you, but I do want to
correct you on this one point:

Our designers do not design Firefox for themselves. Our developers do
not develop Firefox for themselves. Firefox has always been and will
always be designed and built for others, the hundreds of millions, even
billions, of users who are not in the business of designing and building
browsers.

Because our designers and developers cannot know for certain what every
user wants in every possible case, they make educated guesses --
assumptions informed by years of study and experience, about what will
work out the best for users. Your characterization of those assumptions
as "how designers use Firefox" is incorrect.

- A

Ron Hunter

unread,
Oct 9, 2011, 5:30:29 PM10/9/11
to

I am sure there are MANY features of FF that I have never used, and this
is one of them. I may not be a typical user, but I would never have
noticed this feature being missing. Frankly, it makes MUCH more sense
to me to just drag the icon from the URL to the bookmarks toolbar, which
is because I rarely use ANY tabs.
There does seem to be a trend to simplify the interface by reducing the
number of ways something can be done. I also see this as a negative trend.

Eric Sh.

unread,
Oct 9, 2011, 6:02:40 PM10/9/11
to Ron Hunter, dev-apps...@lists.mozilla.org
Actually most users won't even think about dragging the icon, they would
drag the tab instead since they are used to dragging and dropping tabs.

Eric,

WLS

unread,
Oct 9, 2011, 6:57:03 PM10/9/11
to
Eric Sh. wrote:
> Actually most users won't even think about dragging the icon, they would
> drag the tab instead since they are used to dragging and dropping tabs.
>
> Eric,
>

I guess I'm not like most users.

I always use Ctrl + D, then Show All Bookmarks, find the one I just
bookmarked, highlight it, cut it, find the folder in Bookmarks Toolbar I
want it to be in, then paste it. NOT!

Really I just drag the favicon. Didn't even know you could drag the tab,
and never tried.

--

SeaMonkey 2.5b2 on openSUSE 11.3 Linux

Robert Buecheler

unread,
Oct 9, 2011, 10:14:34 PM10/9/11
to dev-apps...@lists.mozilla.org

and I thought I was like most users and come find out I'm not.
pulled the favicon at the left of the URL (now the awesomebar) onto
the bookmark toolbar or -folder ever since I started with FF. Once --
it's been a while ago -- I found out that pulling the tab would either
move its position or open it in a new window.
I do am a little peeved that the app-tab doesn't keep the original web
address and saves the last used one, as I keep gmail in it and end up
having to figure out where I am as it might be opening the last
message I was reading... but that doesn't have to do with drag&drop
tabs to bookmarks... - which I never used anyway :)

Dao

unread,
Oct 10, 2011, 10:51:06 AM10/10/11
to

There are plans to remove the favicon from the location bar, since it's
redundant (it's already on the tab) ;-)

Robert Buecheler

unread,
Oct 10, 2011, 3:57:31 PM10/10/11
to dev-apps...@lists.mozilla.org

I sure hope that the plans include a similar easy way to bookmark a page...

If drag&drop to bookmark of tab is "implemented or reinstated", then
go for it, otherwise think about the user...

al...@yahoo.com

unread,
Oct 10, 2011, 5:54:46 PM10/10/11
to
"Dao" <d...@design-noir.de> wrote in message
news:tvOdnceei6XHmw7T...@mozilla.org...

> There are plans to remove the favicon from the location bar, since it's
> redundant (it's already on the tab) ;-)

Tab bar can be hidden, so urlbar favicon is not redundant.


Eric Sh.

unread,
Oct 10, 2011, 6:52:49 PM10/10/11
to al...@yahoo.com, dev-apps...@lists.mozilla.org
I think that the block with the favicon before the url is also important
aesthetically, and now that "http" is gone it helps me feel on what type of
page I am.

If you want to minimize chrome then how about removing the "https" string?
It is already possible to recognize a secure page because the favicon clock
is highlighted.

Eric,

Alex Limi

unread,
Oct 10, 2011, 8:35:26 PM10/10/11
to Eric Sh., al...@yahoo.com, dev-apps...@lists.mozilla.org
On Mon, Oct 10, 2011 at 3:52 PM, Eric Sh. <shed...@gmail.com> wrote:

> If you want to minimize chrome then how about removing the "https" string?
> It is already possible to recognize a secure page because the favicon clock
> is highlighted.
>

We're looking into ways to do this too, but it's a bit more complicated, as
the current security indicator isn't doing a very good job at explaining
what's going on. But we're working on a better solution for it. :)

--
Alex Limi · Firefox UX Team · +limi <http://profiles.google.com/limi> ·
@limi <http://twitter.com/limi/> · limi.net

Ron Hunter

unread,
Oct 10, 2011, 9:10:39 PM10/10/11
to

Please don't. MANY users never see the tab bar as they (we) don't often
(or ever) use tabs. This would make the favicon unavailable.

Ron Hunter

unread,
Oct 10, 2011, 9:11:20 PM10/10/11
to

And don't forget the users who don't always HAVE a tab bar!

Eric Sh.

unread,
Oct 10, 2011, 11:24:32 PM10/10/11
to Ron Hunter, dev-apps...@lists.mozilla.org
If you really, and I mean really(please don't :) ) have to remove it, maybe
just remove it if the user has his tabs showing and if they are hidden show
it?

Asa Dotzler

unread,
Oct 12, 2011, 3:25:35 AM10/12/11