Re: [webkit-dev] Question about Constructors in WebKit JS Bindings

[Maciej Stachowiak]

On Jul 2, 2009, at 10:12 PM, Drew Wilson wrote:

I had another question - I'm looking at JSWorkerConstructor code,  
but this pattern exists elsewhere as well:


JSWorkerConstructor::JSWorkerConstructor(ExecState* exec)
: DOMObject(JSWorkerConstructor::createStructure(exec- 
>lexicalGlobalObject()->objectPrototype()))

{
putDirect(exec->propertyNames().prototype,  
JSWorkerPrototype::self(exec, exec->lexicalGlobalObject()), None);
putDirect(exec->propertyNames().length, jsNumber(exec, 1),  
ReadOnly|DontDelete|DontEnum);

}

What is the purpose of the second putDirect() call? I don't see this  
in other constructors like JSXMLHttpRequestConstructor, but I do see  
it in things like JSOptionConstructor and JSAudioConstructor.


At first I thought it was just some kind of copy/paste error, but  
now I'm not so sure given how many files it's found in.


In theory, JavaScript host functions are supposed to have a "length"  
property that gives the expected number of arguments. Web IDL might  
specify what it's supposed to be. The fact that we are inconsistent is  
likely because this is very very unimportant to actual Web  
compatibility.


 - Maciej

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

Re: [webkit-dev] Question about Constructors in WebKit JS Bindings

[Drew Wilson]

I had another question - I'm looking at JSWorkerConstructor code, but this
pattern exists elsewhere as well:
JSWorkerConstructor::JSWorkerConstructor(ExecState* exec)
:
DOMObject(JSWorkerConstructor::createStructure(exec->lexicalGlobalObject()->objectPrototype()))
{
putDirect(exec->propertyNames().prototype, JSWorkerPrototype::self(exec,
exec->lexicalGlobalObject()), None);
*putDirect(exec->propertyNames().length, jsNumber(exec, 1),
ReadOnly|DontDelete|DontEnum);*
}

What is the purpose of the second putDirect() call? I don't see this in
other constructors like JSXMLHttpRequestConstructor, but I do see it in
things like JSOptionConstructor and JSAudioConstructor.

At first I thought it was just some kind of copy/paste error, but now I'm
not so sure given how many files it's found in.

-atw
On Tue, Jun 23, 2009 at 5:14 PM, Adam Barth  wrote:

> [+sam]
>
> On Tue, Jun 23, 2009 at 5:11 PM, Drew Wilson wrote:
> > On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak 
> wrote:
> >> Also, there might be a subtle bug in the above code: what if
> window.Worker
> >> is first accessed from a different frame? Then the prototype of the
> Worker
> >> constructor itself will use the other frame's Object prototype as its
> >> prototype. I'm not sure if that is right. I think maybe
> JSWorkerConstructor
> >> should be passed the global object from which it is retrieved as a
> property,
> >> instead of using the lexical global object.
> >
> > Good catch. This bug seems to be in all our custom generated
> constructors.
>
> Yes.  This has caused us headaches (e.g., security bugs) in the past.
>
> Adam
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit Plugin Fallback, Registering for Image MIME Types

[Mark Rowe]

On 2009-07-02, at 21:42, Simone Manganelli wrote:

On that note, I've also been exploring taking over control of the  
display of the image/gif MIME type, but what's puzzling is that it  
seems that WebKit handles this MIME type internally, regardless of  
whether another plug-in registers for it or not, even if I remove  
the QuickTime plugin entirely.  (I've filed a bug for this as well: https://bugs.webkit.org/show_bug.cgi?id=26946 
 .)  Is this a deliberate design decision not to allow other plug- 
ins to handle images that QuickTime handles?  I've tested this with  
image/png and it produced a similar effect.  Is this an unchangeable  
policy, or is it feasible to allow plug-ins to handle these MIME  
types?


Image elements are not plug-ins.

- Mark



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] WebKit Plugin Fallback, Registering for Image MIME Types

[Simone Manganelli]

Hey all --

I'm one of the developers on the ClickToFlash project, a WebKit plugin  
that works to block Flash until the user specifically clicks on the  
view (I have it on good authority that some of you may already know of  
me or the project :) ).


Anyway, I was wondering about the feasibility/implementation of a  
couple of changes to plugin handling that would greatly help secure  
the future of ClickToFlash as well as making a bunch of us  
ClickToFlash devs secure in knowing that our efforts won't be for  
naught somewhere down the line.


First of all, it'd be great if there was a way to implement fallback  
to other plug-ins when handling content.  That is, ClickToFlash  
registers for the MIME type application/x-shockwave-flash, but then to  
get WebKit to fall back to the Flash plugin to finally display it, we  
have to do some DOM swizzling by changing the MIME type of the content  
to application/futuresplash.


