1741634 - The search box moves left and right every you type.

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[Alice0775 White]

Steps to reproduce:

1. Set text bigger 140% in Windows Settings, Ease of Access
2. Start Nightly
3. Open about:preferences
4. Type something e.g. sec

Actual Results:
The search box moves left and right every you type
screen cast: https://youtu.be/B7E3eJ4eVY4

Expected Results:
Do not move

Comment 1

[:Gijs (he/him)]

(In reply to Alice0775 White from comment #0)

The search box moves left and right every you type
screen cast: https://youtu.be/B7E3eJ4eVY4

This appears to be private rather than unlisted, so I can't see it?

Also, do you happen to know if this is a regression? I feel like we've fixed this before but perhaps I'm wrong about that.

Comment 2

[Alice0775 White]

(In reply to :Gijs (he/him) from comment #1)

(In reply to Alice0775 White from comment #0)

The search box moves left and right every you type
screen cast: https://youtu.be/B7E3eJ4eVY4

This appears to be private rather than unlisted, so I can't see it?

Oops, It should be viewable now.

Also, do you happen to know if this is a regression? I feel like we've fixed this before but perhaps I'm wrong about that.

This is not a regression. Just implementation error(Fixed size layout) I think.

Comment 3

[:Gijs (he/him)]

Yeah... at its heart, the issues involved here are:

1. the position of the search box depends on the width of the content area containing the prefs
2. the search box's contents control which of the items in that area are visible
3. some of those items are wider than others, and have content/text that either never wraps or isn't correctly set up to wrap
4. we use a pixel width for the width of the content area (so it doesn't scale with the user-configured text size)
5. that pixel width is not enforced (so if content is wider, the content area becomes wider).

In the general pane, I see this happening with the network settings, ie this markup:

  <hbox align="center">
    <hbox align="center" flex="1">
      <description id="connectionSettingsDescription" control="connectionSettings" data-l10n-id="network-proxy-connection-description"/>
      <spacer width="5"/>
      <label id="connectionSettingsLearnMore" class="learnMore" is="text-link"
        data-l10n-id="network-proxy-connection-learn-more">
      </label>
      <separator orient="vertical"/>
    </hbox>

    <!-- Please don't remove the wrapping hbox/vbox/box for these elements. It's used to properly compute the search tooltip position. -->
    <hbox>
      <button id="connectionSettings"
              is="highlightable-button"
              class="accessory-button"
              data-l10n-id="network-proxy-connection-settings"
              searchkeywords="doh trr"
              search-l10n-ids="[snip]" />
    </hbox>
  </hbox>

All of this content is forced to be horizontally adjacent, the "learn more" link can't wrap with the rest of the content of the description, and as a result this ends up with a significant minimum width.

Similarly, in the privacy pane on Windows the "Allow Windows single sign-on for Microsoft, work and school accounts. Learn more" bit is really wide and refuses to wrap.

I'm sure there are others, and it's probably worse in German or other locales with wider strings - these are just ones I found by changing the rule for the width of the content pane to use 500px, and then progressively deleting items until I saw in the inspector that the rendered width of the content pane decreased.

Some mitigations I can think of:

1. stop having the alignment of the search box use width: calc(100% + 8px), and resolve that width to a fixed value immediately after pageload. Downside: it might not end-align with the content if the searched-for content ends up wider than the content pane was when it loaded. Upside: this should be fairly straightforward to implement
2. enforce the content pane width as fixed even if some elements are wider. I don't know how hard this is and it feels yucky and like it'll introduce other issues.
3. fix elements that don't wrap correctly so they do wrap correctly
4. use em to set the width of the content pane such that it adjusts to a higher windows text size.

(3) and (4) are the most attractive as it's the "right" solution for what's happening here, and (3) would solve some other issues if done right (ie if we build some reusable "here is a checkbox, label, learn more and button component (with some of those being optional) that behaves correctly" component) but esp. (3) would also probably demand some significant investment. (1) is appealing because it's a "quick fix", doesn't contaminate other code, and would fix the jiggering of the search input - but it doesn't address some of our longer-term tech debt here.

Mike/Jared, what do you think?

Comment 4

[Mike Conley (:mconley) (:⚙️)]

I think we should start with (1), and file a separate bug to do (3), and perhaps make that a mentored issue? I'm only advocating for (1) because it's a pretty bad experience for a piece of UI that's exposed right at the top of about:preferences. If we can wallpaper this over now, and get a bug on file to pay down that tech debt, maybe we'll someday get a shot to either pay it down or mentor someone to help us pay it down.

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

I agree with Mike, though I think we could look at left-aligning the search box so that we don't need to have it anchored to the edge of the page that fluctuates.

Something like this:

[Search ]          
* General    |           General
* Home       |           Startup
* Search     |              [ ] Open previous windows and tabs
...                              .........

So aligned with the categories.

Comment 6

[:Gijs (he/him)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5)

I agree with Mike, though I think we could look at left-aligning the search box so that we don't need to have it anchored to the edge of the page that fluctuates.

I sympathise with this from an engineering perspective, but I also think it'd feel weird - most apps put the search box in the top-right (top-end) place. Finder, Windows Explorer, etc. etc., and the sidebar of categories isn't what you're searching so it'd be confusing to have it there, and it'd look off-center if we left-align to the start of the content pane.

I wanted to put up a patch for (1) but it's not trivial, because the top bar is non-transparent, and is meant to occlude other content if you're scrolled down on the page because it's position: sticky. We also can't "just" position the search box absolutely inside that sticky container, because if you take it out of flow and the user also gets enterprise policies, the enterprise policies start overlapping. Abs/pos'ing both of them feels like it's asking for trouble with l10n and/or other edgecases (what if the enterprise policies text wraps in other locales and then overlaps the main content?).

I spent a while trying to rejig the DOM of the prefs (why is this container even a child of the content pane?) or come up with some alternative for that but ultimately it took me too long and I was unsuccessful at figuring something out that didn't have other issues. (E.g. if I move this outside of the categories/content <stack>, the categories get moved down. I can remove the top margin that they come with by default, but even then they are further down than before (pushed down by the sticky-container at the top) and because they're in a stack that has overflow, they get clipped if I move them further up. I could try to get rid of the stack too and just force more use of HTML, but that feels like it's no longer a "small"/contained fix to this issue...

Comment 7

[:Gijs (he/him)]

Actually, thank you for rubberducking, I think I've got something...

Comment 8

[:Gijs (he/him)]

Attachment: Bug 1741634 - ensure search input doesn't move mid-search due to differing content width, r?jaws

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7366288ec078
ensure search input doesn't move mid-search due to differing content width, r=jaws,preferences-reviewers

Comment 10

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/7366288ec078

Comment 11

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

The patch landed in nightly and beta is affected.
:Gijs, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.