1631224 - option to use native widget behavior, especially in urlbar

Status: RESOLVED DUPLICATE of bug 1621570

(Firefox :: Address Bar, enhancement)

Description

[Antonio Russo]

Attachment: toggleable-native-widget-behavior.patch

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

This is a wishlist bug to have an option to allow widgets (this may be the wrong word---roughly I mean GUI elements) to behave in a platform-standard way. A patch is attached that addresses this for the urlbar. Please compare to 1621570, which is different for two critical reasons:

1. The removed option, browser.urlbar.clickSelectsAll, requested a specific behavior of widgets. This obviously will not scale: we cannot hope to implement everyone's particular desired behavior. This patch instead simply restores the native platform behavior---as additional widgets are identified with nonstandard behavior, that behavior can be simply toggled off with a single if statement.

2. The removed option required testing because it claims to describe particular behavior of a widget. This one simply requests the conventional, platform specific behavior.

I have tested this on Linux (Debian unstable), on top of 75.0. It introduces a boolean configurable option, ui.nativeWidgetBehavior, which disables custom Firefox behave in GUI elements.

Actual results:

Some widgets behave differently than would be expected from platform conventions.

Expected results:

There should be an option for widgets to behave in alignment with platform conventions.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Marco Bonardo [:mak]]

This seems just a workaround to reintroduce browser.urlbar.clickSelectsAll and we currently don't plan to do it for the reasons I explained in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1621570#c7
https://bugzilla.mozilla.org/show_bug.cgi?id=1621570#c20
https://bugzilla.mozilla.org/show_bug.cgi?id=1621570#c101

If our investigation will end up with the will to reintroduce a pref, we'll file a bug then.

Comment 3

[Antonio Russo]

I had not seen your third comment, thank you for pointing it out.

But I would like to make a point: my aspirations for this patch are not "to reintroduce browser.urlbar.clickSelectsAll", they are to more generically allow users to disable non-generic widget behavior (for instance, pressing escape selecting all text, as in UrlbarInput.handleRevert; I'll add that in the next time I recompile Firefox).

As for the maintainer burden: I'll be maintaining this patch, mainlined or not. And I'll be rebasing onto any release that gets into Debian, and posting it here. If having this around would somehow introduce developer burden to Mozilla employees, by all means wait to mainline it. But I'd appreciate not closing the bug as a duplicate, since the fundamental concern is (subtly) different than the browser.urlbar.clickSelectsAll removal---giving an option for a native widget experience to users---not inviting an explosion of nonstandard configurations.

Comment 4

[tobias]

Hi Mak, I think this proposed patch actually avoids a lot of the problems of reintroducing clickSelectsAll.
I've taken the liberty of extracting your arguments from the three linked comments of yours (reordered and slightly trimmed). Replies below in-line.

First off: I think the decision to unify the default behaviour was a good one, easing switching platforms and browsers. But please acknowledge that the removal of clickSelectsAll broke 13 years of users' muscle memory, and the new/unified behaviour breaks expectations about what is in the primary selection.

• it was a special behavior only implemented for Linux
• it was not consistent with Firefox on other OSes
• [it was not consistent] with other browsers on Linux itself.

These arguments are good for changing the default (which--again--I agree with), but not for the removal of cSA. This patch is fully opt-in, even requiring users that might have already set it in the past (accidentally or not) to take action again.

• The prefs were causing broken edge cases complicate to handle, taking into account all the possible pref combinations
• Not removing the prefs would have not saved many resources, since we still need to maintain them.
• maintaining those prefs has a cost
• and having to execute more tests for them.

When looking at how cSA and dCSA were implemented previously, this is justifiable. However, this patch is a) much shorter and therefore easier to understand and maintain and b) only a single pref, reducing combination problems significantly. The reporter also argues to just declare potential edge cases as features. Maybe the name of the pref could be changed to further emphasise that it isn't a fully supported/well tested configuration (ignoreRecommendedURLBarSelectionBehaviour, maybe?). Since this patch comes without tests for the above reasons, the fourth point isn't a problem, too.

• and at a certain point we may have to remove the pref regardless, because it would block landing improvements.

True. But maybe this bridge can be crossed once we get to it, and I am sure a lot of people (including me) would gladly send patches then.

• the change we made here will allows us to experiment more broadly with the unfocused Address Bar contents, for both UX and security reasons.
• Keeping browser.urlbar.clickSelectsAll around would make experiments a lot more problematic

This pref is not about the unfocused address bar, but what happens when the user focuses it.
Both of these also seem to be hypotheticals; again, maybe cross that bridge once we come to it.

• unfortunately sometimes changes must happen, to be able to evolve things.

I find it hard to formulate a reply to this that doesn't come across as snippy; be assured it isn't meant so: Evolution isn't a one-way street. Sometimes changes turn out to have negative side effects and need to be reevaluated.

Thanks for reading. Your work on Firefox is very well appreciated!

Comment 5

[Antonio Russo]

Attachment: implements nativeWidgetBehavior tunable

Rebasing onto 76 was, as expected, trivial. I've applied it on top of Debian's 76.0-2, and it builds. I'm running it presently.

This version additionally removes the non-native "escape selects all" behavior of the urlbar.

I'm also mirroring it on Github.

Comment 6

[Antonio Russo]

Apparently I forgot to swing by to let everyone know: rebasing on 77 was trivial. Rebasing on 78 was also trivial.

Any news on when the new features or changes that might conflict with these lines might show up?