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

VERIFIED FIXED in Firefox 38

Status

()

defect
P3
normal
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: stas, Assigned: Gijs)

Tracking

(Blocks 1 bug, {regression})

38 Branch
Firefox 40
Points:
1
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite -
qe-verify +

Firefox Tracking Flags

(firefox38 verified, firefox39 verified, firefox40 verified)

Details

Attachments

(3 attachments)

Reporter

Description

4 years ago
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?
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
What's more I don't see such issue with nonincontent preferences.
Component: pl / Polish → Preferences
Product: Mozilla Localizations → Firefox
Target Milestone: --- → Firefox 38
Version: unspecified → 38 Branch
Reporter

Comment 5

4 years ago
(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.
Moving back to Polish, as making content fit is the problem of the localizer, in particular if the localization breaks line break algorithms.
Component: Preferences → pl / Polish
Product: Firefox → Mozilla Localizations
Target Milestone: Firefox 38 → ---
Version: 38 Branch → unspecified
(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.
(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/
(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/
(In reply to Stefan Plewako [:stef] from comment #9)
> so https://jsfiddle.net/ss53csnt/1/

It seems I didn't save this or something…
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.
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…
Summary: Non-breaking spaces break translations → Text wrapping broken in in-content preferences
Component: pl / Polish → Preferences
Product: Mozilla Localizations → Firefox
Target Milestone: --- → Firefox 38
Version: unspecified → Firefox 38
Summary: Text wrapping broken in in-content preferences → In-content preferences: long text in localized builds is not wrapping, horizontal scrollbar displayed
As in comment 12 - not only localized builds.
Summary: In-content preferences: long text in localized builds is not wrapping, horizontal scrollbar displayed → In-content preferences: long text is not wrapping, horizontal scrollbar displayed
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?
Flags: needinfo?(splewako)
Flags: needinfo?(dao)
> (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.
Flags: needinfo?(splewako)
(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?).
(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?
(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").
(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. :(
Assignee

Comment 20

4 years ago
In the future, please write a useful bug summary and description.
Summary: In-content preferences: long text is not wrapping, horizontal scrollbar displayed → In-content preferences: long checkbox labels don't wrap, causing horizontal scrollbars at default window width (esp. on non-en-US builds, but also en-US dev-edition)
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.
Assignee

Comment 22

4 years ago
(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.
Flags: needinfo?(francesco.lodolo)
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.
Flags: needinfo?(francesco.lodolo)
Summary: In-content preferences: long checkbox labels don't wrap, causing horizontal scrollbars at default window width (esp. on non-en-US builds, but also en-US dev-edition) → In-content preferences: long text in some labels doesn't wrap and it's displayed on one line, causing horizontal scrollbars (localized build, en-US developer edition)
Assignee

Comment 24

4 years ago
(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?
Flags: needinfo?(francesco.lodolo)
Assignee

Comment 25

4 years ago
(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".
Flags: needinfo?(francesco.lodolo)
Assignee

Comment 26

4 years ago
The history part was regressed by bug 1136670.
Blocks: 1136670
Assignee

Comment 27

4 years ago
(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.
Flags: needinfo?(dao)
Assignee

Updated

4 years ago
Blocks: 1151833
Assignee

Comment 28

4 years ago
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.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Iteration: --- → 40.1 - 13 Apr
Points: --- → 1
Flags: qe-verify+
Flags: in-testsuite-
Flags: firefox-backlog+
Keywords: regression
Summary: In-content preferences: long text in some labels doesn't wrap and it's displayed on one line, causing horizontal scrollbars (localized build, en-US developer edition) → In-content preferences: long text in privacy pane doesn't wrap
Attachment #8589100 - Flags: review?(jaws) → review+
Priority: -- → P3

Comment 31

4 years ago
https://hg.mozilla.org/mozilla-central/rev/c73cf1364a02
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
QA Contact: camelia.badau
Assignee

Comment 32

4 years ago
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
Attachment #8589100 - Flags: approval-mozilla-beta?
Attachment #8589100 - Flags: approval-mozilla-aurora?
Comment on attachment 8589100 [details] [diff] [review]
fix wrapping of privacy pane,

Should be in 38 beta 3.
Attachment #8589100 - Flags: approval-mozilla-beta?
Attachment #8589100 - Flags: approval-mozilla-beta+
Attachment #8589100 - Flags: approval-mozilla-aurora?
Attachment #8589100 - Flags: approval-mozilla-aurora+
Target Milestone: Firefox 38 → Firefox 40
Mistakenly filed against Firefox 38 and should be instead 38 Branch. Sorry for the spam. dkl
Version: Firefox 38 → 38 Branch
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.
You need to log in before you can comment on or make changes to this bug.