Instead, it'd be better if there was an official way to do this.  I've  
filed a bug on the problem on Bugzilla ( https://bugs.webkit.org/show_bug.cgi?id=25540 
 ).  Mark Rowe suggested that a possible mechanism for accomplishing  
this would be for plug-ins to return nil in response to  
+plugInViewWithArguments: , which would then cause WebKit to search  
for another plug-in that can handle that content.  Is this a feasible  
method?  I'd appreciate any thoughts.  (I've downloaded the WebKit  
source myself and attempted to do a bit of patching myself, but didn't  
get too far, and besides, I have a lowly MacBook which screams out for  
mercy when compiling WebKit.)


On that note, I've also been exploring taking over control of the  
display of the image/gif MIME type, but what's puzzling is that it  
seems that WebKit handles this MIME type internally, regardless of  
whether another plug-in registers for it or not, even if I remove the  
QuickTime plugin entirely.  (I've filed a bug for this as well: https://bugs.webkit.org/show_bug.cgi?id=26946 
 .)  Is this a deliberate design decision not to allow other plug-ins  
to handle images that QuickTime handles?  I've tested this with image/ 
png and it produced a similar effect.  Is this an unchangeable policy,  
or is it feasible to allow plug-ins to handle these MIME types?


Any guidance would be greatly appreciated.  Thanks for your time.

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

[webkit-dev] New WebKit Security policy

[Maciej Stachowiak]

The WebKit Security Group has adopted a new policy on security bugs  
and security group membership: 


I encourage vendors who are shipping WebKit or individuals with a  
particular interest in security to study this policy. The purpose of  
the policy is to enable us to effectively deploy security fixes to the  
widest possible range of users without inadvertent public disclosure.


Members of the Webkit Security Group are listed here: 


Regards,
Maciej

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

[webkit-dev] Some new mailing lists

[Maciej Stachowiak]

Hello folks,

Based on popular demand, we have created two new mailing lists to  
handle some content that's off-topic for webkit-dev. The new lists are:


webkit-help -- requests for help with building webkit, using WebKit's  
APIs, embedding WebKit, porting WebKit, and so forth


  I suggest that anyone who would like to help others with WebKit  
topics that aren't about the development of WebKit itself, or people  
interested in asking such questions, should subscribe. We will  
gradually migrate this kind of material off of webkit-dev.


webkit-jobs -- post about WebKit-related jobs.

  I suggest that anyone who would like to post or hear about WebKit- 
related employment opportunities should subscribe.


I have subscribed to both lists.

Regards,
Maciej

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

[webkit-dev] Build Slave Downtime Tomorrow

[Mark Rowe]

Hi all,

The Tiger, Leopard and Windows build slaves will be offline for most  
of the day tomorrow while networking upgrades are performed in the  
building where they are hosted.  We'll aim to get them back online as  
quickly as possible after the upgrade is complete. build.webkit.org  
itself will remain up, so hopefully people will make an effort to keep  
the remaining build slave green.


Let me know if you have any questions.

- Mark



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Show more context in diffs

[Jeremy Orlow]

On Thu, Jul 2, 2009 at 4:37 PM, Maciej Stachowiak  wrote:

>
> On Jul 2, 2009, at 4:33 PM, Julie Parent wrote:
>
> When viewing patches on bugs.webkit.org, either with the review tool or
> prettydiff, I regularly find the 3 lines of context provided to
> be insufficient to really understand the code change.  This may be because I
> am new to the code base, or because I am used to review tools like Rietveld,
> but I find that every time I want to look at a patch, I have to open the
> file side by side with the patch window to fully understand the change.
>  This is very annoying and often leads me to just give up and not bother
> fully understanding the code.
> Proposal: I'd like to change svn-create-patch to increase the number of
> lines of context provided (suggestions for how many are welcome).  One
> downside to doing this of course would be that patch sizes would increase.
>
>
> I don't think it's just because you're (relatively) new. I often wish for
> more context myself.
>

I would definitely find this useful as well.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Maciej Stachowiak]

On Jul 2, 2009, at 4:52 PM, Sam Weinig wrote:

While clearly a personal preference, I don't like the default  
prepare-changelog default text and would much rather we revert to  
the old one.  I don't think the new text adds anything and will  
likely be ignored by most.  Can we leave the --bug= option and  
revert to the old template?


I expressed concern that the new template is too noisy. However, the  
"OOPS" part of it can enable the tools to help you notice if you  
forgot to include a description. Maybe if we got rid of the all-caps  
other than "OOPS", and perhaps prepare-ChangeLog can prompt for a bug  
number instead of just inserting complaint text by default.


 - Maciej



-Sam


On Wed, Jul 1, 2009 at 10:44 PM, Eric Seidel  wrote:
Background: Reviewers spend too much time correcting errors which
should be caught by tools.  This is frustrating both to contributers
and reviewers.  One such class of errors are missing or incorrect
information in ChangeLogs.  I'm trying to fix that.


As part of:
http://trac.webkit.org/changeset/45464

prepare-ChangeLog now takes an optional --bug= argument and is able to
fill in more than before:

% prepare-ChangeLog --bug=26383
 Running status to find changed, added, or removed files.
 Reviewing diff to determine which lines changed.
 Change author: Eric Seidel .
 Description from bug 26383:
   "prepare-ChangeLog should have a --bug= argument and use it for
url autofill".
 Editing the ../WebCore/ChangeLog file.

Results in:
2009-07-01  Eric Seidel  

   Reviewed by NOBODY (OOPS!).

   prepare-ChangeLog should have a --bug= argument and use it for
url autofill
   https://bugs.webkit.org/show_bug.cgi?id=26383

   DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
   http://webkit.org/coding/contributing.html FOR MORE INFORMATION

   Tests: fast/foo.html

   * foo.cpp: Added.



Running prepare-ChangeLog by default will however output more boiler- 
plate:


2009-07-01  Eric Seidel  

   Reviewed by NOBODY (OOPS!).

   SHORT DESCRIPTION/BUG TITLE GOES HERE (OOPS!)
   BUG URL GOES HERE (pass --bug= to autofill)

   DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
   http://webkit.org/coding/contributing.html FOR MORE INFORMATION

   LIST OF TESTS, OR EXPLANATION WHY TESTING IS IMPOSSIBLE GOES
HERE (OOPS!)

   * foo.cpp: Added.


However, hopefully the boilerplate is more helpful than before.


Unfortunately everyone will now see:
   DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
   http://webkit.org/coding/contributing.html FOR MORE INFORMATION

in their initial ChangeLogs.  This may be annoying to seasoned
contributers (and I'm open to removing it).  But hopefully it will
lead to better ChangeLogs overall.


Looking forward to your comments!

-eric
___
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


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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Sam Weinig]

While clearly a personal preference, I don't like the default
prepare-changelog default text and would much rather we revert to the old
one.  I don't think the new text adds anything and will likely be ignored by
most.  Can we leave the --bug= option and revert to the old template?
-Sam


On Wed, Jul 1, 2009 at 10:44 PM, Eric Seidel  wrote:

> Background: Reviewers spend too much time correcting errors which
> should be caught by tools.  This is frustrating both to contributers
> and reviewers.  One such class of errors are missing or incorrect
> information in ChangeLogs.  I'm trying to fix that.
>
>
> As part of:
> http://trac.webkit.org/changeset/45464
>
> prepare-ChangeLog now takes an optional --bug= argument and is able to
> fill in more than before:
>
> % prepare-ChangeLog --bug=26383
>  Running status to find changed, added, or removed files.
>  Reviewing diff to determine which lines changed.
>  Change author: Eric Seidel .
>  Description from bug 26383:
>"prepare-ChangeLog should have a --bug= argument and use it for
> url autofill".
>  Editing the ../WebCore/ChangeLog file.
>
> Results in:
> 2009-07-01  Eric Seidel  
>
>Reviewed by NOBODY (OOPS!).
>
>prepare-ChangeLog should have a --bug= argument and use it for
> url autofill
>https://bugs.webkit.org/show_bug.cgi?id=26383
>
>DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
>http://webkit.org/coding/contributing.html FOR MORE INFORMATION
>
>Tests: fast/foo.html
>
>* foo.cpp: Added.
>
>
>
> Running prepare-ChangeLog by default will however output more boiler-plate:
>
> 2009-07-01  Eric Seidel  
>
>Reviewed by NOBODY (OOPS!).
>
>SHORT DESCRIPTION/BUG TITLE GOES HERE (OOPS!)
>BUG URL GOES HERE (pass --bug= to autofill)
>
>DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
>http://webkit.org/coding/contributing.html FOR MORE INFORMATION
>
>LIST OF TESTS, OR EXPLANATION WHY TESTING IS IMPOSSIBLE GOES
> HERE (OOPS!)
>
>* foo.cpp: Added.
>
>
> However, hopefully the boilerplate is more helpful than before.
>
>
> Unfortunately everyone will now see:
>DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
>http://webkit.org/coding/contributing.html FOR MORE INFORMATION
>
> in their initial ChangeLogs.  This may be annoying to seasoned
> contributers (and I'm open to removing it).  But hopefully it will
> lead to better ChangeLogs overall.
>
>
> Looking forward to your comments!
>
> -eric
> ___
> 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

[webkit-dev] Progress Indicator rules

[Peter Abrahamsen]

Good day, everyone,

As a web developer, I've tried to find an explanation of when
Webkit/Safari decides that the page is done loading, but come up
empty-handed.

I want to issue a long-lived XHR relatively soon after page load to
receive events from a server. Unfortunately, if I do this even a
second or so after onload fires, the XHR will cause the load progress
indicator to stay on permanently. I have to wait several seconds - 3-5
or so before issuing the request for it not to be considered
(apparently) part of the initial page load.

Can anyone explain, or has someone already, the sequence of events
while loading the page, in terms of DOM events and the progress
("busy") indicator? How can I know from javascript that the page load
is complete, since this is apparently not the case before onload
fires?

Many thanks,

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

Re: [webkit-dev] Show more context in diffs

[Maciej Stachowiak]

On Jul 2, 2009, at 4:33 PM, Julie Parent wrote:

When viewing patches on bugs.webkit.org, either with the review tool  
or prettydiff, I regularly find the 3 lines of context provided to  
be insufficient to really understand the code change.  This may be  
because I am new to the code base, or because I am used to review  
tools like Rietveld, but I find that every time I want to look at a  
patch, I have to open the file side by side with the patch window to  
fully understand the change.  This is very annoying and often leads  
me to just give up and not bother fully understanding the code.


Proposal: I'd like to change svn-create-patch to increase the number  
of lines of context provided (suggestions for how many are  
welcome).  One downside to doing this of course would be that patch  
sizes would increase.


I don't think it's just because you're (relatively) new. I often wish  
for more context myself.


 - Maciej

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

[webkit-dev] Show more context in diffs

[Julie Parent]

When viewing patches on bugs.webkit.org, either with the review tool or
prettydiff, I regularly find the 3 lines of context provided to
be insufficient to really understand the code change.  This may be because I
am new to the code base, or because I am used to review tools like Rietveld,
but I find that every time I want to look at a patch, I have to open the
file side by side with the patch window to fully understand the change.
 This is very annoying and often leads me to just give up and not bother
fully understanding the code.
Proposal: I'd like to change svn-create-patch to increase the number of
lines of context provided (suggestions for how many are welcome).  One
downside to doing this of course would be that patch sizes would increase.

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Maciej Stachowiak]

