Closed
Bug 1123284
Opened 9 years ago
Closed 9 years ago
<input type="file"> displays badly in vertical writing mode
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
RESOLVED
FIXED
mozilla39
Tracking | Status | |
---|---|---|
firefox39 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 2 obsolete files)
2.41 KB,
patch
|
smontagu
:
review+
|
Details | Diff | Splinter Review |
11.56 KB,
patch
|
smontagu
:
review+
|
Details | Diff | Splinter Review |
The [Browse] button and filename field aren't sensibly positioned.
Assignee | ||
Comment 1•9 years ago
|
||
The poor sizing/positioning here happens because the anonymous content of the nsFileControlFrame uses a XUL textbox for the file label, and that doesn't handle vertical modes when considering the measurement or positioning of its text. This patch doesn't completely fix things -- for some reason, the height of the textbox gets 'stuck' instead of adjusting itself to the length of the filename -- but it does deal with the worst of the issues, so that the <input type=file> is reasonably usable.
Assignee | ||
Comment 2•9 years ago
|
||
Attachment #8566531 -
Flags: review?(smontagu)
Assignee | ||
Updated•9 years ago
|
Attachment #8553247 -
Attachment is obsolete: true
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Assignee | ||
Comment 3•9 years ago
|
||
Attachment #8566533 -
Flags: review?(smontagu)
Comment 4•9 years ago
|
||
Comment on attachment 8566531 [details] [diff] [review] pt 1 - Make nsTextBoxFrame somewhat aware of vertical writing mode, to allow <input type=file> to display properly Review of attachment 8566531 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/xul/nsTextBoxFrame.cpp @@ +523,5 @@ > > nsresult rv = NS_ERROR_FAILURE; > > + nsPoint baselinePt = vertical ? nsPoint(baseline, aTextRect.y) > + : nsPoint(aTextRect.x, baseline); Nit: can you put this next to the calculation of |baseline| above, or is there a reason not to do that? @@ +1094,5 @@ > (textStyle->mTextAlign == NS_STYLE_TEXT_ALIGN_DEFAULT && > vis->mDirection == NS_STYLE_DIRECTION_RTL) || > (textStyle->mTextAlign == NS_STYLE_TEXT_ALIGN_END && > vis->mDirection == NS_STYLE_DIRECTION_LTR)) { > + textIStart += (outerISize - textISize); This is confusing. At first I thought it was wrong for the default-align-in-rtl case, but on further consideration it's in fact correct (IIANM) because textIStart is actually the physical start in the inline axis, not a logical inline start in the sense we usually use. Can you either use a different name, or change the logic? I think I would prefer using a LogicalRect inside this method and doing GetPhysicalRect for the result.
Updated•9 years ago
|
Attachment #8566533 -
Flags: review?(smontagu) → review+
Assignee | ||
Comment 5•9 years ago
|
||
Updated as suggested in comment 4.
Attachment #8571924 -
Flags: review?(smontagu)
Assignee | ||
Updated•9 years ago
|
Attachment #8566531 -
Attachment is obsolete: true
Attachment #8566531 -
Flags: review?(smontagu)
Comment 6•9 years ago
|
||
Comment on attachment 8571924 [details] [diff] [review] pt 1 - Make nsTextBoxFrame somewhat aware of vertical writing mode, to allow <input type=file> to display properly Review of attachment 8571924 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!
Attachment #8571924 -
Flags: review?(smontagu) → review+
Assignee | ||
Comment 7•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/6b73c8abb0d0 https://hg.mozilla.org/integration/mozilla-inbound/rev/289e28bd2e3d
https://hg.mozilla.org/mozilla-central/rev/6b73c8abb0d0 https://hg.mozilla.org/mozilla-central/rev/289e28bd2e3d
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in
before you can comment on or make changes to this bug.
Description
•