Closed Bug 698291 Opened 8 years ago Closed 8 years ago

[dir=auto] changing window size doesn't re-renders textarea with dynamic widths

Categories

(Core :: Layout: Form Controls, defect)

10 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla11

People

(Reporter: tomer, Assigned: smontagu)

References

()

Details

(Keywords: rtl)

Attachments

(2 files, 2 obsolete files)

Steps to reproduce:
a. Unmaximize window. 
b. Load a page with dir=auto[1]
c. Maximize browser window.


Expected result:
The textarea content should be at the right side of the textarea but instead is at the center. 



[1] data:text/html,<meta%20charset="utf-8"/><textarea%20dir="auto"%20style="width:100%;font-size:200%;">%D7%91%D7%93%D7%99%D7%A7%D7%94</textarea></div>

Note that it doesn't reproduce if we emit the dynamic width from the style, as it needs less recalculations.
Tested with: Mozilla/5.0 (X11; Linux i686; rv:10.0a1) Gecko/20111030 Firefox/10.0a1
Version: unspecified → 10 Branch
This doesn't reproduce if setting dir=rtl outside of the textarea element.

data:text/html,<html%20dir="ltr"><meta%20charset="utf-8"/><textarea%20dir="auto"%20style="width:100%;font-size:200%;">%D7%91%D7%93%D7%99%D7%A7%D7%94</textarea></html>


Please note that I had a small typo in the previous testcase. There should be not </div> at the end.
I bet this happens because there is an optimization somewhere which only realigns the text to the right edge of the textarea when dir=rtl or align=right, and therefore not when dir=auto. I haven't found where that is, though.
Assignee: nobody → smontagu
OS: Linux → All
Hardware: x86 → All
Attached patch Patch (obsolete) — Splinter Review
Attachment #570603 - Flags: review?(roc)
Attached patch Reftest (obsolete) — Splinter Review
Attachment #570605 - Flags: review?(roc)
Comment on attachment 570603 [details] [diff] [review]
Patch

Shouldn't this be a bitmask check on nsStyleTextReset::mUnicodeBidi?

Otherwise looks right.
Comment on attachment 570603 [details] [diff] [review]
Patch

(In reply to David Baron [:dbaron] from comment #6)
> Comment on attachment 570603 [details] [diff] [review] [diff] [details] [review]
> Patch
> 
> Shouldn't this be a bitmask check on nsStyleTextReset::mUnicodeBidi?

Yes it should.
Attachment #570603 - Attachment is obsolete: true
Attachment #570603 - Flags: review?(roc)
Attached patch Patch v.2Splinter Review
Attachment #570610 - Flags: review?(dbaron)
Comment on attachment 570605 [details] [diff] [review]
Reftest

Review of attachment 570605 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/reftests/bidi/698291-1.html
@@ +9,5 @@
> +  document.getElementById("f").style.width="100%";
> +}
> +    </script>
> +  </head>
> +  <body onload="boom()">

This should be a MozReftestInvalidate handler, I think.
Attached patch Reftest v.2Splinter Review
Attachment #570605 - Attachment is obsolete: true
Attachment #570605 - Flags: review?(roc)
Attachment #570626 - Flags: review?(roc)
Comment on attachment 570610 [details] [diff] [review]
Patch v.2

dbaron, I moved the review request over to you because I thought from comment 6 that you had already looked over the patch and it would be trivial for you to review it. If that was wrong, please feel free to transfer the request back to roc.
Comment on attachment 570610 [details] [diff] [review]
Patch v.2

r=dbaron

(This makes me wonder whether 'plaintext' should be a value for 'direction' rather than 'unicode-bidi'...)
Attachment #570610 - Flags: review?(dbaron) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/4f9095c87c18
https://hg.mozilla.org/integration/mozilla-inbound/rev/0396b6250613
Assignee: smontagu → nobody
Component: Layout: Text → Layout: Form Controls
Flags: in-testsuite+
QA Contact: layout.fonts-and-text → layout.form-controls
https://hg.mozilla.org/mozilla-central/rev/4f9095c87c18
https://hg.mozilla.org/mozilla-central/rev/0396b6250613
Assignee: nobody → smontagu
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla11
You need to log in before you can comment on or make changes to this bug.