On Jul 2, 2009, at 2:50 PM, Timothy Hatcher wrote:

Having it all on the dateline is not the best for git users either.  
We usually remove that line, since git shows the first line of the  
commit log in many places.


In retrospect, committing to SVN also usually removes this line so I  
retract the suggestion.




On Jul 2, 2009, at 1:44 PM, Maciej Stachowiak wrote:


In the future maybe we could consider putting it in the dateline:

2009-06-30  Maciej Stachowiakrevewied by Sam  
Weinig


That way all the blame goes in one place. :-)





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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Timothy Hatcher]

Having it all on the dateline is not the best for git users either. We  
usually remove that line, since git shows the first line of the commit  
log in many places.


On Jul 2, 2009, at 1:44 PM, Maciej Stachowiak wrote:


In the future maybe we could consider putting it in the dateline:

2009-06-30  Maciej Stachowiakrevewied by Sam Weinig

That way all the blame goes in one place. :-)



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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Maciej Stachowiak]

On Jul 2, 2009, at 11:22 AM, Timothy Hatcher wrote:


I also agree and that is the style I use.


I've always kept the "Reviewed by" on top, to me it logically goes  
with the date/author line. I don't mind doing it the other way as long  
as prepare-ChangeLog helps me. In the future maybe we could consider  
putting it in the dateline:


2009-06-30  Maciej Stachowiakrevewied by Sam Weinig

That way all the blame goes in one place. :-)

 - Maciej




On Jul 2, 2009, at 7:05 AM, Adam Roben wrote:

- I generally move the "Reviewed by" line after the bug number/ 
description/URL.  When you're reading a ChangeLog entry/commit  
message (especially an older one), it's generally much more  
interesting which bug is being fixed rather than knowing who  
reviewed it.  (Also, putting the bug description first makes git's  
one-line description of each commit much more useful than either  
having a list of dates and the person who wrote the patch or  
having a list of patch reviewers.)


I agree with Dave on all three points. git users gotta stick  
together.


___
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] Changes to prepare-ChangeLog

[Timothy Hatcher]

I also agree and that is the style I use.

On Jul 2, 2009, at 7:05 AM, Adam Roben wrote:

- I generally move the "Reviewed by" line after the bug number/ 
description/URL.  When you're reading a ChangeLog entry/commit  
message (especially an older one), it's generally much more  
interesting which bug is being fixed rather than knowing who  
reviewed it.  (Also, putting the bug description first makes git's  
one-line description of each commit much more useful than either  
having a list of dates and the person who wrote the patch or having  
a list of patch reviewers.)


