727469 - only show about:newtab on tabs opened using the mouse

Status: RESOLVED WONTFIX

(Firefox :: New Tab Page, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

The idea being that people who use keyboard shortcuts to open tabs are less likely to find the page useful (they're more likely to use the awesomebar than to switch from keyboard to mouse) and more likely to find it distracting.

This might require propagating an event object around in a few places, but hopefully that's not too bad.

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

actually when I want to access the new tab pages I open a new tab with the keyboard shortcut... I never open a new tab with the mouse.
So maybe what should change is the default behavior, but if the user then toggles the behavior it should stick.

Comment 2

[Dão Gottwald [:dao]]

Attachment: patch

I don't think we need to pass around events here. This would mean to stop using command events as these don't carry around this information.

I'm not sure about the BROWSER_NEW_TAB_URL uses in nsBrowserAccess.prototype.openURI...

Comment 3

[Dão Gottwald [:dao]]

(In reply to Marco Bonardo [:mak] from comment #1)
> So maybe what should change is the default behavior, but if the user then
> toggles the behavior it should stick.

How would the user toggle the behavior? Are you saying we should open about:newtab with the grid disabled? And if the user enables it, save the state in a new pref? Given bug 724239, I'd rather use about:blank here.

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Dão Gottwald [:dao] from comment #3)
> How would the user toggle the behavior? Are you saying we should open
> about:newtab with the grid disabled? And if the user enables it, save the
> state in a new pref? Given bug 724239, I'd rather use about:blank here.

I didn't think about implementation details, just that if I open new tabs with keyboard and I want the thumbs, I could toggle them and next time they would be shown. So basically differentiate the show/hide also on keyboard/mouse.
Btw, was just pointing out my habits, surely I don't plan to enforce them on anyone and I can learn new habits.

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

or better, always show for mouse, allow to toggle behavior for keyboard (default hide)

Comment 6

[Alfred Kayser]

Or better, have toggles/prefs for both kind of actions, but default use the same effect for button/mouse and the key action, otherwise it will be confusing.

Comment 7

[:Felipe Gomes (needinfo for replies!)]

I don't think we should change this. Like Mak, I open all my tabs with the keyboard and then use to click on the thumbnails. I really don't think this is unusual at all. Ctrl+T is supposed to be a shortcut, not a different action.
Also, the thumbnails are tabbable, so they're useful for keyboard users too.

Comment 8

[:Felipe Gomes (needinfo for replies!)]

*and then use the mouse

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 597427 [details] [diff] [review]
patch

Review of attachment 597427 [details] [diff] [review]:
-----------------------------------------------------------------

I'm with Felipe on this, I don't think we should change this behavior. While it *might* fit my own habits I'm not sure that a casual user really gets the difference between a new tab opened by mouse and one opened by keyboard. IMHO this would be better implemented in an add-on.

Comment 10

[Dão Gottwald [:dao]]

Comment on attachment 597427 [details] [diff] [review]
patch

Saying Ctrl+T is just a shortcut ignores the fact that there is a cost involved in switching from mouse to keyboard and vice versa. Some users use the mouse and keyboard simultaneously, but at that point we're not talking about casual users anymore.

If not this bug, what are the plans for not distracting users as they want to type something in the location bar? This isn't a question of customizability and shouldn't be pushed off to add-ons.

Comment 11

[:Felipe Gomes (needinfo for replies!)]

If someone is such a heavy keyboard user that they'll be distracted by the thumbnails, they should just disable the about:newtab page.
I don't know how to explain to people that they will only get thumbnails if they open the new tab with the mouse and not with the keyboard. I expect most users will consider this a bug rather than a feature.

One alternative would be to simply dim the page with opacity if it's opened with the keyboard. Then if the mouse is moved inside the page we bring the opacity back to its original value.

Comment 12

[Dão Gottwald [:dao]]

(In reply to Felipe Gomes (:felipe) from comment #11)
> If someone is such a heavy keyboard user that they'll be distracted by the
> thumbnails, they should just disable the about:newtab page.

As I understand it this bug isn't about heavy keyboard usage only. The same user can sometimes use the keyboard and sometimes the mouse and we can in fact encourage this.

Also note that Benjamin posted to dev.apps.firefox that he didn't know how to disable the page; that's of course a different issue (I don't know if there are plans for addressing it), except that disabling it by default for keyboard usage should mitigate the incentive to completely disable the feature.

Comment 13

[Asa Dotzler [:asa]]

(In reply to Dão Gottwald [:dao] from comment #10)
> If not this bug, what are the plans for not distracting users as they want
> to type something in the location bar? This isn't a question of
> customizability and shouldn't be pushed off to add-ons.

There is a toggle in the new tab page that lets users switch back to about blank. If that UI isn't usable, we should fix that.

Also, can we not make significant UI changes to a new feature without involving the UX folks that designed the feature?

Comment 14

[:Gavin Sharp [email: [e-mail]]]

(In reply to Asa Dotzler [:asa] from comment #13)
> Also, can we not make significant UI changes to a new feature without
> involving the UX folks that designed the feature?

We haven't made any changes, and this bug is marked uiwanted.

Comment 15

[Omari Stephens]

(In reply to Asa Dotzler [:asa] from comment #13)
> (In reply to Dão Gottwald [:dao] from comment #10)
> > If not this bug, what are the plans for not distracting users as they want
> > to type something in the location bar? This isn't a question of
> > customizability and shouldn't be pushed off to add-ons.
> 
> There is a toggle in the new tab page that lets users switch back to about
> blank. If that UI isn't usable, we should fix that.
> 
> Also, can we not make significant UI changes to a new feature without
> involving the UX folks that designed the feature?

I was only able to find this after you mentioned it, so I would assert that the UI is usable but not discoverable, especially for people with large monitors.  The distracting stuff in the middle tends to attract my attention to the middle, and then I try to ignore it and I focus my attention on the AwesomeBar.  My attention never gets to the top-right corner of the screen.

Comment 16

[Sean Newman]

I suggest a compromise:
for those, who open a new tab using keyboard - just make the Awesome bar get a focus.

Comment 17

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 597427 [details] [diff] [review]
patch

Cancelling review until we hear back from UX folks about this issue.

Comment 18

[Mardeg]

Would this patch make about:newtab inaccessible to people who have dragged the "new tab" button off the tab bar to the customise dialog?

Comment 19

[Mardeg]

Disregard that last comment, I forgot about the menu items in the App button/File menu.

Comment 20

[Matthew N. [:MattN]]

Mass-move to Firefox::New Tab Page.

Filter on new-tab-page-component.

Comment 21

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 22

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 23

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 24

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 25

[Jessilyn Davis]

Hello!

This bug has been closed due to inactivity and/or the potential for this bug to no longer be an issue with the new Discovery Stream-powered New Tab experience.

Please help us triage by reopening if this issue still persists and should be addressed.

Thanks!