1706583 - Make Page Actions customizable again

Status: NEW

(Firefox :: Toolbars and Customization, enhancement, P5)

Description

[TGOS]

Starting 89.0b1, page actions are no longer customizable. You cannot customize which actions appear there, now all actions appear there, if you want that or not.

Worse enough that it was never possible to change the order of actions in the address bar but now you cannot even hide them any longer. This totally clutters up my address bar, unless I uninstall tons of add-ons and thus lose tons of functionality.

Why would any user ever want to lose customizability? This is another extremely poor design decision against user friendliness.

Comment 1

[Marco Bonardo [:mak]]

How many icons do you have in the urlbar? could you please post a screenshot?

Comment 2

[Marco Bonardo [:mak]]

Ah, please don't open new bugs when a bug gets closed, you can reopen bugs (until we verify them as something we don't want to fix).

Comment 3

[TGOS]

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

Ah, please don't open new bugs when a bug gets closed, you can reopen bugs (until we verify them as something we don't want to fix).

The old bug was about the inability to do it (a "defect"), as I was assuming this surely must have been a mistake as nobody would seriously consider removing such an important UI customization. It was closed as "invalid", which means to me "we don't want to fix that" (how else should I have interpret that?). And why would I re-open an invalid bug? If it is invalid, it is invalid; reopening it will not make it valid. And when I get told it is desired behavior, it is no defect either.

This bug here is an "enhancement" request to bring back that functionality, this is an entirely different thing. Where I come from, you don't turn defects into enhancements as these are two fundamental different things (defects are problems and must be fixed, enhancements are wishes and may or may not be taken into account). In all other bug trackers I use the rule is: If you want an enhancement, you file an enhancement; you don't recycle an invalid defect report for that purpose.

If you would had wanted to re-use the old bug in such a case, you should have turned it into an enhancement request instead of closing it as invalid, like: "This is no defect, it is intended but we see you miss that behavior, so we make an enhancement out of it, keep it open and see what turns out". Closing it as invalid signals "We don't want to do that, your opinion is not welcome, go away". Turning it into a feature request welcomes users with open arms. Keep in mind that the burden to come here, create an account, fill out those forms that look like HTML 3 in the 90th and telling you about defects you should know about is a very high one for most users. For every user who does so, there are more than 100 who think exactly the same way but just get scared off by the effort.

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

How many icons do you have in the urlbar? could you please post a screenshot?

I don't know the total number, as it depends on site (not all icons are always shown). Also after some of these where highly visually annoying to me, I tried to downgrade to 88 but the browser wouldn't let me do so without losing my profile. Since that is definitely no option, I already removed three extensions because of that since I'd rather live without their functionality before getting visually annoyed by their icons. What is typically left on the sties I used is in the screenshot I'll upload.

Please note that some of these extension provide meaningful functionality beyond their address bar icon. They provide this functionality also if their icon is not visible, as they can also be accessed via toolbar, context menu, or don't need to be accessed at all and will provide functionality in the background, even if not visible at all. E.g. the RSS icon is from my feed reader. I don't usually need it in the address bar as I only subscribe to a feed once in maybe three years. Yet I use this reader daily to read news. Another one is my form history control, very useful but when I need to access it, I can do so by right clicking on a form field.

Not allowing to hide icons there is like not allowing to customize the toolbar any longer. Then please drop page actions completely and force all add-on authors to us toolbar icons only, at least I can surely customize these. Well or at least until your next UI update (I wonder when software developers will start taking care of features their customer have asked for before prioritizing those nobody has ever asked for).

Comment 4

[TGOS]

Attachment: address_bar.png

Comment 5

[Drew Willcoxon :adw]

(In reply to TGOS from comment #3)

Please note that some of these extension provide meaningful functionality beyond their address bar icon.

This is a valid point IMO. Romain, the implementation is correct per spec, but could you please run this by UX to make sure this point was considered?

Comment 6

[Marco Bonardo [:mak]]

IIRC the number of users having more than 1 add-on in the urlbar is very much low. We may consider enabling the overflow handling also if the number of actions is bigger than a threshold (like 3). The problem is that someone will still be unhappy with that solution because then it will require 2 clicks for all the actions rather than just for some. Additionally that would include the star, so you'd lose checking the bookmarked state of pages.

Comment 7

[Drew Willcoxon :adw]

That sounds like a good compromise. Could we just always show the star? It doesn't seem like a big deal to have two buttons during overflow instead of only the overflow button itself.

Comment 8

[Marco Bonardo [:mak]]

in very small windows I'd prefer to keep it like now, it's important to give space to the url in that case for safety reasons.
But we can special case the star button when not in a small window, again with simple css.
My concern is that it's not going to solve the "customization problem", it will just unclutter the bar in the many add-ons edge case.

Comment 9

[Asif Youssuff]

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

IIRC the number of users having more than 1 add-on in the urlbar is very much low. We may consider enabling the overflow handling also if the number of actions is bigger than a threshold (like 3). The problem is that someone will still be unhappy with that solution because then it will require 2 clicks for all the actions rather than just for some. Additionally that would include the star, so you'd lose checking the bookmarked state of pages.

I'm not sure I understand this solution of overflow handling - does this mean that you would force items >3 to be inside of an overflow menu? I thought the idea was to bring back the old pinning functionality that existed previously.

Comment 10

[Marco Bonardo [:mak]]

There is no more any pinning functionality, it's all or nothing.

Comment 11

[Asif Youssuff]

Forcing items into an overflow menu with no option to choose which items should be hidden seems worse than the current functionality, and indeed feels like a Hobson's choice. The previous functionality worked fine (presumably because it went through UX reviews and QA testing and user testing and reporting) - why is that not possible?

Comment 12

[Drew Willcoxon :adw]

It's technically possible, it's just not what UX has called for in Proton. I've needinfo'ed Romain, so we'll have to see what he and UX say.

Comment 13

[Marco Bonardo [:mak]]

I think it's no more possible in 89 anyway, the strings have gone.

Comment 14

[Romain Testard [:RT]]

There are 30 extensions placing a button into the page action menu with more than 20,000 users.
The most used of these extensions is used by 0,28% of our users and users with several of these were considered rare enough that moving extension page action buttons to the URL bar sould not require specific work such as the overflow menu mentioned here. This was discussed originally with UX and add-ons team. I fully realize that it may be seen as a regression for the few users that run multiple extensions with page action entries though we had to make a call on where effort would have the largest impact and most users will benefit from the meatball menu removal (less confusion when attempting to find the main menu, less UI clutter).

Comment 16

[Tomislav Jovanovic :zombie]

(In reply to Romain Testard [:RT] from comment #14)

I fully realize that it may be seen as a regression for the few users that run multiple extensions with page action entries though we had to make a call on where effort would have the largest impact and most users will benefit from the meatball menu removal (less confusion when attempting to find the main menu, less UI clutter).

Hiding the meatball menu by default didn't mean we had to remove the functionality for users who explicitly use it to hide rarely used page actions. In fact, we're keeping the implementation for small windows, and discussing special-casing the bookmark star in this bug.

It actually took effort to remove pinning functionality and adjust accompanying tests.

Comment 18

[klint]

(In reply to Asif Youssuff from comment #11)

Forcing items into an overflow menu with no option to choose which items should be hidden seems worse than the current functionality, and indeed feels like a Hobson's choice. The previous functionality worked fine (presumably because it went through UX reviews and QA testing and user testing and reporting) - why is that not possible?

Knowing that pinning pageaction icons will not be brought back, the solution of moving the ones above a certain threshold to the overflow menu is quite acceptable to me.
Actually, I would even prefer to move all icons but the star one to the threshold menu (so that there is consistency in which ones are displayed -none ;)- or hidden in the menu).
The current behaviour is really painful visually speaking as the number of diplayed icons varies depending on the browsed page.

Thank you