I agree with Dave on all three points. git users gotta stick together.


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

[webkit-dev] [JavaScript] How to find a word user moused over

[Xiaomei Ji]

Hello,
I am trying to write a JavaScript to find the word user moused over.

FireFox supports event.rangeOffset, which is the *character* offset the
cursor is at within the element. Given English word, using this offset, I
can find the previous and next spaces and know the word under the cursor.

But seems that Webkit does not support event.rangeOffset. Then, how to find
a word user moused over? or how to convert the event.clientX to the
*character* offset within an element? My understanding is that it must
involve encoding/font/font size, but I do not have clear idea on how it
works.

Appreciate any input!

Thanks,
Xiaomei


P.S. Following example (event.rangeOffest) works in FireFox, but not
Safari/Chromium.






function showToolTip(ev)
{
if (ev.rangeOffset) {
  //alert("yes again" + ev.rangeOffset);
  document.getElementById('divCoord').title = ev.rangeOffset;
}
}




hello, how are
you. 

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

Re: [webkit-dev] Reviewer Nomination: Peter Kasting

[David Hyatt]

Seconded.

On Jul 2, 2009, at 3:10 AM, Eric Seidel wrote:


I would like to nominate Peter Kasting as a WebKit reviewer.

Peter is most well known for all his work on the Image Decoders.  At
this point, I believe he's webkit's #1 expert on how they work.  Peter
also worked on other random bits of WebCore under the Don Gibson
pseudonym before Chrome was public.

I have found Peter a pleasure to work with, very technical, extremely
passionate, and quite level-headed.  (Even including some recent
arguments over image decoder architecture between Holger and Peter.)

Peter is well over 80 patches:
http://trac.webkit.org/search?q=kasting
http://trac.webkit.org/search?q=Don+Gibson

His patches have been reviewed by numerous other reviewers (including
myself), and he can be found everyday in #webkit as pkasting.

Do I hear a 2nd, 3rd?  (Ideally including at least one non-Google  
reviewer...)


-eric
___
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] Changes to prepare-ChangeLog

[Simon Fraser]

On Jul 2, 2009, at 12:40 AM, Eric Seidel wrote:


Agreed.  Although, Darin Adler is about the only person I ever see
fill in per-file/per-function information. :)

But you're right, that the message could be made more clear.  Maybe
something like:

CHANGE DESCRIPTION GOES HERE. (OOPS!) SEE:
http://webkit.org/coding/contributing.html FOR MORE INFORMATION
FILE AND FUNCTION CHANGES SHOULD BE DESCRIBED NEXT TO NAMES BELOW


Can we change it so that it's not SHOUTING? I'd prefer to see the  
lines to be edited by the committer start with an indicator, like:


---> Change description goes here (OOPS!)
---> File and function changes should be described.

etc.

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Joe Mason]

Maciej Stachowiak wrote:


With SVN at least, it's a lot faster and easier to do a text search on 
the ChangeLog than to retrieve and search the commit log history. 
Searching the actual commit logs is very slow online and doesn't work at 
all offline. The ChangeLog also ends up in static tarball drops, which 
is useful to people getting those.


There are scripts to autogenerate the ChangeLog from the SVN history 
(I've used svn2cl.pl in the past, don't know if there are better ones). 
 Why not just run one of these when you want to grep the ChangeLog? 
You could set it up to run automatically when you update if you wanted 
to always have an up-to-date ChangeLog.  It could also be used by the 
packager to generate ChangeLogs for the tarballs.


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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Benjamin Meyer]

On Jul 2, 2009, at 4:07 AM, Mike Hommey wrote:

On Thu, Jul 02, 2009 at 01:01:09AM -0700, Adam Barth > wrote:
On Thu, Jul 2, 2009 at 12:50 AM, Mike Hommey+web...@glandium.org> wrote:
I've always wondered, in the days of atomic commits and advanced  
SCM, why
fill changelogs at all ? Except for CVS, RCS or SCCS, any SCM  
already

stores the log of changes. Keeping a Changelog in the SCM is both a
duplication of information and a stick to beat yourself when you
cherry-pick or revert changes, or merge branches.


When I've ask similar questions in the past, I've been told:

1) Changelogs are easier to search / archive / fix up than commit  
log messages.


For search and archive, nothing prevents you to generate ChangeLogs  
for

that purpose.


2) We can review the Changelog messages using bugzilla's review
system, but it's harder to review the commit log message.


Not if the patch contains the commit message in its header, like git
or mercurial do. Creating a script for svn, if it doesn't already  
exist,

wouldn't be too hard, too.


Indeed, I never manually fill in a changelog and always use the script  
to autofill it from my git patch.  This means that everything in the  
changelog (at least for me) is a duplicate of what is already in the  
rcs which is a violation of the DRY principle.  If we ever move off  
svn I will propose that we should no longer maintain the changelog.   
It is duplicated information and causes update/merge errors/hassle.


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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Adam Roben]

On Jul 2, 2009, at 9:14 AM, David Kilzer wrote:

On Wednesday, July 1, 2009 10:44:16 PM, Eric Seidel  
 wrote:


> Results in:
> 2009-07-01  Eric Seidel  
>
> Reviewed by NOBODY (OOPS!).
>
> prepare-ChangeLog should have a --bug= argument and use it  
for

url autofill
> https://bugs.webkit.org/show_bug.cgi?id=26383
>
> DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
> http://webkit.org/coding/contributing.html FOR MORE  
INFORMATION

>
> Tests: fast/foo.html
>
> * foo.cpp: Added.

- I prefer having "Bug N: " before the actual bug description so  
I don't have to parse the URL myself for the bug number.  It also  
acts as a visual marker when I read the ChangeLog entry.


- I like putting angle brackets "<>" around the URL to set it off  
visually from other text.


- I generally move the "Reviewed by" line after the bug number/ 
description/URL.  When you're reading a ChangeLog entry/commit  
message (especially an older one), it's generally much more  
interesting which bug is being fixed rather than knowing who  
reviewed it.  (Also, putting the bug description first makes git's  
one-line description of each commit much more useful than either  
having a list of dates and the person who wrote the patch or having  
a list of patch reviewers.)


I agree with Dave on all three points. git users gotta stick together.

Here's an example entry that follows the format that I (and I think  
Dave) like:



+2009-04-20  Adam Roben  
+
+Change MemoryStream::createInstance to return a COMPtr
+
+Part of Bug 25294: All WebKit/win classes should return  
COMPtrs from

+their static constructor members
+
+
+Reviewed by Darin Adler.
+
+* MemoryStream.cpp:
+(MemoryStream::createInstance): Changed to return a COMPtr.
+(MemoryStream::Clone): Updated for createInstance change.
+* MemoryStream.h: Changed createInstance to return a COMPtr.
+
+* WebArchive.cpp:
+(WebArchive::data):
+* WebCoreSupport/EmbeddedWidget.cpp:
+(EmbeddedWidget::didReceiveData):
+* WebDataSource.cpp:
+(WebDataSource::data):
+* WebHistory.cpp:
+(WebHistory::data):
+* WebIconFetcher.cpp:
+(WebIconFetcherClient::finishedFetchingIcon):
+* WebResource.cpp:
+(WebResource::createInstance):
+Updated for changes to MemoryStream::createInstance.
+



-Adam

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

[webkit-dev] Text inside editor in zoomed state

[Nilesh Patil]

Hi

How does text drawing is handled inside text editor ( or  ) in Zoomed mode ?
I am confused how selection controllers work in this case and update
cursor position is updated.

Any insight on this will be great !!

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[David Kilzer]

On Wednesday, July 1, 2009 10:44:16 PM, Eric Seidel  wrote:


> Results in:
> 2009-07-01  Eric Seidel  
> 
> Reviewed by NOBODY (OOPS!).
> 
> prepare-ChangeLog should have a --bug= argument and use it for
url autofill
> https://bugs.webkit.org/show_bug.cgi?id=26383
> 
> DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
> http://webkit.org/coding/contributing.html FOR MORE INFORMATION
> 
> Tests: fast/foo.html
> 
> * foo.cpp: Added.


- I prefer having "Bug N: " before the actual bug description so I don't 
have to parse the URL myself for the bug number.  It also acts as a visual 
marker when I read the ChangeLog entry.

- I like putting angle brackets "<>" around the URL to set it off visually from 
other text.

- I generally move the "Reviewed by" line after the bug number/description/URL. 
 When you're reading a ChangeLog entry/commit message (especially an older 
one), it's generally much more interesting which bug is being fixed rather than 
knowing who reviewed it.  (Also, putting the bug description first makes git's 
one-line description of each commit much more useful than either having a list 
of dates and the person who wrote the patch or having a list of patch 
reviewers.)

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Maciej Stachowiak]

On Jul 2, 2009, at 1:07 AM, Mike Hommey wrote:

On Thu, Jul 02, 2009 at 01:01:09AM -0700, Adam Barth > wrote:
On Thu, Jul 2, 2009 at 12:50 AM, Mike Hommey+web...@glandium.org> wrote:
I've always wondered, in the days of atomic commits and advanced  
SCM, why
fill changelogs at all ? Except for CVS, RCS or SCCS, any SCM  
already

stores the log of changes. Keeping a Changelog in the SCM is both a
duplication of information and a stick to beat yourself when you
cherry-pick or revert changes, or merge branches.


When I've ask similar questions in the past, I've been told:

