If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

only show about:newtab on tabs opened using the mouse

ASSIGNED
Unassigned

Status

()

Firefox
New Tab Page
ASSIGNED
6 years ago
3 years ago

People

(Reporter: Gavin, Unassigned)

Tracking

({uiwanted})

Trunk
uiwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
Blocks: 455553
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.

Updated

6 years ago
Assignee: nobody → dao
Status: NEW → ASSIGNED
Created attachment 597427 [details] [diff] [review]
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...
Attachment #597427 - Flags: feedback?(ttaubert)
(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.

Updated

6 years ago
Attachment #597427 - Flags: feedback?(ttaubert) → review?(ttaubert)
(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.
or better, always show for mouse, allow to toggle behavior for keyboard (default hide)

Comment 6

6 years ago
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.
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.
*and then use the mouse
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.
Attachment #597427 - Flags: review?(ttaubert)
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.
Attachment #597427 - Flags: review?(ttaubert)
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.
Keywords: uiwanted
(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

6 years ago
(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?
(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

6 years ago
(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.

Updated

6 years ago
Assignee: dao → nobody

Comment 16

6 years ago
I suggest a compromise:
for those, who open a new tab using keyboard - just make the Awesome bar get a focus.
Comment on attachment 597427 [details] [diff] [review]
patch

Cancelling review until we hear back from UX folks about this issue.
Attachment #597427 - Flags: review?(ttaubert)

Comment 18

5 years ago
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

5 years ago
Disregard that last comment, I forgot about the menu items in the App button/File menu.
Mass-move to Firefox::New Tab Page.

Filter on new-tab-page-component.
Component: General → New Tab Page
You need to log in before you can comment on or make changes to this bug.