The default bug view has changed. See this FAQ.

Text with "-moz-text-align-last: right" does not hug the right as the window widens

RESOLVED FIXED in mozilla13

Status

()

Core
Layout: Text
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Jesse Ruderman, Assigned: smontagu)

Tracking

(Blocks: 2 bugs, {testcase})

Trunk
mozilla13
testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 3 obsolete attachments)

(Reporter)

Description

5 years ago
Created attachment 596416 [details]
testcase

1. Load the testcase.
2. Widen the window.

Result: The text stays where it is, so it's no longer aligned to the right.

Expected: The text should move in order to stay at the right side of the window.
nsBlockFrame::PrepareResizeReflow needs to be adjusted for text-align-last, probably?
(Reporter)

Updated

5 years ago
Blocks: 373610
(Assignee)

Comment 2

5 years ago
Created attachment 596920 [details] [diff] [review]
Patch
Assignee: nobody → smontagu
Attachment #596920 - Flags: review?(dbaron)
(Assignee)

Comment 3

5 years ago
Created attachment 596921 [details] [diff] [review]
Patch
Attachment #596920 - Attachment is obsolete: true
Attachment #596920 - Flags: review?(dbaron)
Attachment #596921 - Flags: review?(dbaron)
(Assignee)

Comment 4

5 years ago
Created attachment 596923 [details] [diff] [review]
Reftests
Attachment #596923 - Flags: review?(dbaron)
Comment on attachment 596921 [details] [diff] [review]
Patch

+bool static inline IsAlignedLeft(const PRUint8 aAlignment,
+                                 const PRUint8 aDirection,
+                                 const PRUint8 aUnicodeBidi)
+{
+  return (NS_STYLE_TEXT_ALIGN_LEFT == aAlignment ||
+          (NS_STYLE_TEXT_ALIGN_DEFAULT == aAlignment &&
+           NS_STYLE_DIRECTION_LTR == aDirection &&
+           !(NS_STYLE_UNICODE_BIDI_PLAINTEXT & aUnicodeBidi)) ||
+          (NS_STYLE_TEXT_ALIGN_END == aAlignment &&
+           NS_STYLE_DIRECTION_RTL == aDirection));
+}

Two issues here:

 (1) You probably need to check unicode-bidi: plaintext for the
     rtl + end case as well, no?  (Can we have a test for that too?)
     (Yes, you're just moving an existing bug.)

 (2) You should probably add a comment above the function that it's
     a test for whether lines are *certain* to be aligned left so that
     we can make resizing optimizations.



In PrepareResizeReflow:
 * put the result of GetStyleTextReset() in a variable at the top
   (for the 2 uses)
 * inside the interesting for loop, put |isLastLine| in a variable
   since it can be used twice (once negated) and allow removing a comment
   "not the last line"

r=dbaron with that
Attachment #596921 - Flags: review?(dbaron) → review+
Comment on attachment 596923 [details] [diff] [review]
Reftests

The tests look fine... except that I'm really curious why they're fuzzy?  What part is fuzzy, and is it fixable?  I really wouldn't have expected that... and I don't think you should need it in this case.

(I might be open to changing to review+ if there's a good reason.)
Attachment #596923 - Flags: review?(dbaron) → review-
(Assignee)

Comment 7

5 years ago
Created attachment 597849 [details] [diff] [review]
Patch v.2

You might want to give this another quick look: As well as addressing your comments I've added a condition !line->IsLineWrapped() for the last line test in the for loop to catch lines that are not last lines but are followed by a forced line break, so text-align-last applies to them.
Attachment #596921 - Attachment is obsolete: true
Attachment #597849 - Flags: review?(dbaron)
(Assignee)

Comment 8

5 years ago
Created attachment 597852 [details] [diff] [review]
Reftests v.2

Adding letter-spacing makes the reftests pass without fuzz.
Attachment #596923 - Attachment is obsolete: true
Attachment #597852 - Flags: review?(dbaron)
(Assignee)

Comment 9

5 years ago
I still don't really know why the reftests needed fuzz before: they were showing differences in anti-aliasing pixels between the letters, similar to what we get when the test renders text in separate operations and the reftest renders it in one go, e.g. bug 696671 and several others. Nothing like that happens here though, my only guess is that it might be some kind of effect from rounding when calculating 50% of the width.
Comment on attachment 597852 [details] [diff] [review]
Reftests v.2

Well, r=dbaron, I guess, though the fuzz issue might be worth investigating sometime.
Attachment #597852 - Flags: review?(dbaron) → review+
Comment on attachment 597849 [details] [diff] [review]
Patch v.2

r=dbaron.  Might also be worth testing the forced-break case.  And don't forget to remove the try syntax from the commit message.
Attachment #597849 - Flags: review?(dbaron) → review+
(Assignee)

Comment 12

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/a76bb7843e73
https://hg.mozilla.org/integration/mozilla-inbound/rev/28803f706b3a
Flags: in-testsuite+
OS: Mac OS X → All
Hardware: x86_64 → All
Target Milestone: --- → mozilla13
https://hg.mozilla.org/mozilla-central/rev/6a43d088a2b4
https://hg.mozilla.org/mozilla-central/rev/a76bb7843e73
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Depends on: 729759
You need to log in before you can comment on or make changes to this bug.