headers
Yuzo Fujishima | 1 Mar 2010 11:51
Picon
Favicon

Reviewers Wanted: CSS3 Paged Media

Hi, webkit-dev (especially, reviewers),

Shinichiro, Hayato, Peter, and I (all CC'ed) have started implementing
CSS3 Paged Media (http://dev.w3.org/csswg/css3-page/).

https://bugs.webkit.org/show_bug.cgi?id=15548
https://bugs.webkit.org/show_bug.cgi?id=35329

Reviewers,
We'd appreciate it if one of you are interested in reviewing patches for
CSS3 Paged Media. Anyone, please?

Yuzo
Permalink | Reply | 1 comment |
headers
Shinichiro Hamaji | 1 Mar 2010 12:56

Re: Reviewers Wanted: CSS3 Paged Media

Note that we will review each other so it will make the main review a
bit easier (hopefully!). I can also r+ easy patches but I'm not
confident to review patches which touch deep WebCore stuff yet.

On Mon, Mar 1, 2010 at 7:51 PM, Yuzo Fujishima <yuzo <at> google.com> wrote:
> Hi, webkit-dev (especially, reviewers),
>
> Shinichiro, Hayato, Peter, and I (all CC'ed) have started implementing
> CSS3 Paged Media (http://dev.w3.org/csswg/css3-page/).
>
> https://bugs.webkit.org/show_bug.cgi?id=15548
> https://bugs.webkit.org/show_bug.cgi?id=35329
>
> Reviewers,
> We'd appreciate it if one of you are interested in reviewing patches for
> CSS3 Paged Media. Anyone, please?
>
> Yuzo
>
Permalink | Reply | 0 comments |
headers
Darin Adler | 1 Mar 2010 22:42
Picon
Favicon

Re: WebView & mouseMoved events

On Feb 28, 2010, at 9:16 AM, Alex MacCaw wrote:

> It looks like Apple aren't using the normal mouseMoved events, but rather send them through a NSNotificationCenter.

In, AppKit, mouse moved events are sent to the first responder and passed the responder chain. But WebKit
needs them even for views that are not in the responder chain. That’s why WebKit responds to mouse moved
notifications instead.

> I don't know where they're created, but I assume it''s something to do with
'WKSetNSWindowShouldPostEventNotifications'. Since that part of the project is closed, I can't see
the source to find out why they're not being created.

That function calls a private NSWindow method to tell NSWindow to post notifications for mouse events.
It’s just a single method call.

> Anyone know why mouse moved events wouldn't be created?

I think you should reduce your program to a simple test case that shows the mouse move events not being
handled. Mouse moved events do work in simple browsers made with WebKit as well as in Safari, so there must
be something different about your program.

    -- Darin
Permalink | Reply | 0 comments |
headers
baizhenxuan | 2 Mar 2010 02:45
Picon

rangeParent and rangeOffset of mouseEvent in Javascript

Hi,
 
i want to write a extension to get the word under mouse through javascript.
in firefox, mouseEvent has property rangeParent and rangeOffset that 
help me to get the word under the mouse, but in webkit, i can only find 
which node under the mouse ,cannot find any position information inside 
the text node. for example, in the following html, i can only find the 
mouse stay on a HTMLDivElement and it's content is " Ap The ...", what i 
want is which word the mouse stay on.
<div>
AP The measure cleared a key hurdle on Monday when the Senate's newest 
Republican
</div>
why webkit doesn't provide these apis?
    thanks
    baizhenxuan
 
 
2010-03-02
baizhenxuan
发件人： webkit-dev-request
发送时间： 2010-03-01  23:00:13
收件人： webkit-dev
抄送：
主题： webkit-dev Digest, Vol 58, Issue 1
Send webkit-dev mailing list submissions to
webkit-dev <at> lists.webkit.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
or, via email, send a message with subject or body 'help' to
webkit-dev-request <at> lists.webkit.org
You can reach the person managing the list at
webkit-dev-owner <at> lists.webkit.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of webkit-dev digest..."
Today's Topics:
   1. WebView & mouseMoved events (Alex MacCaw)
   2. Reviewers Wanted: CSS3 Paged Media (Yuzo Fujishima)
   3. Re: Reviewers Wanted: CSS3 Paged Media (Shinichiro Hamaji)
----------------------------------------------------------------------
Message: 1
Date: Sun, 28 Feb 2010 17:16:04 +0000
From: Alex MacCaw <maccman <at> gmail.com>
To: webkit-dev <at> lists.webkit.org
Subject: [webkit-dev] WebView & mouseMoved events
Message-ID: <22FBD4B3-5798-49A5-B1E9-7E0CA9024066 <at> gmail.com>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I'm having trouble with mouse moved events with Apple WebKit port.
They're just not firing - and so I don't get any :hover css effects or js events.
It looks like Apple aren't using the normal mouseMoved events, but rather send them through a NSNotificationCenter.
I don't know where they're created, but I assume it''s something to do with 'WKSetNSWindowShouldPostEventNotifications'.
Since that part of the project is closed, I can't see the source to find out why they're not being created. 
At the moment, I'm getting round the issue by firing them myself:
http://github.com/maccman/bowline-desktop/commit/e4aa611373a2c76455566ff0dcf178a775b49756
Anyone know why mouse moved events wouldn't be created? I'd much rather do this the proper way, rather then hack round it.
Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100228/922fce99/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 1 Mar 2010 19:51:24 +0900
From: Yuzo Fujishima <yuzo <at> google.com>
To: WebKit Development <webkit-dev <at> lists.webkit.org>
Cc: "Linss, Peter" <peter.linss <at> hp.com>, hayato <at> chromium.org
Subject: [webkit-dev] Reviewers Wanted: CSS3 Paged Media
Message-ID:
<9124e09b1003010251k196245f6p9c5bf58a2dd454bd <at> mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Hi, webkit-dev (especially, reviewers),
Shinichiro, Hayato, Peter, and I (all CC'ed) have started implementing
CSS3 Paged Media (http://dev.w3.org/csswg/css3-page/).
https://bugs.webkit.org/show_bug.cgi?id=15548
https://bugs.webkit.org/show_bug.cgi?id=35329
Reviewers,
We'd appreciate it if one of you are interested in reviewing patches for
CSS3 Paged Media. Anyone, please?
Yuzo
------------------------------
Message: 3
Date: Mon, 1 Mar 2010 20:56:29 +0900
From: Shinichiro Hamaji <hamaji <at> chromium.org>
To: Yuzo Fujishima <yuzo <at> google.com>
Cc: "Linss, Peter" <peter.linss <at> hp.com>, hayato <at> chromium.org, WebKit
Development <webkit-dev <at> lists.webkit.org>
Subject: Re: [webkit-dev] Reviewers Wanted: CSS3 Paged Media
Message-ID:
<dc751ec01003010356x6c4625ax7a9575b2afc5bcd9 <at> mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Note that we will review each other so it will make the main review a
bit easier (hopefully!). I can also r+ easy patches but I'm not
confident to review patches which touch deep WebCore stuff yet.
On Mon, Mar 1, 2010 at 7:51 PM, Yuzo Fujishima <yuzo <at> google.com> wrote:
> Hi, webkit-dev (especially, reviewers),
>
> Shinichiro, Hayato, Peter, and I (all CC'ed) have started implementing
> CSS3 Paged Media (http://dev.w3.org/csswg/css3-page/).
>
> https://bugs.webkit.org/show_bug.cgi?id=15548
> https://bugs.webkit.org/show_bug.cgi?id=35329
>
> Reviewers,
> We'd appreciate it if one of you are interested in reviewing patches for
> CSS3 Paged Media. Anyone, please?
>
> Yuzo
>
------------------------------
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
End of webkit-dev Digest, Vol 58, Issue 1
*****************************************
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Permalink | Reply | 1 comment |
headers
Ojan Vafai | 2 Mar 2010 02:49

Re: Increasing the number of cross-platform/port expected results

On Tue, Feb 23, 2010 at 3:26 PM, Eric Seidel <eric <at> webkit.org> wrote:
On Tue, Feb 23, 2010 at 2:19 PM, Darin Adler <darin <at> apple.com> wrote:
> But in practice pixel results are often ignored entirely. I think that reftest-style tests if done right could be a great addition.

Also, there are zillions of render-tree-dump tests which could easily
be converted to plain-text tests.  No one has yet written a tool to
visualize how many tests we have with platform-specific results, but I
would expect many of those platform-specific results could be removed
by converting more existing tests to dump as text.

The vast majority of plain-text tests don't end up needing platform-specific results. Also, they run faster.

In the past there was some resistance to converting older tests to dumpAsText out of fear of losing test coverage. Could we instead try to make it so that the default is dumpAsText? That would go a long way in making new tests be dumpAsText. The difficulty there, of course, is actually doing it since there are so many tests that would need to be modified (i.e. current render dump tests would need something like a dumpRenderTree() call).

Implementation difficulties aside, does that sound like a good idea?

Ojan
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Permalink | Reply | 8 comments |
headers
Maciej Stachowiak | 2 Mar 2010 03:40
Picon
Favicon

Re: Increasing the number of cross-platform/port expected results


On Mar 1, 2010, at 5:49 PM, Ojan Vafai wrote:

On Tue, Feb 23, 2010 at 3:26 PM, Eric Seidel <eric <at> webkit.org> wrote:
On Tue, Feb 23, 2010 at 2:19 PM, Darin Adler <darin <at> apple.com> wrote:
> But in practice pixel results are often ignored entirely. I think that reftest-style tests if done right could be a great addition.

Also, there are zillions of render-tree-dump tests which could easily
be converted to plain-text tests.  No one has yet written a tool to
visualize how many tests we have with platform-specific results, but I
would expect many of those platform-specific results could be removed
by converting more existing tests to dump as text.

The vast majority of plain-text tests don't end up needing platform-specific results. Also, they run faster.

In the past there was some resistance to converting older tests to dumpAsText out of fear of losing test coverage. Could we instead try to make it so that the default is dumpAsText? That would go a long way in making new tests be dumpAsText. The difficulty there, of course, is actually doing it since there are so many tests that would need to be modified (i.e. current render dump tests would need something like a dumpRenderTree() call).

Implementation difficulties aside, does that sound like a good idea?

On the one hand, it's good to shift the default. On the other hand, many render tree dumping tests do not currently need to run any JavaScript script, while many text-only tests do. I would almost suggest having a per-directory default but that might be too confusing and mysterious.

Question: are text-only tests really faster, in non-pixel mode? I would be surprised if there was a significant different, and it may point to something we can optimize.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Permalink | Reply | 7 comments |
headers
Ojan Vafai | 2 Mar 2010 03:46

Re: Increasing the number of cross-platform/port expected results

On Mon, Mar 1, 2010 at 6:40 PM, Maciej Stachowiak <mjs <at> apple.com> wrote:
On Mar 1, 2010, at 5:49 PM, Ojan Vafai wrote:
On Tue, Feb 23, 2010 at 3:26 PM, Eric Seidel <eric <at> webkit.org> wrote:
On Tue, Feb 23, 2010 at 2:19 PM, Darin Adler <darin <at> apple.com> wrote:
> But in practice pixel results are often ignored entirely. I think that reftest-style tests if done right could be a great addition.

Also, there are zillions of render-tree-dump tests which could easily
be converted to plain-text tests.  No one has yet written a tool to
visualize how many tests we have with platform-specific results, but I
would expect many of those platform-specific results could be removed
by converting more existing tests to dump as text.

The vast majority of plain-text tests don't end up needing platform-specific results. Also, they run faster.

In the past there was some resistance to converting older tests to dumpAsText out of fear of losing test coverage. Could we instead try to make it so that the default is dumpAsText? That would go a long way in making new tests be dumpAsText. The difficulty there, of course, is actually doing it since there are so many tests that would need to be modified (i.e. current render dump tests would need something like a dumpRenderTree() call).

Implementation difficulties aside, does that sound like a good idea?
On the one hand, it's good to shift the default. On the other hand, many render tree dumping tests do not currently need to run any JavaScript script, while many text-only tests do. I would almost suggest having a per-directory default but that might be too confusing and mysterious.

Yeah, I thought about having per-directory defaults too. There are some nice things about that. For example, the editing tests mostly want something in between dumpAsText and a render dump. It would be great if we could default those to dumpAsMarkup (https://bugs.webkit.org/show_bug.cgi?id=26501).

But, I agree, it's probably too confusing.
 
Question: are text-only tests really faster, in non-pixel mode? I would be surprised if there was a significant different, and it may point to something we can optimize.

I just meant that they are faster assuming you're running pixel tests. Ideally we'd head in the direction of running pixel tests by default one day. :)

Ojan
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Permalink | Reply | 6 comments |
headers
Maciej Stachowiak | 2 Mar 2010 03:53
Picon
Favicon

Re: Increasing the number of cross-platform/port expected results


On Mar 1, 2010, at 6:46 PM, Ojan Vafai wrote:

On Mon, Mar 1, 2010 at 6:40 PM, Maciej Stachowiak <mjs <at> apple.com> wrote:
On the one hand, it's good to shift the default. On the other hand, many render tree dumping tests do not currently need to run any JavaScript script, while many text-only tests do. I would almost suggest having a per-directory default but that might be too confusing and mysterious.

Yeah, I thought about having per-directory defaults too. There are some nice things about that. For example, the editing tests mostly want something in between dumpAsText and a render dump. It would be great if we could default those to dumpAsMarkup (https://bugs.webkit.org/show_bug.cgi?id=26501).

<3 dumpAsMarkup


But, I agree, it's probably too confusing.
 
Question: are text-only tests really faster, in non-pixel mode? I would be surprised if there was a significant different, and it may point to something we can optimize.

I just meant that they are faster assuming you're running pixel tests. Ideally we'd head in the direction of running pixel tests by default one day. :)

Good point. If we always ran the pixel tests, then perhaps we should consider having some tests that dump the render tree but are not subject to pixel testing. I do think the platform-independence issue is a good reason to be strongly biased towards making new tests dump as text (or dump as markup, once that is added). Even if we do not change the default, we should recommend it as a good practice and reviewers should be on the lookout for this issue when reviewing patches.

Cheers,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Permalink | Reply | 5 comments |
headers
Darin Adler | 3 Mar 2010 00:05
Picon
Favicon

Re: rangeParent and rangeOffset of mouseEvent in Javascript

This mailing list is for discussion of the development of WebKit, not help using WebKit. Please see
<http://webkit.org/contact.html>. Your question is more appropriate for webkit-help.

On Mar 1, 2010, at 5:45 PM, baizhenxuan wrote:

> in firefox, mouseEvent has property rangeParent and rangeOffset that help me to get the word under the mouse

> why webkit doesn't provide these apis?

As far as I know, these properties are Firefox-specific, not mentioned in any standard. WebKit doesn’t
have all the same extensions to the DOM API that Firefox does. These seem like they might be reasonable
things to add. You could file a bug requesting them or even work on the implementation yourself. The
documentation at <http://webkit.org/quality/reporting.html> tells how to write a bug report.

Folks on webkit-help might be able to help you find a workaround. WebKit does have at least some APIs that
might be useful to you in this situation.

    -- Darin
Permalink | Reply | 0 comments |
headers
Jeremy Moskovich | 3 Mar 2010 07:13

Re: Google Summer Of Code 2010

The deadline for applying for GSoC is a little over a week away now (March 12th).

If you are interested in mentoring or would like to propose a project, please write those up on the wiki page.

Best regards,
Jeremy

On Wed, Feb 24, 2010 at 1:23 AM, Jeremy Moskovich <jeremy <at> chromium.org> wrote:
WebKit participated in GSoC 2 years ago, I was wondering whether there was interest in doing so again this year?

I've started a wiki page to collect ideas and potential mentors for this year: https://trac.webkit.org/wiki/Google%20Summer%20of%20Code%202010

The deadline for registering a mentoring organization is March 12th, so we need to decide by then where we stand.

Copious apologies if I'm getting this wrong, but from what I understand - apart from one outstanding contributor, the WebKit community didn't have a very positive experience last time around.

Perhaps if we try taking a more conservative approach this year. Both in terms of our criteria for accepting students and picking projects closer to the current core functionality of WebKit [rather than implementing totally new specs], that we might have a better experience.

Best regards,
Jeremy



_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Permalink | Reply | 0 comments |

Gmane