[webkit-dev] CSS Parse error in <link rel> element.

Mon Feb 13 00:59:29 PST 2017

I have been debugging on the CSS Parser issue and what I observed is
similar to issue described at
http://stackoverflow.com/questions/27256849/it-is-possible-to-use-vh-minus-pixels-in-a-css-calc

For example, the CSS parser is crashing while processing following:
height:calc(100vh - 200px)

I modified it as
height:calc(~"100vh - 200px")

This seems to be working. So my question is, whether CSS parser is supposed
to handle the faulty case or the CSS source should be fixed always?

Thanks,
Atul.

On Mon, Feb 13, 2017 at 2:21 PM, Atul Sowani <sowani at gmail.com> wrote:

> I am using Qt 5.5.1.
>
> On Thu, Feb 9, 2017 at 10:15 PM, Simon Fraser <simon.fraser at apple.com>
> wrote:
>
>> What WebKit revision are your sources based on? It's quite likely the
>> this bug has been fixed.
>>
>> Simon
>>
>> On Feb 9, 2017, at 4:09 AM, Atul Sowani <sowani at gmail.com> wrote:
>>
>> Finally I zeroed in on 3 "calc" candidates from the stylesheet which are
>> causing the CSS parser to fail:
>>
>> height:calc(100vh - 200px)
>> height:calc(100vh - 230px)
>> max-height:calc(100vh - 200px)
>>
>> I think it is the very first one and the remaining two never get
>> processed.
>>
>> I put in some debug statements in the code and the corresponding output
>> for this is:
>>
>> ATUL: value->id = 0 propId = 1080
>> ATUL: in CSSPropertyHeight
>> ATUL: in CSSPropertyWebkitLogicalHeight
>> ATUL: in CSSCalcValue::create
>> ATUL: in parseValueExpression, calling parseAdditiveValueExpression
>> ATUL: calling CSSCalcBinaryOperation::create from
>> parseAdditiveValueExpression
>> ATUL: operatorCharacter = -
>> ATUL: lhs = 1 rhs = 1
>> ATUL: leftSide category = ATUL: m_category = 5
>> 5
>> ATUL: rightSide category = ATUL: m_category = 1
>> 1
>> ATUL: m_category = 5
>> ASSERTION FAILED: leftSide->category() != CalcOther &&
>> rightSide->category() != CalcOther
>> css/CSSCalculationValue.cpp(293) : static WTF::PassRefPtr<WebCore::CSSCalcBinaryOperation>
>> WebCore::CSSCalcBinaryOperation::create(WTF::PassRefPtr<WebCore::CSSCalcExpressionNode>,
>> WTF::PassRefPtr<WebCore::CSSCalcExpressionNode>, WebCore::CalcOperator)
>> 1   0x12e8a80c bin/phantomjs() [0x12e8a80c]
>> < stack trace removed >
>>
>> So the question is, is the calc expression valid one?
>>
>> Best regards,
>> Atul.
>>
>> On Thu, Feb 9, 2017 at 2:17 PM, Atul Sowani <sowani at gmail.com> wrote:
>>
>>> @Konstantin thanks for the suggestions. I disabled CSS JIT on x85 but
>>> there was no negative impact on the results on x86. So I guess the issue is
>>> a genuine ppc64le problem. I have picked up the starting points mentioned
>>> in this thread earlier and debugging the issue. I have also isolated the
>>> issue to a single CSS file which is causing the problem. Now I am trying to
>>> isolate the exact entry in the CSS file which is causing the trouble.
>>>
>>> Thanks!
>>> Atul.
>>>
>>> On Tue, Feb 7, 2017 at 3:53 PM, Konstantin Tokarev <annulen at yandex.ru>
>>> wrote:
>>>
>>>>
>>>>
>>>> 07.02.2017, 12:55, "Atul Sowani" <sowani at gmail.com>:
>>>> > Thanks Geoffrey, Alex, Yoav for the debugging pointer. I am debugging
>>>> the issue further using this information and will most likely need some
>>>> more help in immediate future as well.
>>>> >
>>>> > Unfortunately, I don't have a stand-alone test case which can be
>>>> tested with qtwebkit. I am trying to load a page using PhantomJS and it's
>>>> crashing. The typical URLs which cause it to crash are
>>>> http://engadget.com and http://cnn.com - both of these load without
>>>> any issue on x86 platform though, so the issue seems to be specific to
>>>> ppc64le.
>>>>
>>>> A few suggestions:
>>>>
>>>> 1. I suppose you are building with disabled JIT, as WebKit does not
>>>> implement JIT for any PPC variant in official tree. This may introduce
>>>> subtle differences in behavior, for example I once encountered layout test
>>>> that was failing only when CSS JIT was disabled. You can try building
>>>> without JIT on x86_64 and compare.
>>>>
>>>> 2. It might be miscompilation, as your platform may not be as
>>>> thoroughly tested as more mainstream ones. You can try to build with -O0,
>>>> -O1, -O2 (default is -O3). Alternatively, try building with different
>>>> compiler (at least GCC and Clang support ppc64le and are fine for WebKit,
>>>> xlC may not work though), or try different version of your compiler.
>>>>
>>>> 3. Note that webkit-qt list is more appropriate for issues specific for
>>>> QtWebKit. Make sure you are using latest release (technology preview 5 at
>>>> the moment [1])
>>>>
>>>> [1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5
>>>>
>>>> >
>>>> > Thanks,
>>>> > Atul.
>>>> >
>>>> > On Mon, Feb 6, 2017 at 5:56 PM, Yoav Weiss <yoav at yoav.ws> wrote:
>>>> >> Hi Atul,
>>>> >>
>>>> >> I second Alex's suggestion (perhaps followed by
>>>> HTMLLinkElement::process() and other places in that file that refer to
>>>> `hrefAttr`).
>>>> >> If you have a test case online, I could try to take a look and maybe
>>>> provide more guidance.
>>>> >>
>>>> >> Cheers :)
>>>> >> Yoav
>>>> >>
>>>> >> On Fri, Feb 3, 2017 at 9:19 PM Alex Christensen <
>>>> achristensen at apple.com> wrote:
>>>> >>> I would start looking at HTMLLinkElement::parseAttribute.
>>>> >>> LinkHeader.cpp contains parsers for link headers, which are
>>>> related.  Yoav knows more about those.  Those parsers ought to be united
>>>> more.
>>>> >>>
>>>> >>>> On Feb 3, 2017, at 1:17 AM, Atul Sowani <sowani at gmail.com> wrote:
>>>> >>>> At present I am focusing on CSSParser::findURI() particularly
>>>> and CSSParser::realLex() other related functionality in CSSParser.cpp
>>>> - hope I am on right track. ;-)
>>>> >>>>
>>>> >>>> Please let me know if I should be looking at some other
>>>> functionality as well to resolve this issue.
>>>> >>>>
>>>> >>>> Thanks!
>>>> >>>> Atul.
>>>> >>>>
>>>> >>>> On Fri, Feb 3, 2017 at 2:33 PM, Atul Sowani <sowani at gmail.com>
>>>> wrote:
>>>> >>>>> Hi,
>>>> >>>>>
>>>> >>>>> I came across an issue in qtwebkit CSS parser while working on a
>>>> PhantomJS crash. The issue seems to be with parsing of <link rel="..."
>>>> href="..."> type elements in an HTML page. What I observed is that the
>>>> parser is trying to interpret the value for href given inside
>>>> double-quotes. The value contains a "-" (e.g. "
>>>> http://some.domain.com/some-page-etc-etc"). The "-" sign is being
>>>> interpreted as minus and then things go wrong. In another case I found that
>>>> "\g" embedded in the value (e.g. "http://some.domain.com/some-p
>>>> age/global/something") is also creating issues. In essence, the parser
>>>> is trying to interpret the value, which I believe, it should not.
>>>> >>>>>
>>>> >>>>> I am willing to dive further into it to debug and fix the issue,
>>>> but looking at the complexity and size of WebCore, I think I would benefit
>>>> a lot to expedite a fix, if I could get some tips about which code
>>>> area/functionality I should specifically focus in the WebCore. Looking
>>>> forward to some help in this regard.
>>>> >>>>>
>>>> >>>>> Thanks,
>>>> >>>>> Atul.
>>>> >>>> _______________________________________________
>>>> >>>> webkit-dev mailing list
>>>> >>>> webkit-dev at lists.webkit.org
>>>> >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>> > ,
>>>> >
>>>> > _______________________________________________
>>>> > webkit-dev mailing list
>>>> > webkit-dev at lists.webkit.org
>>>> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Konstantin
>>>>
>>>
>>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20170213/3c6d0430/attachment.html>