[webkit-dev] Making Webkit - CSSGrammar.h

2011-06-21 Thread Tom Smith 
Hello,

I'm trying to build Webkit on Ubuntu, but I get this error when I try to
make it:

WebCore/css/CSSParser.cpp:4152: fatal error: CSSGrammar.h: No such file or
directory
compilation terminated.
make[1]: *** [WebCore/css/libWebCore_la-CSSParser.lo] Error 1
make[1]: Leaving directory `/home/screamer/Canmore/usr/src/WebKit-r36247'
make: *** [all] Error 2

I tried looking for the CSSGrammar.h file in /WebCore/css but I it's simply
not there. Can anyone help?


Best regards,
Tom
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Making Webkit - CSSGrammar.h

2011-06-21 Thread İsmail Dönmez 
Hi;

On Tue, Jun 21, 2011 at 3:44 PM, Tom Smith  wrote:

> Hello,
>
> I'm trying to build Webkit on Ubuntu, but I get this error when I try to
> make it:
>
> WebCore/css/CSSParser.cpp:4152: fatal error: CSSGrammar.h: No such file or
> directory
> compilation terminated.
> make[1]: *** [WebCore/css/libWebCore_la-CSSParser.lo] Error 1
> make[1]: Leaving directory `/home/screamer/Canmore/usr/src/WebKit-r36247'
> make: *** [all] Error 2
>
> I tried looking for the CSSGrammar.h file in /WebCore/css but I it's simply
> not there. Can anyone help?
>

 That file automatically generated from CSSGrammar.y file, I am guessing you
are missing bison/yacc package installed.

Regards,
ismail
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] MathML Anonymous Block Conundrum

2011-06-21 Thread Alex Milowski 
I've run into a conundrum with "anonymous blocks" yet again.  I was
helping track down a crash relating to DOM manipulation.  While I
fixed that particular case by just marking all the instances as
anonymous blocks, this solution doesn't work in general.

In many places in the MathML rendering code we create
RenderMathMLBlock instances that are used to layout different
constructs.  For example, for fractions we stack two RenderMathMLBlock
instances as wrappers for the numerator and denominator.  In many
instances, that is all we need to do.  In other instances, such as
fractions, we set style properties on each created instance.

Here's the problem:

If the created wrappers are marked as anonymous, the style created for
the wrapper is ignored due to this bit from the CSS 2.1
recommendation:

"The properties of anonymous boxes are inherited from the enclosing
non-anonymous box (e.g., in the example just below the subsection
heading "Anonymous block boxes", the one for DIV). Non-inherited
properties have their initial value. For example, the font of the
anonymous box is inherited from the DIV, but the margins will be 0."
[1]

If we don't mark them as anonymous, we can get a crash related to
Javascript DOM manipulation at RenderBlock.cpp:680:

   ASSERT(anonymousChild->isAnonymous());

where it is searching for the anonymous wrapper that doesn't exist.
In fact, I believe the problem is that the beforeChild parameter is
the rendering object that has been wrapped and not the wrapper.  As
such, beforeChild is "wrong" and by adding something like:

if (beforeChild && !beforeChild->isRenderMathMLBlock())
beforeChild = beforeChild->parent();

I can fix that before I use it to add the wrapper.  I would have to do
this in all places where I know that I have wrappers with styles and
where I could actually guarantee what I'm doing.  In the case of
fractions, over/under, and a few others, this may work fine.

This doesn't feel like a good general solution.

Also, if I wrap an added child and code elsewhere assumes that the
parent/child relationship is the same as in the DOM, then I've broken
their assumption.  I see this same kind of behavior with table
sections in the RenderTable object and I wonder why beforeChild isn't
a problem there.

I fail to understand why I need to mark things as anonymous as they
aren't anonymous in the same sense of CSS.  This is a layout construct
needed to display the Mathematics.  I need to create these rendering
objects that do not correspond directly to a element in the way as
most others do.

I think I'm beginning to appreciate some of what Dave Hyatt was
hinting at to me that I may need my own line layout algorithm but I
still really don't want to go there.  That is, layout of a fraction
doesn't feel like line layout to me.


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Making Webkit - PluginViewGtk.cpp error

2011-06-21 Thread Tom Smith 
Hello,

I'm trying to install Webkit on Ubuntu, but I get the following error:

WebCore/plugins/gtk/PluginViewGtk.cpp: In member function ‘void
WebCore::PluginView::init()’:
WebCore/plugins/gtk/PluginViewGtk.cpp:552: error:
‘NPSetWindowCallbackStruct’ was not declared in this scope
WebCore/plugins/gtk/PluginViewGtk.cpp:552: error: ‘ws’ was not declared in
this scope
WebCore/plugins/gtk/PluginViewGtk.cpp:552: error: expected type-specifier
before ‘NPSetWindowCallbackStruct’
WebCore/plugins/gtk/PluginViewGtk.cpp:552: error: expected ‘;’ before
‘NPSetWindowCallbackStruct’
WebCore/plugins/gtk/PluginViewGtk.cpp:572: error: ‘struct NPWindow’ has no
member named ‘ws_info’
make[1]: *** [WebCore/plugins/gtk/libWebCore_la-PluginViewGtk.lo] Error 1
make[1]: Leaving directory `/home/screamer/Canmore/usr/src/WebKit-r36247'
make: *** [all] Error 2


I tried looking at the PluginViewGtk.cpp file, but I'm not sure how to fix
this. Can anyone help?


Best regards,
Tom
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Making Webkit - PluginViewGtk.cpp error

2011-06-21 Thread Ariya Hidayat 
You post too many build errors lately. Care to tell us what exactly
did you run? How did you invoke the 'build-webkit' script?



-- 
Ariya Hidayat
http://www.linkedin.com/in/ariyahidayat
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Making Webkit - PluginViewGtk.cpp error

2011-06-21 Thread Tom Smith 
Hello,

I used the command: ./autogen.sh --prefix=${BUILD_DEST} to setup and
configure webkit, which compiled fine. But I get errors when I try to make
it. I'm running Ubuntu 10.10 with
WebKit-r36247.


Best regards,
Tom
On Tue, Jun 21, 2011 at 12:32 PM, Ariya Hidayat wrote:

> You post too many build errors lately. Care to tell us what exactly
> did you run? How did you invoke the 'build-webkit' script?
>
>
>
> --
> Ariya Hidayat
> http://www.linkedin.com/in/ariyahidayat
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] DumpRenderTree for the EFL port :)

2011-06-21 Thread Raphael Kubo da Costa 
Leandro Pereira  writes:

> At last, the EFL port of WebKit got a DumpRenderTree implementation!
> We're still working on ironing out a lot of bugs found by some of the
> LayoutTests, but the DRT (and ImageDiff) code has been submitted to
> Bugzilla. It would be awesome if anyone could help reviewing these
> patches.

Thanks to eseidel, a few of our patchas have already made their way
upstream.

Unfortunately, he needs to take a break from too much exposure to
C-style code, so we need someone else to review our remaining
patches :-)

The remaining DRT patches are:

https://bugs.webkit.org/show_bug.cgi?id=61962
https://bugs.webkit.org/show_bug.cgi?id=61974
https://bugs.webkit.org/show_bug.cgi?id=63086
https://bugs.webkit.org/show_bug.cgi?id=61974

-- 
Raphael Kubo da Costa
ProFUSION embedded systems
http://profusion.mobi

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Accessibility Object Searching

2011-06-21 Thread Samuel White 
Hey everybody,

I'm new to the list and thought it would be a good idea to get some feedback on 
an accessibility feature before filing a bug or submitting anything. Currently, 
no functionality exists in WebKit to search through AccessibilityObjects using 
basic search criteria like next link or next table internally. Screen readers 
and other access devices often must instead probe WebKit and build up their own 
internal representation of a page before they can begin searching for what they 
are after. This presents two big problems for the users of access technology. 
First, pages such as the HTML 5 working doc have a massive number of DOM 
elements and building up an external representation can be a very expensive and 
slow task. Secondly, maintaining an accurate external representation of a site 
can become difficult if that site has a large amount of dynamic content and 
users may not be accessing relevant information.

I would like to make a few small changes to the AccessibilityObject class that 
adds the functionality I've mentioned. I think these small but important 
additions will allow existing access technologies to rely much more on WebKits 
representation of a page and thus eliminate the problems I've described above. 
I appreciate any feedback and look forward to helping out.

Thanks
Sam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Accessibility Object Searching

2011-06-21 Thread Charles Pritchard 
On Jun 21, 2011, at 4:30 PM, Samuel White  wrote:

> Hey everybody,
> 
> I'm new to the list and thought it would be a good idea to get some feedback 
> on an accessibility feature before filing a bug or submitting anything. 
> Currently, no functionality exists in WebKit to search through 
> AccessibilityObjects using basic search criteria like next link or next table 
> internally. Screen readers and other access devices often must instead probe 
> WebKit and build up their own internal representation of a page before they 
> can begin searching for what they are after. This presents two big problems 
> for the users of access technology. First, pages such as the HTML 5 working 
> doc have a massive number of DOM elements and building up an external 
> representation can be a very expensive and slow task. Secondly, maintaining 
> an accurate external representation of a site can become difficult if that 
> site has a large amount of dynamic content and users may not be accessing 
> relevant information.
> 
> I would like to make a few small changes to the AccessibilityObject class 
> that adds the functionality I've mentioned. I think these small but important 
> additions will allow existing access technologies to rely much more on 
> WebKits representation of a page and thus eliminate the problems I've 
> described above. I appreciate any feedback and look forward to helping out.
> 
> Thanks
> Sam

While you're rooting around in there, I'd love to see the tree exposed to 
WebKit inspector at some point. It might make ARIA a little easier to use.

I'm still months away from being a contributor-- I'm hoping to see the canvas 
shadow DOM made accessible, and subsequently, see paths supported by assistive 
technology, like Apple's gesture-based eyes-free mode in Mobile Safari/iOS.

-Charles
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Accessibility Object Searching

2011-06-21 Thread Chris Fleizach 

Searching for elements on a webpage is one of the important functions for a 
screen reader, so this has the potential for vastly improving screen reader 
access on the web.

What's nice about this approach is that it will allow other platforms to also 
take advantage. It should significantly reduce memory usage, number of IPC 
calls and overall runtime whenever searching is done.

On Jun 21, 2011, at 4:30 PM, Samuel White wrote:

> Hey everybody,
> 
> I'm new to the list and thought it would be a good idea to get some feedback 
> on an accessibility feature before filing a bug or submitting anything. 
> Currently, no functionality exists in WebKit to search through 
> AccessibilityObjects using basic search criteria like next link or next table 
> internally. Screen readers and other access devices often must instead probe 
> WebKit and build up their own internal representation of a page before they 
> can begin searching for what they are after. This presents two big problems 
> for the users of access technology. First, pages such as the HTML 5 working 
> doc have a massive number of DOM elements and building up an external 
> representation can be a very expensive and slow task. Secondly, maintaining 
> an accurate external representation of a site can become difficult if that 
> site has a large amount of dynamic content and users may not be accessing 
> relevant information.
> 
> I would like to make a few small changes to the AccessibilityObject class 
> that adds the functionality I've mentioned. I think these small but important 
> additions will allow existing access technologies to rely much more on 
> WebKits representation of a page and thus eliminate the problems I've 
> described above. I appreciate any feedback and look forward to helping out.
> 
> Thanks
> Sam
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Accessibility Object Searching

2011-06-21 Thread Chris Fleizach 

On Jun 21, 2011, at 5:45 PM, Charles Pritchard wrote:

> On Jun 21, 2011, at 4:30 PM, Samuel White  wrote:
> 
>> Hey everybody,
>> 
>> I'm new to the list and thought it would be a good idea to get some feedback 
>> on an accessibility feature before filing a bug or submitting anything. 
>> Currently, no functionality exists in WebKit to search through 
>> AccessibilityObjects using basic search criteria like next link or next 
>> table internally. Screen readers and other access devices often must instead 
>> probe WebKit and build up their own internal representation of a page before 
>> they can begin searching for what they are after. This presents two big 
>> problems for the users of access technology. First, pages such as the HTML 5 
>> working doc have a massive number of DOM elements and building up an 
>> external representation can be a very expensive and slow task. Secondly, 
>> maintaining an accurate external representation of a site can become 
>> difficult if that site has a large amount of dynamic content and users may 
>> not be accessing relevant information.
>> 
>> I would like to make a few small changes to the AccessibilityObject class 
>> that adds the functionality I've mentioned. I think these small but 
>> important additions will allow existing access technologies to rely much 
>> more on WebKits representation of a page and thus eliminate the problems 
>> I've described above. I appreciate any feedback and look forward to helping 
>> out.
>> 
>> Thanks
>> Sam
> 
> While you're rooting around in there, I'd love to see the tree exposed to 
> WebKit inspector at some point. It might make ARIA a little easier to use.
> 

The accessibility hierarchy is usually coupled (tightly at times) to the 
platform's implementation. Often there are tools on the platform to help figure 
out the accessibility hierarchy. 

On the Mac, there's "Accessibility Inspector", which conveniently can also be 
run on the iOS simulator. Just start the program and hover the mouse over an 
item on a webpage to learn how it's exposed to the platform.

> I'm still months away from being a contributor-- I'm hoping to see the canvas 
> shadow DOM made accessible, and subsequently, see paths supported by 
> assistive technology, like Apple's gesture-based eyes-free mode in Mobile 
> Safari/iOS.
> 
> -Charles
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Spellcheck API for WebKit

2011-06-21 Thread Simon Fraser 
On May 31, 2011, at 3:38 AM, Hironori Bono (坊野 博典) wrote:

> Greetings WebKit developers,
> 
> These days, we have talked about adding Spellcheck API in the
> public-webapps ML:
> .
> This API currently consists of two functions (addSpellcheckRange and
> removeSpellcheckRange) and an attribute (spellcheckRanges) to editable
> elements of HTML so web-application developers (and extension
> developers) can implement custom spellcheckers. Also, I have uploaded
> a reference implementation of this API to .
> Even though this change enables this SpellcheckAPI only on Chromium,
> it would be definitely helpful to give me your feedback not only for
> this Spellcheck API and also for my WebKit change.
> Thank you for your help in advance.

This new API got turn on inadvertently on Mac just now, and a few of us spent
a wasted hour trying to get things to build. In this light, my comments on the 
API
may not be as favorable as they would otherwise be.

First, why is the API on HTMLDivElement?

Second, since this exposes to the web API in a non-final spec, the new methods
should be prefixed with 'webkit' to avoid potential conflict if the API changes 
later.

Simon

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Spellcheck API for WebKit

2011-06-21 Thread 坊野 博典 
Greetings Simon,

Apologies for my stupid change in advance.
My change just tried to straightforwardly implement a suggestion

without deep consideration about WebKit manners noted by your e-mail.

On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser  wrote:
> This new API got turn on inadvertently on Mac just now, and a few of us spent
> a wasted hour trying to get things to build. In this light, my comments on 
> the API
> may not be as favorable as they would otherwise be.
>
> First, why is the API on HTMLDivElement?

Unfortunately, I have just copied and pasted my code in
HTMLTextAreaElement to support contenteditable elements and designMode
ones because I did not have better ideas at that time. I should have
asked about it in this ML before landing this change.

> Second, since this exposes to the web API in a non-final spec, the new methods
> should be prefixed with 'webkit' to avoid potential conflict if the API 
> changes later.

This is totally my fault. (The sin of ignorance.) Sorry again for that.

By the way, I wonder how I should treat my r88332 even though I
understand this change was wrong. Even though there are several
options: 1. re-design the API, 2. revert my r88332 and re-implement
it, 3. send changes that apply these comments, etc. Would it be
possible to give me your advice?

Regards,

Hironori Bono
E-mail: hb...@chromium.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Spellcheck API for WebKit

2011-06-21 Thread Ryosuke Niwa 
2011/6/21 Hironori Bono (坊野 博典) 
>
>  On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser 
> wrote:
> > This new API got turn on inadvertently on Mac just now, and a few of us
> spent
> > a wasted hour trying to get things to build. In this light, my comments
> on the API
> > may not be as favorable as they would otherwise be.
> >
> > First, why is the API on HTMLDivElement?
>
> Unfortunately, I have just copied and pasted my code in
> HTMLTextAreaElement to support contenteditable elements and designMode
> ones because I did not have better ideas at that time. I should have
> asked about it in this ML before landing this change.
>

contenteditable attribute can appear in any element so I don't think we
should restrict it to div.

 > Second, since this exposes to the web API in a non-final spec, the new
> methods
> > should be prefixed with 'webkit' to avoid potential conflict if the API
> changes later.
>
> This is totally my fault. (The sin of ignorance.) Sorry again for that.
>
> By the way, I wonder how I should treat my r88332 even though I
> understand this change was wrong. Even though there are several
> options: 1. re-design the API, 2. revert my r88332 and re-implement
> it, 3. send changes that apply these comments, etc. Would it be
> possible to give me your advice?
>

Given that the original patch seems to have various issues and we're going
to make a lot of changes (i.e. move it to HTMLElement and prefix it with
webkit or chrome), option 2 seems most suitable approach here.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev