Re: [webkit-dev] EFL port?

[Gyuyoung Kim]

Hello,

To be honest, very few people have worked for EFL port recently. In my case
it was hard to maintain EFL port because of internal work.
However I have a plan to improve EFL port after I finish the work. Even I
opened a website for EWebKit. http://www.ewebkit.org.
Besides I released EWebKit 1.18 version[1] for EFL 1.18 official release.
Could you give me more time for EFL port ?

Gyuyoung.


[1] EWebKit 1.18 release announcement.

https://phab.enlightenment.org/w/efl_and_elementary_1_18_release_announcement/
EWebkit

Together with this release we are happy to announce that the EWebkit team
is doing a
release  with
their work matching the efl 1.18.
It contains various webkit core as well as EWebkit specific enhancements.
See the
NEWS file  for
details and the http://www.ewebkit.org page for further instructions on
building. We hope to keep future releases of EWebkit aligned with the EFL
release schedule.






On Fri, Feb 10, 2017 at 9:42 AM, Anders Carlsson  wrote:

> Hello,
>
> Looks like the EFL port isn’t really being worked on anymore. Is this
> true? Can we rip it out?
>
> - Anders
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] EFL port?

[Anders Carlsson]

Hello,

Looks like the EFL port isn’t really being worked on anymore. Is this true? Can 
we rip it out?

- Anders
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] CSS Parse error in element.

[Simon Fraser]

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  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::create(WTF::PassRefPtr,
>  WTF::PassRefPtr, 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  > 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  > wrote:
> 
> 
> 07.02.2017, 12:55, "Atul Sowani" >:
> > 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  > > 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  >> > 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   > 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 

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

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::create(WTF::PassRefPtr,
WTF::PassRefPtr, 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  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 
> wrote:
>
>>
>>
>> 07.02.2017, 12:55, "Atul Sowani" :
>> > 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  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 <
>> achristen...@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  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 
>> 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 > 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. "
>> 

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

@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 
wrote:

>
>
> 07.02.2017, 12:55, "Atul Sowani" :
> > 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  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 
> 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  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  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  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-
> page/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@lists.webkit.org
>  https://lists.webkit.org/mailman/listinfo/webkit-dev
> > ,
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> --
> Regards,
> Konstantin
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev