Summary: | queryCommandState with justifyCenter, justifyLeft, and justifyRight always return false | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> | ||||||||
Component: | HTML Editing | Assignee: | Ryosuke Niwa <rniwa> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | darin, druspini, enrica, jamesr, jparent, justin.garcia, mitz, ojan, tkent, tonikitoo, tony | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | All | ||||||||||
OS: | All | ||||||||||
Bug Depends on: | 46382 | ||||||||||
Bug Blocks: | 46954 | ||||||||||
Attachments: |
|
Description
Ryosuke Niwa
2010-09-16 11:36:37 PDT
MSIE doesn't support text-align CSS property but only responds to align attribute When "world" is selected, Firefox returns left for the following markups: <div style="text-align: left;">hello<br><span style="text-align: right;">world</span></div> <div style="text-align: left;">hello world<br><span style="display: block; text-align: right;">WebKit</span></div> but I don't think we should be returning left for the latter case. It should be right instead because text-align: is respected for all block-level elements. Created attachment 67841 [details]
work in progress
This fails in the case of <div>hello<span style="text-align:right;">world</span></div> because we return right in such case but text is clearly left-aligned.
*** Bug 17593 has been marked as a duplicate of this bug. *** I'm getting -webkit-left and left, and I'm not sure what's the difference between them. I was speculating that there's some difference in how they behave in the context of RTL but it doesn't seem to be the case as far as I've tested so far. Dan, do you know if I can treat them equally for the purpose of queryCommandState? Created attachment 68572 [details] work in progress with a test I did look into the difference between -webkit-left and left and it seems like the only notable difference is in RenderBox::calcHorizontalMargins where we have: } else if ((marginRight.isAuto() && width() < containerWidth) || (!marginLeft.isAuto() && containingBlock()->style()->direction() == RTL && containingBlock()->style()->textAlign() == WEBKIT_LEFT)) { m_marginLeft = marginLeft.calcValue(containerWidth); m_marginRight = containerWidth - width() - m_marginLeft; } else if ((marginLeft.isAuto() && width() < containerWidth) || (!marginRight.isAuto() && containingBlock()->style()->direction() == LTR && containingBlock()->style()->textAlign() == WEBKIT_RIGHT)) { m_marginRight = marginRight.calcValue(containerWidth); m_marginLeft = containerWidth - width() - m_marginRight; But most importantly, RenderText::localCaretRect, RenderBlock::computeHorizontalPositionsForLine, and RenderBlock::localCaretRect treat WEBKIT_LEFT and LEFT equally (likewise for WEBKIT_RIGHT, WEBKIT_CENTER) so I'm quite convinced that we can treat -webkit-(left|right|center) and (left|right|center) equally in editing. In this new work-in-progress patch, I treat them equally in getPropertiesNotIn. Some tests fail due to the bug 41989 and the bug 46382. Created attachment 68971 [details]
Patch
Committed r68465: <http://trac.webkit.org/changeset/68465> |