Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact mboldan@mozilla.com Reporter
	Description • 6 years ago

[Affected versions]:
 Fx 60.0
 Fx 61.0b11
 Fx 62.0a2

[Affected platforms]:
 Windows 10 x64
 Windows 7 x64
 mac OS X 10.13
 Ubuntu 14.04 LTS

[Steps to reproduce]:
 1. Launch Firefox.
 2. Go to about:preferences#security.
 3. Scroll down until the "Firefox Data Collection Use" section.

[Expected result]:
 All the hyperlinks are aligned.

[Actual result]:
 The "Learn more" hyperlink from "Allow Firefox to send backlogged crash reports on your behalf" is not aligned accordingly.

[Regression range]:
 Will return with the regression range as soon as possible.

[Additional notes]:
 Please note the attachment.

	Jared Wein [:jaws] (please needinfo? me)
	Comment 1 • 6 years ago

This was introduced by bug 1439930. Michael, can you try using textContent instead of setting the label via the attribute?

	Jared Wein [:jaws] (please needinfo? me)
	Comment 2 • 6 years ago

Marking as regression in the sense that we had done work to not have right-aligned Learn More links before and these two snuck in.

	Francesco Lodolo [:flod]
	Comment 3 • 6 years ago

(removing Fluent from the subject, since it doesn't seem relevant based on comment 1)

	Osmose [:osmose, :mkelly]
	Comment 4 • 6 years ago

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #1)
> This was introduced by bug 1439930. Michael, can you try using textContent
> instead of setting the label via the attribute?

I'm not super-familiar with XUL, you mean setting the `textContent` attribute on the DOM node for the checkbox, instead of using the `data-l10n-id` attribute, right?

If so, when I do that, the text label of the checkbox doesn't change. If I set it on the <xul:label> inside the checkbox element, it sets the text correctly but doesn't fix the alignment of the Learn More links.

IIRC the problem is that the only way I could find to make the checkbox properly wrap long strings to avoid expanding the width of the entire preferences page was to flex them, which has the side effect of pushing the Learn More links to the right side.

I'll ask around for XUL help to see if I can find another solution.

	Jared Wein [:jaws] (please needinfo? me)
	Comment 5 • 6 years ago

Michael, can you keep the needinfo open until you find a solution for this?

	Osmose [:osmose, :mkelly]
	Comment 6 • 6 years ago

So after further testing, I've found that most of the checkboxes in about:preferences suffer from the same wrapping problems[1]. That we don't run into this (at least not in en-US) is simply luck due to string length.

After asking around #fx-team, it seems that this is a known limitation with <label>s and <checkbox>es in XUL without a great solution. We could solve this by using HTML instead of XUL, but we'd want to convert all the checkboxes in about:preferences at once, and would have to reimplement all <checkbox> behavior in HTML/JS/CSS, maybe with a WebComponent. Additionally, I ran into issues testing this idea out[2].

I think the best course of action is to choose one of the two "broken" states and defer fixing these specific checkboxes to the larger issue of rewriting the preferences frontend in HTML:

1. Keep the `flex="1"` on the <checkbox> elements, which keeps the "Learn More" links aligned to the right. Optionally, apply this flex to other checkboxes in the preferences. This will preserve the behavior of text being wrapped.

2. Remove `flex="1"` from the two checkboxes in question. One of them will extend the width of the page, causing the "jumping search box" behavior from bug 1439930.

jaws: What do you think? I couldn't find a bug for porting the preferences UI to HTML, and don't know if that's in the long-term roadmap.

[1] That is, their labels do not wrap, but instead extend the page width if they're too long. This causes the search box to jump around while performing searches depending on whether the extended label is present in the results (bug 1439930).

[2] When I tried adding an `<input type="checkbox" />` element to about:preferences, it was not displayed on the page, although it showed up in the DOM inspector. It didn't look like CSS was hiding it.

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 7 • 6 years ago

Too late to fix in 61/62 but we could still consider it in 63 or 64.

	Gingerbread Man
	Comment 9 • 6 years ago

(In reply to Cristian Comorasu [:ccomorasu], Release Desktop QA from comment #0)
>  The "Learn more" hyperlink from "Allow Firefox to send backlogged crash
> reports on your behalf" is not aligned accordingly.

The link for "Allow Nightly to send browser error reports (including error messages) to Mozilla" is now affected as well. Please undupe bug 1489544 if it should be kept separate.

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 10 • 6 years ago

Marking fix-optional for 64. We could still take a patch for 65, and if it's verified and doesn't seem risky, could still take fixes for 64 as well.

	Pascal Chevrel:pascalc (PTO until April 26)
	Comment 11 • 6 years ago

Updating tracking flags as we get closer to the 64 release.

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 12 • 5 years ago

Happy to take a patch in nightly; if it seems low risk enough please feel free to request uplift to 65 beta.