1) Changelogs are easier to search / archive / fix up than commit  
log messages.


For search and archive, nothing prevents you to generate ChangeLogs  
for

that purpose.


2) We can review the Changelog messages using bugzilla's review
system, but it's harder to review the commit log message.


Not if the patch contains the commit message in its header, like git
or mercurial do. Creating a script for svn, if it doesn't already  
exist,

wouldn't be too hard, too.


With SVN at least, it's a lot faster and easier to do a text search on  
the ChangeLog than to retrieve and search the commit log history.  
Searching the actual commit logs is very slow online and doesn't work  
at all offline. The ChangeLog also ends up in static tarball drops,  
which is useful to people getting those.


Regards,
Maciej

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

Re: [webkit-dev] Reviewer Nomination: Peter Kasting

[Mark Rowe]

On 2009-07-02, at 01:10, Eric Seidel wrote:


I would like to nominate Peter Kasting as a WebKit reviewer.

Peter is most well known for all his work on the Image Decoders.  At
this point, I believe he's webkit's #1 expert on how they work.  Peter
also worked on other random bits of WebCore under the Don Gibson
pseudonym before Chrome was public.

I have found Peter a pleasure to work with, very technical, extremely
passionate, and quite level-headed.  (Even including some recent
arguments over image decoder architecture between Holger and Peter.)

Peter is well over 80 patches:
http://trac.webkit.org/search?q=kasting
http://trac.webkit.org/search?q=Don+Gibson

His patches have been reviewed by numerous other reviewers (including
myself), and he can be found everyday in #webkit as pkasting.

Do I hear a 2nd, 3rd?  (Ideally including at least one non-Google  
reviewer...)


This is the wrong mailing list for reviewer nominations.

- Mark



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Reviewer Nomination: Peter Kasting

[Oliver Hunt]

I have difficulty seeing peter as a reviewer he has historically  
demonstrated a bad attitude wrt other ports, is reticent about fixing  
regressions in other ports.


I also think "expert" on how image decoders work is overrated as he is  
the only person who has done any work on them, and has repeatedly  
broken them on platforms he isn't directly involved in.


Given my recollection of working with him i don't yet believe he has  
reached the point where he should reasonably be considered for a  
reviewer.


--Oliver

On Jul 2, 2009, at 1:10 AM, Eric Seidel wrote:


I would like to nominate Peter Kasting as a WebKit reviewer.

Peter is most well known for all his work on the Image Decoders.  At
this point, I believe he's webkit's #1 expert on how they work.  Peter
also worked on other random bits of WebCore under the Don Gibson
pseudonym before Chrome was public.

I have found Peter a pleasure to work with, very technical, extremely
passionate, and quite level-headed.  (Even including some recent
arguments over image decoder architecture between Holger and Peter.)

Peter is well over 80 patches:
http://trac.webkit.org/search?q=kasting
http://trac.webkit.org/search?q=Don+Gibson

His patches have been reviewed by numerous other reviewers (including
myself), and he can be found everyday in #webkit as pkasting.

Do I hear a 2nd, 3rd?  (Ideally including at least one non-Google  
reviewer...)


-eric
___
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

[webkit-dev] Reviewer Nomination: Peter Kasting

[Eric Seidel]

I would like to nominate Peter Kasting as a WebKit reviewer.

Peter is most well known for all his work on the Image Decoders.  At
this point, I believe he's webkit's #1 expert on how they work.  Peter
also worked on other random bits of WebCore under the Don Gibson
pseudonym before Chrome was public.

I have found Peter a pleasure to work with, very technical, extremely
passionate, and quite level-headed.  (Even including some recent
arguments over image decoder architecture between Holger and Peter.)

Peter is well over 80 patches:
http://trac.webkit.org/search?q=kasting
http://trac.webkit.org/search?q=Don+Gibson

His patches have been reviewed by numerous other reviewers (including
myself), and he can be found everyday in #webkit as pkasting.

Do I hear a 2nd, 3rd?  (Ideally including at least one non-Google reviewer...)

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Mike Hommey]

On Thu, Jul 02, 2009 at 01:01:09AM -0700, Adam Barth  wrote:
> On Thu, Jul 2, 2009 at 12:50 AM, Mike Hommey wrote:
> > I've always wondered, in the days of atomic commits and advanced SCM, why
> > fill changelogs at all ? Except for CVS, RCS or SCCS, any SCM already
> > stores the log of changes. Keeping a Changelog in the SCM is both a
> > duplication of information and a stick to beat yourself when you
> > cherry-pick or revert changes, or merge branches.
> 
> When I've ask similar questions in the past, I've been told:
> 
> 1) Changelogs are easier to search / archive / fix up than commit log 
> messages.

For search and archive, nothing prevents you to generate ChangeLogs for
that purpose.

