Verified on a recent build: 27.0a1 (2013-10-11) Options are now fine thanks to bug 900072, the about flyout still has non wrapping strings (see attached screenshot).
Summary: [l10n] Long strings in about panel are cut instead of wrapping → [l10n] Defect - Long strings in about panel are cut instead of wrapping
Whiteboard: [triage] [l10n] feature=defect c=tbd u=tbd p=0
Whiteboard: [triage] [l10n] feature=defect c=tbd u=tbd p=0 → [l10n] feature=defect c=tbd u=tbd p=0
Whiteboard: [l10n] feature=defect c=tbd u=tbd p=0 → [block28] [l10n] feature=defect c=tbd u=tbd p=0
Summary: [l10n] Defect - Long strings in about panel are cut instead of wrapping → Defect - Long strings in about panel are cut instead of wrapping
Whiteboard: [block28] [l10n] feature=defect c=tbd u=tbd p=0 → [block28] feature=defect c=tbd u=tbd p=0
Hey Matt, can you provide a point estimate.
Whiteboard: [block28] feature=defect c=tbd u=tbd p=0 → [block28] feature=defect c=tbd u=tbd p=2
I can reproduce this by putting long enough strings in the affected elements -- but I haven't found a solution yet. Even setting an explicit max width on *every* element inside the flyout had no effect. We may need to either figure out the underlying layout bug(?) or totally rework the layout here. Maybe replace the XUL boxes with standard flex or block layout.
/me taps in
Assignee: mbrubeck → sfoster
The non-wrapping issue occurs when the value of the xul label is used vs. the textContent. We have a few instances in the flyouts where we assign to .value, or use the value attribute. The new bindings extend the appropriate label bindings and implement a value setter that assigns to textContent. The selectors that apply these bindings look for a [linewrap] attribute, so we get opt-in. I've tried to balance consistency with touching the minimum lines of code; the new bindings are only used where there is an existing demonstrated or real potential problem. For this reason I've not provided a extended label-control binding. We could have the same issue there in theory, but there's no instances that do currently To test the patch, it is simplest to edit browser.xul to add some content to the labels we render, or one of the strings dtd like aboutPanel.dtd or both.
Attachment #8334203 - Flags: review?(mbrubeck)
Comment on attachment 8334203 [details] [diff] [review] Extend the label bindings to assign to textContent to get normal line-wrapping when attached Wow, nice detective work. I'm a little torn about the new binding, since it seems like we could just avoid using the "value" attribute/property... but I guess this helps to prevent future regressions.
Attachment #8334203 - Flags: review?(mbrubeck) → review+
On fx-team: https://hg.mozilla.org/integration/fx-team/rev/a9cede6f40c8 Matt and I discussed the binding vs. not on IRC. I think we're agreed this is the least risk approach for now and should be easy to apply the same linewrap fix if more instances show up
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
Nightly looks good now, but we need the fix on Aurora too if you plan to ship with Firefox 27.
(In reply to Francesco Lodolo [:flod] from comment #9) > Nightly looks good now, but we need the fix on Aurora too if you plan to > ship with Firefox 27. We no longer plan to ship with Firefox 27. We'll disable Metro in Firefox 27 on the Beta and Release channels. We are planning to ship with Firefox 28.
Verified as fixed for iteration #19, with latest it Nightly from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/12/2013-12-01-03-02-03-mozilla-central-l10n/ on Win 8 64-bit. All flyouts look alright.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.