1148024 - In-content preferences: long text in privacy pane doesn't wrap

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[Staś Małolepszy :stas]

It looks like some of the changes introduced in http://hg.mozilla.org/releases/l10n/mozilla-aurora/pl//rev/c97eefb0e61a have adverse effects on the UI.  I'll attach screenshots in a few.

Stef, can some of those nbsps be removed?  What was the rationale behind adding them in the first place?

Comment 1

[Staś Małolepszy :stas]

Attachment: Screenshot from 2015-03-26 17:45:12.png

Comment 2

[Staś Małolepszy :stas]

Attachment: Screenshot from 2015-03-26 17:45:38.png

Comment 3

[Stefan Plewako [:stef]]

How exactly non-breaking spaces break translations? From attached screenshots I only see wrapping issues with styling.

https://pl.wikipedia.org/wiki/Wisz%C4%85cy_sp%C3%B3jnik

Comment 4

[Stefan Plewako [:stef]]

What's more I don't see such issue with nonincontent preferences.

Comment 5

[Staś Małolepszy :stas]

(In reply to Stefan Plewako [:stef] from comment #3)
> How exactly non-breaking spaces break translations? From attached
> screenshots I only see wrapping issues with styling.

Yes, that's what I meant.  The translations are broken in sense that they don't fit the UI.

Comment 6

[Axel Hecht [:Pike]]

Moving back to Polish, as making content fit is the problem of the localizer, in particular if the localization breaks line break algorithms.

Comment 7

[Stefan Plewako [:stef]]

(In reply to Axel Hecht [:Pike] from comment #6)
> Moving back to Polish, as making content fit is the problem of the
> localizer, in particular if the localization breaks line break algorithms.

So far I see that redesign of preferences breaks a lot of stuff and apparently current line breaking algorithms - unless it is intended and will be announced appropriately to l10ns I see no valid reason to remove nbsps from pl.

Comment 8

[Francesco Lodolo [:flod]]

(In reply to Stefan Plewako [:stef] from comment #7)
> So far I see that redesign of preferences breaks a lot of stuff 
Are the issues you're seeing on bug? I'm not sure when it will be enabled on release channel, but all the issues I had were fixed in the last weeks.

> apparently current line breaking algorithms
Is it really broken? I'd expect exactly the current behavior (it shouldn't break a non breaking space)
http://jsfiddle.net/flod/ss53csnt/

Comment 9

[Stefan Plewako [:stef]]

(In reply to Francesco Lodolo [:flod] (UTC+1) from comment #8)
> > apparently current line breaking algorithms
> Is it really broken? I'd expect exactly the current behavior (it shouldn't
> break a non breaking space)
> http://jsfiddle.net/flod/ss53csnt/

Right, it shouldn't break on non-break space character but it should on standard one and it does not.
Example: rememberDescription.label (browser/chrome/browser/preferences/privacy.dtd:55) from attachment 8583967 [details] contains 2 non-breaking spaces and 13 standard spaces and over 140 characters total, so https://jsfiddle.net/ss53csnt/1/

Comment 10

[Stefan Plewako [:stef]]

(In reply to Stefan Plewako [:stef] from comment #9)
> so https://jsfiddle.net/ss53csnt/1/

It seems I didn't save this or something…

Comment 11

[Francesco Lodolo [:flod]]

Thanks, it makes more sense.

I changed the string in my Italian build with Devtools, setting it to "&brandShortName; zapamięta historię przeglądania, wyszukiwania, pobieranych plików i danych formularzy, zachowa także ciasteczka z odwiedzanych witryn." (replaced 2 non-breaking spaces with standard ones). The text doesn't wrap either.

The panel seems to have a max-width of 800px, but it's ignored (the Italian one is already 926px). 

It seems indeed a bug in the inline prefs (longer text not wrapping), unrelated to the non-breaking spaces.

Comment 12

[Stefan Plewako [:stef]]

The issue is also visible (privacy panel) in en-US Firefox Developer Edition at default window width (OS X 10.10).(In reply to Francesco Lodolo [:flod] (UTC+1) from comment #8)

> (In reply to Stefan Plewako [:stef] from comment #7)
> > So far I see that redesign of preferences breaks a lot of stuff 
> Are the issues you're seeing on bug? I'm not sure when it will be enabled on
> release channel, but all the issues I had were fixed in the last weeks.

Don't know, do not have enough time to track this but for sure some things were decided to be ignored…

Comment 13

[Stefan Plewako [:stef]]

As in comment 12 - not only localized builds.

Comment 14

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

Should we create a separate checkbox binding that uses textContent on the label to get it to wrap its contents?

(In reply to Stefan Plewako [:stef] from comment #12)
> but for sure some things were decided to be ignored…

What bugs are being ignored?

Comment 15

[Stefan Plewako [:stef]]

> (In reply to Stefan Plewako [:stef] from comment #12)
> > but for sure some things were decided to be ignored…
> 
> What bugs are being ignored?

Nooo, seriously? For example bugs caused by reusing strings in context they were not intended to be used…
I don't think this is the right place to discuss such things.

Comment 16

[Francesco Lodolo [:flod]]

(In reply to Stefan Plewako [:stef] from comment #15)
> Nooo, seriously? For example bugs caused by reusing strings in context they
> were not intended to be used…

In-content preferences change the way we're displaying preferences, they don't reorganize content AFAICT.

If you're seeing existing strings used in different contexts, it would be useful to file bugs (did you already?).

Comment 17

[Stefan Plewako [:stef]]

(In reply to Francesco Lodolo [:flod] (UTC+1) from comment #16)
> In-content preferences change the way we're displaying preferences, they
> don't reorganize content AFAICT.

Like in bug 767313 for example?

Comment 18

[Francesco Lodolo [:flod]]

(In reply to Stefan Plewako [:stef] from comment #17)
> (In reply to Francesco Lodolo [:flod] (UTC+1) from comment #16)
> > In-content preferences change the way we're displaying preferences, they
> > don't reorganize content AFAICT.
> 
> Like in bug 767313 for example?

Good point: that's definitely reorganizing content (so I stand corrected), but I wouldn't call it "reusing strings in context they were not intended to be used" either. 

The strings are used with the exact same role, the real issue is the amount of potential accesskeys conflicts that this move could cause (unless you mean this by "context").

Comment 19

[Stefan Plewako [:stef]]

(In reply to Francesco Lodolo [:flod] (UTC+1) from comment #18)
> Good point: that's definitely reorganizing content (so I stand corrected),
> but I wouldn't call it "reusing strings in context they were not intended to
> be used" either. 
> 
> The strings are used with the exact same role, the real issue is the amount
> of potential accesskeys conflicts that this move could cause (unless you
> mean this by "context").

They were not intended to be shared or displayed with some other strings and you are correct, it creates accesskeys conflicts like in http://bugs.aviary.pl/show_bug.cgi?id=4977 that are harder to correct than usual (as if in preferences we would have to many available letters) due to sharing strings between two versions of ui… so no, not potential at all. :(

Comment 20

[:Gijs (he/him)]

In the future, please write a useful bug summary and description.

Comment 21

[Francesco Lodolo [:flod]]

Don't want to start unnecessary discussions in a bug, but it's not true that this is only for checkboxes (https://bug1148024.bugzilla.mozilla.org/attachment.cgi?id=8583967) and the existing subject seemed plenty explanatory to me.

Comment 22

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] (UTC+1) from comment #21)
> Don't want to start unnecessary discussions in a bug, but it's not true that
> this is only for checkboxes
> (https://bug1148024.bugzilla.mozilla.org/attachment.cgi?id=8583967) and the
> existing subject seemed plenty explanatory to me.

Then please fix the summary accordingly. So far at least half the comments here are completely off-topic, and to me it was initially wholly unclear why this even needed to block shipping.

Comment 23

[Francesco Lodolo [:flod]]

The bug started as a potential localization issue with non-breaking spaces, it turns out text doesn't wrap in some element (not all of them), and it's just related to the length of the text.

* rememberDescription.label in Privacy panel
* useFirefoxSync.label in General panel for Developer Edition

Not sure if there are others.

Comment 24

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] (UTC+1) from comment #23)
> The bug started as a potential localization issue with non-breaking spaces,
> it turns out text doesn't wrap in some element (not all of them), and it's
> just related to the length of the text.
> 
> * rememberDescription.label in Privacy panel

This is wrapping in en-US on my beta build. What are you seeing?

Comment 25

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #24)
> (In reply to Francesco Lodolo [:flod] (UTC+1) from comment #23)
> > The bug started as a potential localization issue with non-breaking spaces,
> > it turns out text doesn't wrap in some element (not all of them), and it's
> > just related to the length of the text.
> > 
> > * rememberDescription.label in Privacy panel
> 
> This is wrapping in en-US on my beta build. What are you seeing?

Oh, so this regressed on nightly (and maybe aurora/38). The containing vbox needs flex="1".

Comment 26

[:Gijs (he/him)]

The history part was regressed by bug 1136670.

Comment 27

[:Gijs (he/him)]

(In reply to Francesco Lodolo [:flod] (UTC+1) from comment #23)
> * useFirefoxSync.label in General panel for Developer Edition

I'm not sure how we should fix this, because there's a "get started" link at the end that should stay there. :-\

It also doesn't seem critical to me considering it really only affects devedition.

AFAICT none of the affected elements are checkboxes, so clearing needinfo on Dão for now.

Comment 28

[:Gijs (he/him)]

Split off the sync devedition-only issue into bug 1151833 because it is not specific to icp and is devedition-only. I'll take this to fix the other wrapping regression.

If there are any other labels, please file a separate bug with a detailed description of which label (now) fails to wrap.

Comment 29

[:Gijs (he/him)]

Attachment: fix wrapping of privacy pane,

Comment 30

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/integration/fx-team/rev/c73cf1364a02

Comment 31

[Ekanan Ketunuti]

https://hg.mozilla.org/mozilla-central/rev/c73cf1364a02

Comment 32

[:Gijs (he/him)]

Comment on attachment 8589100 [details] [diff] [review]
fix wrapping of privacy pane,

Approval Request Comment
[Feature/regressing bug #]: bug 1136670
[User impact if declined]: long translations of the description of different history settings in the privacy pane don't wrap
[Describe test coverage new/current, TreeHerder]: nope
[Risks and why]: essentially 0, added two attributes to ensure layout of the page works and allows wrapping
[String/UUID change made/needed]: no

Comment 33

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8589100 [details] [diff] [review]
fix wrapping of privacy pane,

Should be in 38 beta 3.

Comment 34

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/27ed827e4f18

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/1f70f2dba807

Comment 36

[David Lawrence [:dkl]]

Mistakenly filed against Firefox 38 and should be instead 38 Branch. Sorry for the spam. dkl

Comment 37

[Camelia Badau [:cbadau], Desktop Test Engineering]

Verified fixed on Windows 7 64bit, Ubuntu 13.10 32bit and Mac OSX 10.9.5 using latest Nightly 40.0a1 (buildID: 20150414130911), latest Aurora 39.0a2 (buildID: 20150414004003) and Firefox 38 Beta 4 (buildID: 20150413143743) - en-US, pl, it builds.