> 2) We can review the Changelog messages using bugzilla's review
> system, but it's harder to review the commit log message.

Not if the patch contains the commit message in its header, like git
or mercurial do. Creating a script for svn, if it doesn't already exist,
wouldn't be too hard, too.

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Adam Barth]

On Thu, Jul 2, 2009 at 12:50 AM, Mike Hommey wrote:
> I've always wondered, in the days of atomic commits and advanced SCM, why
> fill changelogs at all ? Except for CVS, RCS or SCCS, any SCM already
> stores the log of changes. Keeping a Changelog in the SCM is both a
> duplication of information and a stick to beat yourself when you
> cherry-pick or revert changes, or merge branches.

When I've ask similar questions in the past, I've been told:

1) Changelogs are easier to search / archive / fix up than commit log messages.

2) We can review the Changelog messages using bugzilla's review
system, but it's harder to review the commit log message.

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Mike Hommey]

On Thu, Jul 02, 2009 at 12:26:14AM -0700, Maciej Stachowiak  
wrote:
>
> On Jul 1, 2009, at 10:47 PM, Dan Bernstein wrote:
>
>>
>> On Jul 1, 2009, at 10:44 PM, Eric Seidel wrote:
>>
>>>   prepare-ChangeLog should have a --bug= argument and use it for
>>> url autofill
>>>   https://bugs.webkit.org/show_bug.cgi?id=26383
>>
>> I would much prefer if the bug URL came first. I believe that this is 
>> the prevailing style.
>
> Looking at the ChangeLog, I see a mix of different styles. I personally 
> prefer the human-readable short description first, and I prefer to prefix 
> it with a dash, like so:
>
> - Rename html4.css to html.css, since we target HTML5 now
>   https://bugs.webkit.org/show_bug.cgi?id=26873
>
> I wouldn't mind the URL first if it was much shorter and could be on the 
> same line as the summary.
>
> Not too picky about this, but since it's a matter of taste, I thought  
> I'd chime in.

I've always wondered, in the days of atomic commits and advanced SCM, why
fill changelogs at all ? Except for CVS, RCS or SCCS, any SCM already
stores the log of changes. Keeping a Changelog in the SCM is both a
duplication of information and a stick to beat yourself when you
cherry-pick or revert changes, or merge branches.

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Eric Seidel]

Agreed.  Although, Darin Adler is about the only person I ever see
fill in per-file/per-function information. :)

But you're right, that the message could be made more clear.  Maybe
something like:

CHANGE DESCRIPTION GOES HERE. (OOPS!) SEE:
http://webkit.org/coding/contributing.html FOR MORE INFORMATION
FILE AND FUNCTION CHANGES SHOULD BE DESCRIBED NEXT TO NAMES BELOW

Seems kinda verbose.  Hopefully people will actually read
http://webkit.org/coding/contributing.html

-eric

On Thu, Jul 2, 2009 at 12:22 AM, Alexey Proskuryakov wrote:
>
> 02.07.2009, в 9:44, Eric Seidel написал(а):
>
>>       DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
>>       http://webkit.org/coding/contributing.html FOR MORE INFORMATION
>>
>>       Tests: fast/foo.html
>>
>>       * foo.cpp: Added.
>
>
> |n most cases, detailed description of changes would better be per-file or
> per-function, not in a blob above the list of changes.
>
> - WBR, Alexey Proskuryakov
>
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[Maciej Stachowiak]

On Jul 1, 2009, at 10:47 PM, Dan Bernstein wrote:



On Jul 1, 2009, at 10:44 PM, Eric Seidel wrote:


  prepare-ChangeLog should have a --bug= argument and use it for
url autofill
  https://bugs.webkit.org/show_bug.cgi?id=26383


I would much prefer if the bug URL came first. I believe that this  
is the prevailing style.


Looking at the ChangeLog, I see a mix of different styles. I  
personally prefer the human-readable short description first, and I  
prefer to prefix it with a dash, like so:


- Rename html4.css to html.css, since we target HTML5 now
https://bugs.webkit.org/show_bug.cgi?id=26873

I wouldn't mind the URL first if it was much shorter and could be on  
the same line as the summary.


Not too picky about this, but since it's a matter of taste, I thought  
I'd chime in.


 - Maciej

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

Re: [webkit-dev] Changes to prepare-ChangeLog

[Alexey Proskuryakov]

02.07.2009, в 9:44, Eric Seidel написал(а):


   DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE:
   http://webkit.org/coding/contributing.html FOR MORE INFORMATION

   Tests: fast/foo.html

   * foo.cpp: Added.



|n most cases, detailed description of changes would better be per- 
file or per-function, not in a blob above the list of changes.


- WBR, Alexey Proskuryakov



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