Bug 45910 – queryCommandState with justifyCenter, justifyLeft, and justifyRight always return false

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Ryosuke Niwa]

WebKit does not implement queryCommandValue for justifyCenter, justifyLeft, and justifyRight.

[Ryosuke Niwa]

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.

[Ryosuke Niwa]

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.

[Ryosuke Niwa]

*** Bug 17593 has been marked as a duplicate of this bug. ***

[Ryosuke Niwa]

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?

[Ryosuke Niwa]

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.

[Ryosuke Niwa]

Created attachment 68971 [details]
Patch

[Ryosuke Niwa]

Committed r68465: <http://trac.webkit.org/changeset/68465>