Re: [webkit-dev] Bugzilla "Triaged" keyword

[David Kilzer]

I've renamed "Triaged" to "QtTriaged".

Dave



- Original Message 
> From: Jocelyn Turcotte 
> To: webkit-dev@lists.webkit.org
> Sent: Tue, April 27, 2010 10:02:36 AM
> Subject: Re: [webkit-dev] Bugzilla "Triaged" keyword
> 
> On 4/27/2010 5:38 PM, ext Alexey Proskuryakov wrote:
> 27.04.2010, в 
> 00:56, Tor Arne Vestbø написал(а):
>
>
>>> 
> As far as I know QtWebKit uses this keyword to indicate that the
>>> 
> corresponding bug has been checked and prioritized based on its 
> severity
>>> by a triaging group of two QtWebKit 
> developers.
>>>
>>> 
> href="https://trac.webkit.org/wiki/QtWebKitBugs#Triagingbugs"; target=_blank 
> >https://trac.webkit.org/wiki/QtWebKitBugs#Triagingbugs
>>>  
>   
>> That's correct. It's an attempt at using 
> Bugzilla for all our bugs, and to manage them with some sense of "control" 
> over 
> what's there :)
>>  
> I can imagine ongoing 
> confusion about this keyword. Would it makes sense to rename to something 
> like 
> QtTriaged?
>
>
If you believe that for other ports 
> it will bring more confusion than 
use, then please do 
> so.

Jocelyn

___
webkit-dev 
> mailing list

> href="mailto:webkit-dev@lists.webkit.org";>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] Yet another bug-less change hosed the tree.

[David Kilzer]

On Tue, May 11, 2010 at 2:30:45 PM, Geoffrey Garen wrote:

> I don't know how to do either of these steps in an easy way:
> 
> 1. Once I have a patch with a ChangeLog, say, "File a new 
> bug and upload this patch for review." (Bonus points if the
> tool automatically made the first line of the ChangeLog the
> title of the bug.)


The little-known, little-used "webkit-patch create-bug" command does this today 
with the "--no-prompt" switch.  However, you can't limit it to a single 
directory for svn (like other webkit-patch commands), you can't give it a patch 
file to upload (interesting idea), and it's probably only been tested (by me) 
with git.

The "webkit-patch upload" command is the preferred alternative, although it 
still doesn't have a way to make the first line of the ChangeLog the title of 
the bug (which is the main reason I haven't switched to using it), and it has 
over 3x the number of command-line switches as create-bug.  (I must read 
through the switches for any webkit-patch subcommand because I don't use it 
frequently enough to remember them.)

> 2. Once the patch has been reviewed, say, "Add bug # and
> reviewer information from Bugzilla, commit, and close the
> bug." (Bonus points if the commit happens via the bugzilla 
> patch, so I can move on to working on another patch.)

My initial thought for doing this was to provide a placeholder (like 
"http://webkit.org/b/0";) with prepare-ChangeLog so that webkit-patch could 
update it at the right time, just like it does with the reviewer.

Another approach would be to write a rule that adds the bug number at a 
particular location in the ChangeLog each time--as long as it was smart enough 
not to duplicate bug links if one was already present.

Dave

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

Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit

[David Kilzer]

On Fri, May 14, 2010 at 6:29:05 PM, Ojan Vafai wrote:

> tonikitoo, aroben, ddkilzer: You are the three who I remember
> voicing yourselves about wanting webkit-patch to support
> committing/uploading multiple patches from the same branch.
> Would Chris's suggestion below (last couple paragraphs) be
> acceptable to you? I prefer it as it makes webkit-patch less
> confusing to people who aren't very comfortable with git, but
> it does not 100% meet the needs you've asked for in the past.


Since webkit-patch doesn't meet my needs for posting a "patch series" to a 
single bug today, I have no opinion either way on the matter other than 
"simpler is better", so I would support Chris' suggestion.

Personally, I don't see why both models (single patches and multiple patches) 
couldn't be supported based on the arguments passed to webkit-patch.  git 
itself seems to be able to figure out if the user is referring to a single 
commit or a series of commits (based on the context of the command-line 
arguments and what the command does), so I don't see why we have to introduce 
additional command-line switches for various behavior. (See the git-send-email 
command as an example since it's designed to send email for a single patch or a 
series of patches.)

In my opinion, webkit-patch should default to single commit behavior unless the 
user specifies a range.  That way, git neophytes and the majority of existing 
users get the single-commit-to-a-single-bug behavior by default.  However, if a 
range of commits is given, then webkit-patch would be smart enough to post the 
series of patches to a single bug.

Dave

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

Re: [webkit-dev] svn-apply: ideal fuzz value to merge changelogs

[David Kilzer]

Providing 8 lines of context instead of 3 lines to the ChangeLog part of a 
patch isn't going to help with reviewing or merging patches.  If you want to 
provide more context to the rest of the patch, I think you should find a way to 
keep the number of lines of context for ChangeLog diffs to 3 lines.  (Perhaps 
git has some way to provide per-file settings for the diff command, much like 
it does for the merge driver in .gitattributes?)

It's unfortunate that git doesn't include "-U8" in the "diff --git a/foo b/foo" 
line in the patches it generates.  If it did, then the tools could be updated 
to parse the number of lines of context and use that in the patch command.

Dave





From: tonikitoo (Antonio Gomes) 
To: webkit-dev Development 
Sent: Mon, May 24, 2010 11:55:03 AM
Subject: [webkit-dev] svn-apply: ideal fuzz value to merge changelogs

Hi.

Lately I've noticed that most of my patches uploaded to bugzilla could
not get processed by any of the EWS bots at all (see purple balloons
in https://bugs.webkit.org/show_bug.cgi?id=36463 , for example). Chris
Jerdonek guess that I was generating my patches with special
parameters that were making svn-apply to fail to apply them, and it
seems he was right: as an attempt to give reviewers more context to
review my patches I will generating them with 8 lines of context.

$ git format-patch -1 HASH_OF_THE_PATCH -U8

According to him, "... the ChangeLog diffs are applied with "fuzz=3"
to allow the patch to apply (and be inserted at the top) ...", and so
my 8-lines context'ed patches are failing to apply due to that.
Options that were given to me are:

* generate myself a diff that has 3 lines of context just for the ChangeLog part
* change the "fuzz=3" to "fuzz=8" in svn-apply for ChangeLogs.

I support the later, but before anything I would like to know if you
guys have any objection? known issues?

Cheers,

-- 
--Antonio Gomes
___
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] Directory upload experimental feature

[David Kilzer]

> Other alternatives?

I believe Safari will zip a folder and send it as a single file for you if you 
attach a folder to a file upload element instead of an individual file.

Dave





From: John Gregg 
To: Sam Weinig 
Cc: webkit-dev@lists.webkit.org
Sent: Tue, June 1, 2010 3:09:00 PM
Subject: Re: [webkit-dev] Directory upload experimental feature

My proposal for that is that all the files would be listed in the form 
submission the same way as if it were a , but in 
the Content-Disposition header, the filename component would contain the path 
information. 

One alternative idea would be add a "path" component to the Content-Disposition 
header alongside the filename which remains unchanged, but I think that would 
be a much more difficult approach.  Other alternatives?

Example follows.

 -John


If you are have these files
/home/John/photos/vacation/1.jpeg
/home/John/photos/vacation/2.jpeg
/home/John/photos/conference/1.jpeg

and choose "photos" from the directory picker, you'd end up with
input.files[0].name = "1.jpeg"
input.files[0].path = "photos/vacation/1.jpeg"
input.files[1].name = "2.jpeg"
input.files[1].path = "photos/vacation/2.jpeg"
input.files[2].name = "1.jpeg"
input.files[2].path = "photos/conference/1.jpeg"

Your POST would look like
Content-type: multipart/form-data; boundary=WebKitFormBoundaryFoo


WebKitFormBoundaryFoo
Content-Disposition: form-data; name="input"; filename="photos/vacation/1.jpeg"
Content-Type: image/jpeg



WebKitFormBoundaryFoo
Content-Disposition: form-data; name="input"; filename="photos/vacation/2.jpeg"
Content-Type: image/jpeg



WebKitFormBoundaryFoo
Content-Disposition: form-data; name="input"; 
filename="photos/conference/1.jpeg"
Content-Type: image/jpeg





On Sat, May 29, 2010 at 10:22 AM, Sam Weinig  wrote:

How will the directory structure and all the files therein be represented in 
the form submission?
>
>
>-Sam
>
>
>On Fri, May 28, 2010 at 3:17 PM, John Gregg  wrote:
>
>Hi WebKit,
>>
>>
>>I recently proposed adding directory upload support to HTML via a new  
>>attribute to whatwg@, and the discussion arrived at "try it out".  Having 
>>written some code I think I have something that works pretty well, and I'd 
>>like to land it on an experimental basis in WebKit, but want to reach out 
>>early before trying to put any code in the tree.  The plan that comes to mind 
>>is a new ENABLE_DIRECTORY_UPLOAD flag, but I'm completely open to other 
>>options.
>>
>>
>>Background (cf. the whatwg thread 
>>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html): 
>> - The use case for this is a photo album or file manager web application, 
>> which wants the user to easily choose an entire directory to recursively 
>> upload, while preserving the sub-directory structure.
>> - The reason for the new attribute is to signal the UA to show a native 
>> folder-picker rather than a file-picker, which on most OSs are two distinct 
>> dialogs.
>> 
>>The approach I'm using has 2 parts and is a small amount of WebCore code 
>>(about 200 lines).
>> - Extend HTMLInputElement to support the directory attribute, which is 
>> passed up via FileChooser allowing the UA to display a folder-picker.  UA 
>> enumerates all the files and returns them in the normal way.
>> - Extend File to have a File.path property, which contains the path 
>> information starting from the chosen directory as the root.  
>> HTMLInputElement is responsible for generating these values from the list of 
>> files when the directory attribute is set.
>>
>>
>>Thoughts? 
>>
>>
>>Thanks, 
>> -John
>>
>>
>>
>>___
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] Directory upload experimental feature

[David Kilzer]

Also, I was simply pointing out existing behavior, not arguing for/against the 
zip file format.

Dave





From: Sam Weinig 
To: David Kilzer 
Cc: John Gregg ; webkit-dev@lists.webkit.org; Adele 
Peterson 
Sent: Wed, June 2, 2010 11:28:11 AM
Subject: Re: [webkit-dev] Directory upload experimental feature

I think this is only true for Mac OS X style bundles, not all folders.


On Wed, Jun 2, 2010 at 3:44 AM, David Kilzer  wrote:

> Other alternatives?
>
>
>I believe Safari will zip a folder and send it as a single file for you if you 
>attach a folder to a file upload element instead of an individual file.
>
>
>Dave
>
>
>
>
>

From: John Gregg 
>To: Sam Weinig 
>Cc: webkit-dev@lists.webkit.org
>Sent: Tue, June 1, 2010 3:09:00 PM
>Subject: Re: [webkit-dev] Directory upload experimental feature
>
>
>>My proposal for that is that all the files would be listed in the form 
>>submission the same way as if it were a , but in 
>>the Content-Disposition header, the filename component would contain the path 
>>information. 
>>
>
>One alternative idea would be add a "path" component to the 
>Content-Disposition header alongside the filename which remains unchanged, but 
>I think that would be a much more difficult approach.  Other alternatives?
>
>
>Example follows.
>
>
> -John
>
>
>
>If you are have these files
>/home/John/photos/vacation/1.jpeg
>/home/John/photos/vacation/2.jpeg
>>
>/home/John/photos/conference/1.jpeg
>
>
>and choose "photos" from the directory picker, you'd end up with
>input.files[0].name = "1.jpeg"
>input.files[0].path = "photos/vacation/1.jpeg"
>input.files[1].name = "2.jpeg"
>input.files[1].path = "photos/vacation/2.jpeg"
>input.files[2].name = "1.jpeg"
>input.files[2].path = "photos/conference/1.jpeg"
>
>
>Your POST would look like
>Content-type: multipart/form-data; boundary=WebKitFormBoundaryFoo
>
>
>WebKitFormBoundaryFoo
>Content-Disposition: form-data; name="input"; filename="photos/vacation/1.jpeg"
>Content-Type: image/jpeg
>
>
>
>
>
>WebKitFormBoundaryFoo
>Content-Disposition: form-data; name="input"; filename="photos/vacation/2.jpeg"
>Content-Type: image/jpeg
>
>
>
>
>
>WebKitFormBoundaryFoo
>Content-Disposition: form-data; name="input"; 
>filename="photos/conference/1.jpeg"
>Content-Type: image/jpeg
>
>
>
>
>
>
>
>On Sat, May 29, 2010 at 10:22 AM, Sam Weinig  wrote:
>
>How will the directory structure and all the files therein be represented in 
>the form submission?
>>
>>
>>-Sam
>>
>>
>>On Fri, May 28, 2010 at 3:17 PM, John Gregg  wrote:
>>
>>Hi WebKit,
>>>
>>>
>>>I recently proposed adding directory upload support to HTML via a new 
>>> attribute to whatwg@, and the discussion arrived at "try it out".  
>>>Having written some code I think I have something that works pretty well, 
>>>and I'd like to land it on an experimental basis in WebKit, but want to 
>>>reach out early before trying to put any code in the tree.  The plan that 
>>>comes to mind is a new ENABLE_DIRECTORY_UPLOAD flag, but I'm completely open 
>>>to other options.
>>>
>>>
>>>Background (cf. the whatwg thread 
>>>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html): 
>>> - The use case for this is a photo album or file manager web application, 
>>> which wants the user to easily choose an entire directory to recursively 
>>> upload, while preserving the sub-directory structure.
>>> - The reason for the new attribute is to signal the UA to show a native 
>>> folder-picker rather than a file-picker, which on most OSs are two distinct 
>>> dialogs.
>>> 
>>>The approach I'm using has 2 parts and is a small amount of WebCore code 
>>>(about 200 lines).
>>> - Extend HTMLInputElement to support the directory attribute, which is 
>>> passed up via FileChooser allowing the UA to display a folder-picker.  UA 
>>> enumerates all the files and returns them in the normal way.
>>> - Extend File to have a File.path property, which contains the path 
>>> information starting from the chosen directory as the root.  
>>> HTMLInputElement is responsible for generating these values from the list 
>>> of files when the directory attribute is set.
>>>
>>>
>>>Thoughts? 
>>>
>>>
>>>Thanks, 
>>> -John
>>>___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebCore Build Times

[David Kilzer]

On Jun 8, 2010, at 3:17 PM, Eric Seidel  wrote:

> On my Intel Core 2 Duo MBP a full build takes over 1 hour.  5 years
> ago, on my g4 laptop a full build took around 40m.  :(  We seem to be
> slowly moving in the wrong direction.

Was that before or after SVG was enabled in the engine?  :)  In general, I 
think the amount of code in WebCore has increased since 2005, which probably 
has more of an affect than unused headers.

Having said that, I thought it would be useful to write a script that would 
remove individual headers on a file-by-file basis and recompile WebKit to find 
unused header candidates.  I haven't had time to write such a script, though.

Dave

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

Re: [webkit-dev] LayoutTest with a fragment reported as the document URL?

[David Kilzer]

I think you want:

window.location.hash = 'name1';

I'm sure there are other layout tests that set the hash property, so you might 
search for them to get some ideas about how to build your test.

Dave
--
Sent from my iPhone 3GS

On Jun 7, 2010, at 2:04 PM, Chris Fleizach  wrote:

> 
> I'd like the loaded page to be a url like
> 
>>> http://layouttest/new-test.html#segment
> 
> so that
> 
> m_renderer->document()->url();
> 
> returns http://layouttest/new-test.html#segment
> 
> 
> On Jun 7, 2010, at 1:27 PM, Adam Barth wrote:
> 
>> I'd like to help you, but I don't know what you mean by "the
>> document's URL will be reported as".  Reported to whom via what?
>> 
>> Adam
>> 
>> 
>> On Mon, Jun 7, 2010 at 12:37 PM, Chris Fleizach  wrote:
>>> Hello,
>>> I need to write a layout test where the document's URL will be reported as
>>> http://layouttest/new-test.html#segment
>>> I tried
>>> window.location = url + "#name1";
>>> but that doesn't work
>>> any ideas?
>>> thanks
>>> ___
>>> 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] strategy for evaluating performance issues related to memory.

[David Kilzer]

On Jun 21, 2010, at 6:21 AM, Mike Marchywka  wrote:

> (and yes my disk light still comes on for minutes at a time locking me out of 
> doing antyhing with iceweasel or firefox)

Two things:

1. What hardware platform and O/S are you running a WebKit browser on that 
still uses a disk light?  (Do PC cases still have disk lights?  I guess I 
haven't looked recently.)

2. Why do you keep mentioning Iceweasel and Firefox?  Those browsers are based 
on Mozilla's Gecko engine, not WebKit.

Dave

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

Re: [webkit-dev] Should Table Cell (TD) children inherit height?

[David Kilzer]

How do Firefox and MSIE render the test case?

Dave
--
Sent from my iPhone 3GS

On Jun 28, 2010, at 11:42 AM, Fady Samuel  wrote:

> My understanding is that in quirks mode,  causes the 
> table to fill the entire client window. Now, I believe the height attribute 
> should trickle down to the TR and TD tags, correct? What about children of a 
> TD tag? If you add an empty div child to a table, should it fit the whole 
> cell, or should it have a size of 0?
> 
> 
> 
> 
> 
>   
> 
> 
> 
> 
> 
> WebKit will show you red instead of green because the div does not have a 
> height of 100%.
> 
> Now if you make the div's height 100%, you get green. 
> 
> Should a cell's child inherit height?
> 
> Thanks,
> 
> Fady Samuel

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

Re: [webkit-dev] DerivedSources.make & CPP DOM Bindings

[David Kilzer]

On Jul 8, 2010, at 11:04 AM, Kevin Ollivier  wrote:

> I'm working on making the CPP DOM bindings accessible to the wx port, and 
> while I've got the whole thing building, one thing I have yet to sort out is 
> how to add building of the CPP DOM bindings to the build system. 
> DerivedSources.make seems to be the appropriate place to put the code, and 
> it's where I've put things for now, but I wasn't sure if others would feel 
> this is the right place.

DerivedSources.make is the appropriate place for this.

> If I do add it, what is the appropriate way to do it? Should generation be 
> conditional on some define the port will set, like MAKE_CPP_BINDINGS, or 
> should we just directly check for BUILDING_ defines?

I would use BUILDING_ for now until such time as another port wants to 
enable it.

Dave
--
Sent from my iPhone 3GS
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?

[David Kilzer]

On Jul 9, 2010, at 7:34 AM, Adam Roben  wrote:

> On Jul 9, 2010, at 6:23 AM, Alex Milowski wrote:
> 
>> Should we keep the master bug?
>> 
>> Should we use it only for our implementation efforts and not
>> make it depend on every random bug filed for the MathML
>> component?
> 
> I think an important question to ask is, "When will you move the master bug 
> to Resolved/Fixed?" This is basically another way of saying, "What task(s) 
> does the master bug represent?" Once you know that answer, the answers to 
> your other questions may be obvious.

IMO, it should be closed once MathML is enabled in the WebKit nightly builds 
and/or most ports.

Dave
--
Sent from my iPhone 3GS
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] review queue crazy idea

[David Kilzer]

We should also publicize/update these existing resources to help patch authors 
find reviewers for their patches:

http://trac.webkit.org/wiki/CodeReview
http://trac.webkit.org/wiki/WebKit%20Team

I think the most effective approach is when patch authors proactively seek out 
reviewers.  We're all busy, but when I'm asked to review a patch, I make time 
for it or point the person at another reviewer.

Dave
--
Sent from my iPhone 4

On Jul 22, 2010, at 12:29 AM, Maciej Stachowiak  wrote:

> 
> On Jul 21, 2010, at 3:41 PM, Eric Seidel wrote:
> 
>> Wow.  I really like this idea of helping contributors better
>> understand what's going wrong.
>> 
>> But, I think that even better would be to build a better front-end for
>> reviews.  Or a bot which knew how to suggest reviewers (based on
>> annotate information from lines changed).
> 
> 
> I think a better UI for reviews, plus some better attempts at active 
> notification of potential reviewers, could go a long way. I'm a strong 
> believer in trying nudges and positive incentives before implementing harsher 
> policies.
> 
> Regards,
> Maciej
> 
> ___
> 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] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)

[David Kilzer]

On Jul 26, 2010, at 6:08 PM, Maciej Stachowiak  wrote:

> The main problem would be getting the right path to the script file. Unless 
> we duplicate it in every directory with script tests, it kinda has to be a 
> relative path that depends on the directory.

Subversion (and git) handle relative symbolic links just fine, so that is 
another option.

Dave
--
Sent from my iPhone 4

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

Re: [webkit-dev] Some new coding style rules

[David Kilzer]

On Wed, August 4, 2010 at 11:56:53 PM, Sam Weinig wrote:
> On Wed, Aug 4, 2010 at 1:29 AM, Nikolas Zimmermann 
> wrote:
> 
> >namespace WebCore {
> >...
> >} // namespace WebCore
> >
> >2. ENABLE(FOO) #endif comments
> >
> >#if ENABLE(FOO)
> >..
> >#endif // ENABLE(FOO)
> 
> I like these two forms of comments.

As do I.  My preference for rules is:

- Always use "} // namespace Foo" comments with namespaces.

- Always use "#endif // ENABLE(FOO)" comments if there are more than 10-15 
lines  of code between the matching #if/#else/#elif, or if the #endif is 
nested.  But  do not treat it as a warning/error if an #endif macro has a 
well-formed comment  and doesn't obey the 'required' rules in the previous 
sentence (unless this inconsistency would drive anyone nuts).


I like both of these comments for the following reasons:


- You don't have to scroll up or otherwise jump around the source to know 
what the right curly brace or the #endif macro is used for.

In the namespace case, the block almost always spans most of the file, so 
there's rarely a case when it's less than 10 lines away from the left 
curly brace.  Or to put it another way, the "namespace Foo {" line is always 
near the top of the file, and the "} // namespace Foo" line is always near the 
bottom of the file, so it's rare that you see them both at the same time.

In the case of the #endif macro, I find that the comments are useful if 
the corresponding #if/#else/#elif is more than 10-15 lines away (e.g., more 
than 
a screenful), or if there is any #if macro nesting such that #endif statements 
can appear next to each other (see Platform.h).


- When merging, having these comments are a great help to both the person 
doing the merge and to merge algorithms.

New methods are often added near the end of a namespace, which means the "}" 
for the end of the method looks the same as the "}" for the end of a 
namespace (especially with our current namespace indent rules), so merges with 
conflicts sometimes end up "repurposing" the namespace curly brace for the end 
of a new method.  Providing an explicit comment prevents this behavior, and 
provides a common anchor point in both the original ("ours") and new ("theirs") 
files.

Likewise, #endif macros (especially when grouped together due to nesting) 
will frequently get "repurposed" by merge algorithms.  This can create more 
work (especially the way some macros are nested in Platform.h) if there are 
changes to both files being merged.

--

On a related note, I think we should also define rules for indenting #if 
macros.  I think this is orthogonal to using comments, though, and I prefer 
having comments regardless of the indent rules.

Note that macro indenting has already started (haphazardly) in Platform.h 
and perhaps a few other places.

Here are some examples:

#if ENABLE(FOO)
#if PLATFORM(BAR)
#if USE(BAZ)
...
#else
...
#endif // USE(BAZ)
#endif // PLATFORM(BAR)
#endif // ENABLE(FOO)

#if ENABLE(FOO)
# if PLATFORM(BAR)
#  if USE(BAZ)
...
#  else
...
#  endif // USE(BAZ)
# endif // PLATFORM(BAR)
#endif // ENABLE(FOO)

#if ENABLE(FOO)
#if PLATFORM(BAR)
  #if USE(BAZ)
...
#else
...
  #endif // USE(BAZ)
#endif // PLATFORM(BAR)
#endif // ENABLE(FOO)

My original opinion was to never indent macros, but after staring at the 
above examples, I do think indenting makes them easier to read.  I'm still 
trying to decide whether I like the "#" anchored on the left or whether I 
prefer 
it anchored to if/else/elif/endif macro names, though.

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

Re: [webkit-dev] Build system complexity

[David Kilzer]

On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc  wrote:

> i completely agree with jeremy. is it possible to at least drop the cryptic 
> hashcodes/timestamps? without them, the .xcodeproj files should at least be 
> editable by hand.

Doesn't gyp already generate Xcode projects for Chrome?  I think the issue is 
that gyp can't generate replacement project files for Apple's Mac port or other 
build systems yet.  That was my take-away from the last discussion--that gyp 
needed to be enhanced so that all build systems could be generated, making 
addition or removal of source files a trivial task.

As far as Jeremy's other points, perhaps bugs should be filed about each item 
so that more specific discussion can take place on each topic.

Dave

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

Re: [webkit-dev] Number of pending commits

[David Kilzer]

On Sep 7, 2010, at 9:51 AM, Eric Seidel  wrote:

> I also attempted to look through pending-commit last week.  I decided
> to clean it out someone needs to write a script which can make a guess
> if a bug is landed or not.  I would guess that over half of
> http://webkit.org/pending-commit are already landed and the lander
> forgot to close the bug. [1]
> 
> You should feel free to CQ as much of it as you like.  The CQ is far
> from capacity.  It's slower than it should be during peek hours
> (mostly due to flaky tests combined with ChangeLog/checkout
> contention), but I'm working on making it faster.
> 
> -eric
> 
> 1.  FYI, if you prefer to land your patches w/o the assistance of
> webkit-patch land (which will update and close the bug for you), you
> might consider using "webkit-patch mark-bug-fixed" right after
> landing.  It's a command written by Dave Kiltzer which looks at the
> most recent revision and updates and closes the bug associated with
> that revision.

It's most useful immediately after landing a patch.  Otherwise, you may need to 
specify both the bug number and revision on the command-line.

It should work in both git and svn working directories, though.

Dave
--
Sent from my iPhone 4


> On Tue, Sep 7, 2010 at 1:09 AM, Adam Barth  wrote:
>> I tried to clean out pending-commit a few weeks ago.  I found that
>> many of the patches had already been landed but the bugs hadn't been
>> closed.  The commit-queue should be able to handle as many patches as
>> you throw at it, so that shouldn't be the limiting factor.
>> 
>> Adam
>> 
>> 
>> On Tue, Sep 7, 2010 at 1:03 AM, Holger Freyther  wrote:
>>> Hi,
>>> 
>>> I was just seeing that we have about 84 bugs which are in the pending-commit
>>> state, on the Gtk+ bugs I clicked the patches need to be landed manually.
>>> 
>>> It would be nice to get a hand landing these patches, or asking the commit
>>> queue to take care of them.
>>> 
>>> thanks
>>>holger
>>> ___
>>> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Canvas component in Bugzilla

[David Kilzer]

On Sep 14, 2010, at 10:22 PM, Darin Adler  wrote:

> On Sep 14, 2010, at 5:54 PM, Andreas Kling wrote:
> 
>> I propose we add a "Canvas" component in Bugzilla. Thoughts?
> 
> Sounds OK to me.

Done.

Dave
--
Sent from my iPhone 4

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

Re: [webkit-dev] Review tool changes

[David Kilzer]

On Sep 17, 2010, at 6:38 AM, Mike Pinkerton  wrote:

> On Fri, Sep 17, 2010 at 2:39 AM, Adam Barth  wrote:
> 
>> The tool has some problems on iPad.  The issue is the bottom toolbar
>> uses position: fixed, which seems to be frozen to the initial viewport
>> on iPad.  When you scroll, the bar stays in the middle of the page.  I
>> presume there's some way to fix this.  It's on my list.
> 
> A lot of sites have this problem, it seems. What is it about the iPad
> in particular that causes this issue? I doubt it's a webkit "bug" but
> it manifests itself as only happening on the iPad so most site
> designers end up not caring to fix, or not being able to diagnose the
> problem for lack of hardware. I frequent at least two sites with this
> behavior.

It has to do with how iOS WebKit defines the viewport.



Dave
--
Sent from my iPhone 4

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

Re: [webkit-dev] webkit-patch --suggest-reviewers

[David Kilzer]

Thanks guys!  I really like this feature, but it would be great if you could 
pick individuals from the list of suggested reviewers instead of all-or-none:

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

Dave





From: Adam Barth 
To: webkit-dev@lists.webkit.org
Sent: Thu, October 21, 2010 10:09:12 PM
Subject: [webkit-dev] webkit-patch --suggest-reviewers

Eric and I are working on a new feature of webkit-patch to make it
easier for you to find reviewers for your code.  When you upload a
patch with webkit-patch, you can try passing the --suggest-reviewers
option.  webkit-patch will look at your patch and try to guess who
might be good reviewers (and offer to CC them).  This feature is very
experimental, but I'd like to encourage you to give it a try and let
us know what you think.

At some point, we'd like to use this same idea in reverse and have a
way to ask http://webkit.org/pending-review for patches that you might
be the right person to review.

Enjoy!
Adam___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Client-based Geolocation

[David Kilzer]

On Dec 10, 2010, at 6:45 AM, John Knottenbelt  wrote:

> It would be great if, ultimately, we could remove the non-client-based 
> geolocation code from WebCore (I already have plans to do this for Chromium's 
> WebKit layer). Such a removal would make the WebCore code more readable 
> because the #if ENABLE(CLIENT_BASED_GEOLOCATION) preprocessor directives 
> would go away, more understandable because there would be less code, and more 
> maintainable because we would only need to fix bugs in one code path, rather 
> than two. 
> 
> It seems that Android, Qt and GTK currently implement the non-client-based 
> design.

The iOS port also uses the non-client-based design.

> Is anybody working, or interested in working, on migrating these platforms to 
> the client-based design? 

I would file a bug for each port to start with.

Dave
--
Sent from my iPhone 4

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

Re: [webkit-dev] Stability problems involving Javascript GC

[David Kilzer]

On Dec 17, 2010, at 12:02 AM, Zoltan Herczeg wrote:

>>> On 6 December 2010 22:31, Zoltan Herczeg  wrote:
 Crash in WTF::fastMalloc? Such things only happen if something overwrites
 memory areas belongs to the memory manager (i.e overwrites some bytes
 before or after a block returned by malloc). Try some valgrind equivalent
 on mac to detect those writings into "red zones".
>>> 
>>> How can you use valgrind to help on that? We had some symptoms similar
>>> to this and also came to the conclusion that probably something is
>>> overwriting the structures used by fast malloc, but couldn't find
>>> anything with valgrind. Overwriting in an area that has bee reserved
>>> is not an error vangrind finds, at least not with any options that I
>>> know.
> 
> I haven't received your reply before. To capture this bug, you have to
> disable fastmalloc, and use the internal (trackable) memory allocator
> replacement of valgrind.
> 
> Run "build-webkit --system-malloc"
> 
> This will redirect all allocations to the system malloc.

In addition to valgrind, try running the test under guard malloc on Mac OS X 
with system malloc enabled.   See "man libgmalloc":



Dave

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

Re: [webkit-dev] Random inspector crasher?

[David Kilzer]

On Dec 23, 2010, at 6:02 AM, Carl Lobo wrote:

> I'm not very sure if this is relevant but here goes:
> I'm working on a javascript hosting framework (it's open source:
> https://github.com/directi/webkit_titanium/tree/webkit_clean).
> I'd pulled webkit git a couple of weeks back and then again a few
> hours ago and I get apparently random crashes in the inspector after I
> pause the javascript debugger and then resume. Sometimes it happens
> while I'm stepping through the JS code - but it always happens within
> a few minutes of a JS resume and pretty much randomly. If I don't
> pause the debugger there's no crash even if the inspector is open.
> The stack dump I see in Visual Studio is fairly consistent and doesn't
> include any of our code (except the entry point). I've been trying to
> create some script which reproduces it so I can file a proper bug
> report but I haven't had much luck with that.

Please file a bug report and attach the crash logs to it.  Thanks!

Dave


> Since seeing this email I've been saving a few VS2005 stacks in case
> it is of any help. I'm attaching 3 of them that are significantly
> different (the first 9 or so frames are always consistent).
> There are no assertion failures except if I expand a Dojo Closure
> object in the inspector when the debugger is paused.
> I'm using a debug build of the Cairo port for testing.
> I hope this helps/would be glad to help any further.
> 
> Regards,
> Carl
> 
> PS. The 3 attachments are about 27k so I'm not sure if the mailing
> list will scrub them.
> 
> 


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

Re: [webkit-dev] WebCore has moved: How to avoid merge conflicts

[David Kilzer]

For git, I'm assuming the following works:

Local changes:
1. git stash save "WIP"
2. git pull --rebase origin   (or git svn rebase)
3. git stash pop

Branches:
1. git checkout branchname
2. git rebase master

However, it would be interesting to know if "diff.renames=true" or if 
"diff.renames=copy" is required, or if "diff.renameLimit" needs to be set.

Dave


On Jan 8, 2011, at 9:44 AM, Dimitri Glazkov wrote:

> Thanks for your hard work, Adam!
> 
> I tried this morning to follow your steps. It worked great, except
> there were a few .orig files left after webkit-patch had run. I
> removed them by hand and was on my way.
> 
> :DG<
> 
> On Sat, Jan 8, 2011 at 2:47 AM, Adam Barth  wrote:
>> As of r75314, WebCore is now located in Source/WebCore.
>> If you have outstanding patches to WebCore, here's what you can
>> do to avoid merge conflicts:
>> 
>> 1) *BEFORE* updating past r75314, create a patch for your change,
>> either with svn-create-patch or by uploading your patch to
>> bugs.webkit.org with webkit-patch.
>> 
>> 2) Clean your working copy.  I recommend using "webkit-patch clean",
>> but you can also use svn-unapply, "svn revert", "git reset", or
>> whatever you're most confortable with.
>> 
>> 3) Update to top-of-tree.
>> 
>> 4) Apply your patch using svn-apply or "webkit-patch
>> apply-attachment".  As of r75315, svn-apply is smart enough to
>> magically apply the WebCore parts of your patch to
>> Source/WebCore.
>> 
>> Please let me know if you have any merge trouble.  Hopefully we've got
>> things set up so that the move is relatively painless.  Thanks again
>> for your patience.
>> 
>> Adam
>> ___
>> 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] coding style and comments

[David Kilzer]

On Jan 28, 2011, at 9:36 AM, Peter Kasting wrote:

> On Thu, Jan 27, 2011 at 4:27 PM, Simon Fraser  wrote:
> I think we have a distinct lack of comments that help novices to understand 
> the code. I feel that we almost have a "privileged few" mentality in some 
> code; if you can't figure it out by reading the code, then you shouldn't be 
> messing with it.
> 
> Indeed.  This sets a high barrier to entry when trying to learn about any 
> nontrivial subsystem.
> 
> Even when functions are kept brief and well-named, local simplicity does not 
> eliminate global complexity; in fact it can mask it, making the system appear 
> saner than it really is.  In this sense, I disagree that "self-documenting" 
> code is possible on a large scale (even though I am certainly a fan of making 
> the small-scale units concise, clear, etc.).
> 
> Back when we were writing the initial Chromium port, Brett Wilson and I had 
> to rewrite the Image subsystem three separate times, each time because we 
> realized we'd gotten the ownership semantics wrong and thought we now 
> understood things better.  In this case, a simple function that merely 
> allocates an object is deceptively self-documenting, because it's clear what 
> it does in a local sense, but not in the larger picture of how it fits into 
> the rest of the codebase.
> 
> No one is suggesting that silly comments like "for (int i = 0; i < 10; ++i)  
> // Count to 10." are a good thing, but I have never had any reviewer 
> objections to adding more detailed comments about subtle bits.  At the very 
> least I agree with Simon's suggestion of class-level comments, especially 
> w.r.t. ownership.

An interesting case study would be the (still ongoing?) refactoring of the 
loader code over the past few months (thanks to Adam Barth and others).   Is it 
easier to understand now than before the refactoring started?  How many 
comments were added in the process (FIXMEs notwithstanding)?

Dave

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

Re: [webkit-dev] Some compile time data

[David Kilzer]

On Apr 25, 2011, at 4:59 PM, Stephanie Lewis wrote:

> One point brought up during the compile time discussion today was that if you 
> pulled once a day, you were likely to have rebuild the world.  I thought it 
> would be interesting to see which files were contributing to rebuilding the 
> world the most often.
> 
> Using the data provided by Mihai at 
> http://persistent.info/webkit/tools/buildbot/ I wrote a script to find all of 
> the revisions that took ~2x the average time to compile.  Then I matched that 
> up with the file list from svn log to get an idea of which files are 
> triggering world builds the most often (or at least recently).
> 
> Of the 500 revisions 152 spiked compile time.
> 
> Here are the most common changed files, full data attached.  
> 
> 12/trunk/Source/WebCore/bindings/scripts/CodeGeneratorJS.pm
> 12/trunk/Source/WebCore/bindings/js/JSDOMBinding.h
> 10/trunk/Source/WebCore/WebCore.exp.in

Changing WebCore.exp.in should only require relinking WebCore, not recompiling 
it, although linking WebCore takes a non-trivial amount of time.  (The 
WebCoreExportGenerator project will get recompiled, but that's generally 
negligible compared to WebCore itself.)

Dave

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

Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.

[David Kilzer]

Hi Pavel,

You need to send the contents of the blog post via email.  Not everyone can 
read it (even after logging in).

Dave


On Apr 29, 2011, at 11:44 AM, Pavel Feldman wrote:

> Hi guys,
> 
> I started drafting the blog post "Remote Debugging with Web Inspector": 
> http://www.webkit.org/blog/?p=1620&preview=true.
> 
> I'd like to cover following topics there:
> 
> - ability to use Web Inspector front-end with remote / embedded devices
> - ability to implement alternate front-ends for IDEs
> - share the update on the protocol work progress
> 
> Calling for the early feedback.
> 
> Thanks
> Pavel
> 
> On Mon, Aug 9, 2010 at 11:48 PM, Pavel Feldman  wrote:
> Hi guys,
> 
> As some of you know, we are working on a remote debugging feature in Web 
> Inspector. There are many good reasons behind the project including the 
> following:
> 
> - Debugging WebKit on embedded devices
> - Shaping up a good protocol for ourselves
> - Introducing external SDKs on top of the protocol for IDE integrations and 
> alternate front-ends
> 
> We've had serialized interaction with the out-of-process inspector for quite 
> a while in Chromium. We were upstreaming it into WebKit and have reached an 
> important milestone recently: all the interaction between the inspected page 
> and inspector is entirely serialized on the WebKit level. All the embedder 
> needs to do is to implement a socket that would serve the inspector front-end 
> files and provide our messaging with appropriate transport.
> 
> Now this socket is likely to be platform-specific, implemented on the WebKit 
> and/or host browser levels. It also makes more sense to implement socket on 
> mobile platforms first. However, we've done a proof-of-concept implementation 
> in Chromium and it is now in a demoable state! See the screencast at 
> http://screencast.com/t/YTI2OTY4YTEt. It has Chromium nightly to the left + 
> WebKit nightly to the right. WebKit nightly connects remotely to Chromium 
> over HTTP on the port 9222 and does remote debugging including DOM 
> inspection, breakpoints and such. The communication is established by means 
> of a WebSocket. The interesting thing about the implementation is that 
> inspector front-end is fetched from the host browser, so that there is no 
> mess with protocol versioning and no need in exposing the interaction 
> protocol any time soon.
> 
> So I made the demo and it looked cool. I thought maybe we do a blog post on 
> it. The blog post would draw attention to the Web Inspector and its progress, 
> share the remote debugging vision with the interested parties and would 
> simply look cool. Front-end is working as a pure HTML5 application (obviously 
> full of WebKit-specific styles, but still) which is impressive. Now the 
> project is nowhere complete in terms of finalizing the message format and the 
> protocol itself, but there is no intention to expose it right now. We'd like 
> to let it live with fetchable front-end and mature before we expose the 
> protocol and commit to any level of interface support.
> 
> What do you think, is it ready for a blog post?
> 
> Thanks
> Pavel
> 
> ___
> 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] Chromium Mac moving to Skia

[David Kilzer]

On Aug 18, 2011, at 12:24 PM, Adam Barth wrote:

> Moving the chromium-mac result directories caused more of a disruption
> that I expected in that it apparently broke the git WebKit mirror.
> I'd like to apologize for the disruption.  We've done SVN server-side
> moves before, so I'm not entirely sure why this one caused a problem.
> If any git experts understand what went wrong and can tell me how to
> avoid this problem in the future, I would be very appreciative.
> 
> The only other large single operation in this process is when we
> delete the CG results.  Hopefully that won't trigger the same issue.

I'm not sure of the root cause of the failure.

We updated the installed version of git, ran "git svn revert -r 93166" and then 
ran "git svn fetch" manually to fix the repository.

Dave

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

[webkit-dev] Using C++ constant pointers (type_name * const) in WebKit

[David Kilzer]

In a discussion on Bug 71921, Antti, Darin Adler and I started a discussion 
about using C++ constant pointers in WebKit.  Does the WebKit community have a 
consensus opinion on the matter?

* Pros
  - Documents use of variable.
  - Prevents misuse of variable in a later patch (by a different author) 
through enforcement of pointer const-ness.
  - May help compiler optimize code.  (We weren't sure whether modern compilers 
do this on their own or not.)

* Cons
  - Darin Adler doesn't ever recall fixing a bug in WebKit where a constant 
pointer would have helped.
  - Slightly more verbose syntax for constant pointers to a constant string 
(const char * const pointer;) or even a constant pointer to a mutable string 
(char * const pointer;).

Dave

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

Re: [webkit-dev] Using C++ constant local variables in WebKit

[David Kilzer]

On Nov 29, 2011, at 6:44 PM, Ryosuke Niwa wrote:

> On Tue, Nov 29, 2011 at 6:42 PM, Ryosuke Niwa  wrote: 
>>   - Prevents misuse of variable in a later patch (by a different author) 
>> through enforcement of const-ness.
> 
> Prevents one specific type of misuse: Setting the variable to another value. 
> And that may not be misuse despite the fact that the original author didn’t 
> plan on changing it.
> 
> Right, but it tells us the intent of the author, and appears to be useful 
> even if the variable started with prefixes like "old", "original", and 
> "previous".
> 
> I'll add that I'd much prefer seeing a const in front of a local variable 
> over seeing a comment like "This variable shouldn't be modified".


Thanks for the feedback everyone.  In retrospect, I see that my original 
question was too broad and too general.

What I (and Antti) really wanted to ask was whether it's okay to use const 
pointers on a case-by-case basis without making it a project-wide rule.

And this is the specific case I'm talking about:

diff --git a/Source/WebCore/platform/KURL.cpp b/Source/WebCore/platform/KURL.cpp
index e752bb8..cb033bd 100644
--- a/Source/WebCore/platform/KURL.cpp
+++ b/Source/WebCore/platform/KURL.cpp
@@ -486,7 +486,7 @@ void KURL::init(const KURL& base, const String& relative, 
const TextEncoding& en
 parseBuffer.resize(bufferSize);
 
 char* bufferPos = parseBuffer.data();
-char* bufferStart = bufferPos;
+char* const bufferStart = bufferPos;
 
 // first copy everything before the path from the base
 unsigned baseLength = base.m_string.length();

But of course I couldn't stop there because there were other pointers that 
could be const in this method, so I ended up with:

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

Dave

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

Re: [webkit-dev] new API for offline web applications

[David Kilzer]

The abort() method is defined here:  


There is no abort() method defined in 
Source/WebCore/loader/appcache/DOMApplicationCache.idl.

Please file a bug and attach a patch for review.  See:  


Thanks!

Dave


On Jan 7, 2012, at 7:04 AM, huangxueqing wrote:

> hi all:
>The latest html5 specification add a API "applicationCache.abort()" for 
> offline web applications. I had implement offline web app for our browser in 
> main process this month except this interface since it need to make some 
> modifications in WebCore.
>I want to know whether any guys had planed to implement it? If not and 
> this feature was necessary, maybe i will file a bug and implement this api in 
> next month.
>thanks.
> 
> huangxueqing
> Baidu, Inc.
> ___
> 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] new API for offline web applications

[David Kilzer]

How did you run the layout tests?  The run-webkit-tests script should take care 
of starting the Apache web server for you with all the configuration options 
set.  This is usually how you run just the http tests for a debug build (after 
running the build-webkit script):

./Tools/Scripts/run-webkit-tests --debug http

Do the same tests pass without your changes?  That would be the first thing to 
check.

You should also write at least one layout test that tests the new abort() 
method.  See Step 4 here:  

Dave


On Jan 10, 2012, at 6:46 AM, huangxueqing wrote:

> Hi Dave:
>I have implemented abort(), but some of result of layout test in 
> Layout/http/tests/appcache was failed. And i copy appcache dir into htdocs 
> dir of apache raise failure again. I think due to some configuration 
> problems.  Should i configure something to correct it?
> thanks.
> 
> huangxueqing
> 
>> The abort() method is defined here:  
>> 
> 
>> There is no abort() method defined in 
>> Source/WebCore/loader/appcache/DOMApplicationCache.idl.
> 
>> Please file a bug and attach a patch for review.  See:  
>> 
> 
>> Thanks!
> 
>> Dave
> 
> 
> On Jan 7, 2012, at 7:04 AM, huangxueqing wrote:
> 
>>> hi all:
>>>   The latest html5 specification add a API "applicationCache.abort()" for 
>>> offline web applications. I had implement offline web app for our browser 
>>> in main process this month except this interface since it need to make some 
>>> modifications in WebCore.
>>>   I want to know whether any guys had planed to implement it? If not and 
>>> this feature was necessary, maybe i will file a bug and implement this api 
>>> in next month.
>>>   thanks.
>>> 
>>> huangxueqing
>>> Baidu, Inc.
>>> ___
>>> 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] git.webkit.org is offline

[David Kilzer]

Bill is aware of the issue and is working on it right now.

Dave


On Feb 15, 2012, at 6:38 AM, Osztrogonac Csaba wrote:

> Hi,
> 
> It seems git.webkit.org is offline.
> Could you check what happened?
> 
> br,
> Ossy
> ___
> 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] webkit

[David Kilzer]

This account has been unsubscribed.

Dave


On Feb 25, 2012, at 6:57 PM, Eric Seidel wrote:

> Please ban this spammer.
> 
> On Sat, Feb 25, 2012 at 1:27 PM, Tyler Cumberton  wrote:
>> I have a question : webkit site
>> 
>> --
>> -Tyler.
>> 
>> ___
>> 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] 48459: Glyphs in vertical text tests are rotated 90 degrees clockwise on Windows

[David Kilzer]

WebKitSystemInterface is owned by Apple.

I would implement the fix without assuming that 
wkGetVerticalGlyphsForCharacters is available for Windows.

Dave


On Feb 26, 2012, at 4:46 AM, Koji Ishii wrote:

> I found another library issue for how to get vertical alternate glyphs.
> 
> Currently,
> 
> 1. Mac version of WebCoreSystemInterface.mm defines 
> wkGetVerticalGlyphsForCharacters API
> 2. Mac uses this function and CoreText to draw vertical glyphs in 
> GlyphPageTreeNodeMac.cpp
> 3. Windows version of WebKitSystemInterface.h doesn't have the API
> 
> Should I also write this one too? I'm asking because the module is different, 
> but again I have no idea who owns WebKitSystemInterface.
> 
> The good part is that, the API probably uses not only 'vert' but also 'vrt2', 
> the latter which recent CSS spec decided not to use, so we have more precise 
> control to match to the current and coming spec.
> 
> The bad part is that, from experiences, we will probably face several issues 
> due to broken fonts. It's not too hard to write the code from OpenType specs, 
> but it might degrade stability since not all fonts conforms to OpenType spec 
> very well.
> 
> 
> Regards,
> Koji
> 
> -Original Message-
> From: webkit-dev-boun...@lists.webkit.org 
> [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Koji Ishii
> Sent: Saturday, February 25, 2012 5:50 AM
> To: Ryosuke Niwa
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] 48459: Glyphs in vertical text tests are rotated 90 
> degrees clockwise on Windows
> 
> Thank you Ryosuke for the prompt reply.
> 
>>> 1. Bring the CTFontGetVerticalTranslationsForGlyphs API to WebKitLibraries.
>>> 2. Use other libraries such as FreeType[2] to read related OpenType tables.
>>> 3. Read raw tables using GetFontData Win32 API and parse vhea/vorg/vmtx 
>>> tables etc.
>> 
>> Option 3 seems most desirable since it doesn't introduce new dependencies. 
> 
> Okay...I was afraid of that, because then the patch becomes larger and it 
> might make review harder. But if that's preferable than introducing new 
> dependencies, I can look into that.
> 
> I checked other platforms quickly. Without knowing much of them, from the 
> submitted patches, APIs of Qt[1] and Gtk[2] look like similar to the one on 
> OS X, but it wasn't clear to me if the patches support "upright" for non-CJK 
> letters properly. Chromium Linux[3] doesn't have a patch yet, and Chromium 
> Windows[4] patch has the same issue (uses @-font API.)
> 
> So guess is that if I were to write a function that calculates vertical 
> translations from OpenType tables, it could be shared among some platforms.
> 
> I was thinking to put it into platform/graphics/win/OpenTypeUtilities.cpp, 
> but should I put it into somewhere else?
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=51584
> [2] https://bugs.webkit.org/show_bug.cgi?id=50619
> [3] https://bugs.webkit.org/show_bug.cgi?id=69282
> [4] https://bugs.webkit.org/show_bug.cgi?id=51450
> 
> -
> From: ryosuke.n...@gmail.com [mailto:ryosuke.n...@gmail.com] On Behalf Of 
> Ryosuke Niwa
> Sent: Saturday, February 25, 2012 5:20 AM
> To: Koji Ishii
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] 48459: Glyphs in vertical text tests are rotated 90 
> degrees clockwise on Windows
> 
> On Fri, Feb 24, 2012 at 12:14 PM, Koji Ishii  wrote:
> I was looking into bug 48459: "Glyphs in vertical text tests are rotated 90 
> degrees clockwise on Windows"
> https://bugs.webkit.org/show_bug.cgi?id=48459
> 
> and found that it has two issues:
> 
> 1. It does not support text-orientation[1] property as OS X does.
> 
> 2. It uses @-font, which lets Windows do a magic to rotate some code points 
> and apply 'vert' automatically. But that means WebKit has no control over the 
> glyph orientations, and therefore orientation of some code points don't match 
> to the one on OS X.
> 
> I think the correct fix for the bug is to port showGlyphsWithAdvances from 
> FontMac.mm to FontCGWin.cpp.
> 
> But I then encounter an issue that WebKitLibraries does not support 
> CTFontGetVerticalTranslationsForGlyphs API.
> 
> Since Windows doesn't have such API, possible options I can think of are:
> 
> 1. Bring the CTFontGetVerticalTranslationsForGlyphs API to WebKitLibraries.
> 2. Use other libraries such as FreeType[2] to read related OpenType tables.
> 3. Read raw tables using GetFontData Win32 API and parse vhea/vorg/vmtx 
> tables etc.
> 
> Option 3 seems most desirable since it doesn't introduce new dependencies. 
> 
> - Ryosuke
> 
> ___
> 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.

Re: [webkit-dev] spinoff from webkit-patch -g discussion

[David Kilzer]

On Feb 29, 2012, at 3:28 PM, Dirk Pranke wrote:

> In my view, I would actually rather upload the combination of
> committed + staged + unstaged changes rather than be told I have to
> commit things; in other words, I actually prefer to commit what I've
> uploaded rather than upload what I've committed.

Ah!  This explains why I use webkit-patch differently.  With many local 
branches, leaving staged/unstaged changes in the source tree would make it 
impossible to switch branches easily.  I also don't think of bugs.webkit.org as 
an ancillary source code repository (if I delete my local changes), but maybe 
that's because I'm uploading fewer patches to bugs.webkit.org.

Dave

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

Re: [webkit-dev] iOS parsing of the viewport meta tag

[David Kilzer]

On Jul 10, 2012, at 8:48 AM, Adam Barth wrote:

> Parse the viewport meta tag like iOS
> https://bugs.webkit.org/show_bug.cgi?id=72722
> 
> Is the parsing code for the viewport meta tag in iOS open source?

It's on  in ViewportArguments.cpp.

Dave

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

Re: [webkit-dev] iOS parsing of the viewport meta tag

[David Kilzer]

On Jul 10, 2012, at 9:22 AM, Adam Barth wrote:
> On Tue, Jul 10, 2012 at 9:16 AM, David Kilzer  wrote:
>> On Jul 10, 2012, at 8:48 AM, Adam Barth wrote:
>>> Parse the viewport meta tag like iOS
>>> https://bugs.webkit.org/show_bug.cgi?id=72722
>>> 
>>> Is the parsing code for the viewport meta tag in iOS open source?
>> 
>> It's on <http://opensource.apple.com/> in ViewportArguments.cpp.
> 
> Oh, I was under the mistaken impression that iOS didn't use
> ViewportArguments.cpp.

We do, but there are changes in the source file, so it's not strictly the same 
as ToT WebKit.  You'll want to use diff to see what's different.

Dave

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

[webkit-dev] 'ANGLE' component added to bugs.webkit.org

[David Kilzer]

I've added an 'ANGLE' component to bugs.webkit.org.

Dave

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

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[David Kilzer]

On Feb 8, 2013, at 1:41 PM, Adam Barth  wrote:

> Context: https://bugs.webkit.org/show_bug.cgi?id=109071
> 
> Adam Barth said:
>> It's not clear to me that running WebCore on multiple interlocked threads is 
>> a good idea.  That
>> seems like a pretty major change to WebCore's architecture.  Is that 
>> something that's up for
>> discussion?
> 
> Darin Adler said:
>> I agree that it’s not something I’d do if I was starting a project now.
>> 
>> In the iOS context, it’s fantastic for discussion as a possibly multi-year 
>> major architecture
>> change, but if we take a hard line on this, then we won’t have the iOS port 
>> in the tree for
>> years, and I think it would be good if we do. iOS WebKit has worked this way 
>> for the entire
>> history of iPhone, so it’s not a change that can be made easily.
> 
> Darin Adler also said:
>> I think where you and I may differ is on whether a good solution to the 
>> problem would be
>> valuable to the WebKit project. Is there some way I convince you of the 
>> value of fitting
>> an important existing port of WebKit into our tree in as clean as possible a 
>> way?
> 
> I don't really know how to respond to this thread.  I feel like I'm
> being offered the following choice:
> 
> 1) Give up the ability to have technical input to how WebCore works
> and simply accept all the design choices made in the iOS fork, whether
> they be good choices or bad.
> 
> 2) Keep the iOS port in an Apple-internal fork for a number of years.
> 
> I feel like I'm being asked to make this choice in the context of a
> growing trend of unilateral action by Apple in this project.  Given
> that trend, I don't see how I can choose option (1).
> 
> As much as I would like the iOS port merged into trunk, I'm not
> willing to give up having a technical say in the project.  Therefore,
> reluctantly, I'm forced to choose option (2).


The iOS port does not require re-architecting WebCore.

Bug 109071 was about coming up with a better name for a method that is 
primarily used in ASSERT()s in WebCore.  Without changing the implementation of 
that method, debug builds of WebCore on iOS assert instantly since WebCore 
execution can happen on one of two threads.

We can live with keeping the method name as "isMainThread()" and have already 
moved on to other things.

The rest of WebCore is largely unchanged for iOS, other than the usual 
port-specific code you need for a port, which will be posted for review as we 
continue to merge.

Dave

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

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[David Kilzer]

On Feb 8, 2013, at 2:52 PM, Adam Barth  wrote:

> On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer  wrote:
> 
>> The iOS port does not require re-architecting WebCore.
>> 
>> Bug 109071 was about coming up with a better name for a method that is 
>> primarily used in ASSERT()s in WebCore.  Without changing the implementation 
>> of that method, debug builds of WebCore on iOS assert instantly since 
>> WebCore execution can happen on one of two threads.
>> 
>> We can live with keeping the method name as "isMainThread()" and have 
>> already moved on to other things.
>> 
>> The rest of WebCore is largely unchanged for iOS, other than the usual 
>> port-specific code you need for a port, which will be posted for review as 
>> we continue to merge.
> 
> How do these multiple interlocked threads interact with code that uses
> thread-local storage?


The UI (main) thread and the web thread share the same thread-local storage.  
Those code changes are in 4 or 5 files in WTF.

There are also a couple of additional mutexes in WebCore for WebSQL and the DOM 
wrapper cache.

Access to WebCore itself is mediated by a coarse-grained lock (the web thread 
lock), which is taken outside of WebCore.

Dave

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

Re: [webkit-dev] Getting more buildbots green

[David Kilzer]

Please file bugs on  for each test (or group of 
tests) that you disable per platform, especially for ports that run the layout 
tests regularly (Apple's Mac and Windows, Qt, Gtk, Wx).

Dave





From: Darin Adler 
To: Holger Freyther 
Cc: webkit-dev@lists.webkit.org
Sent: Tuesday, January 27, 2009 9:14:50 AM
Subject: Re: [webkit-dev] Getting more buildbots green

On Jan 27, 2009, at 7:54 AM, Holger Freyther wrote:

> may I read this as a rs=darin?

Yes, rs=me on adding to the Skipped list to make the buildbot green!

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

Re: [webkit-dev] li with position outside combined with img float left problem

[David Kilzer]

Please file a bug on .  Thanks!

Dave




From: Magnus Rembold 
To: webkit-dev@lists.webkit.org
Sent: Thursday, February 5, 2009 11:41:58 AM
Subject: [webkit-dev] li with position outside combined with img float left 
problem


A complete description of the problem with source HTML and inline CSS together 
with images can be found here:
http://www.munterbund.de/problems/090205/li_outside_and_img_float_problem.html

My question is: this is obviously not as is should be. Do the "standards" 
require that this is displayed this way? Or is it only a part of the rendering, 
that's considered "not important"? Or will it be fixed in some way? Everybody 
that I asked told me to format  in a completely awkward way with background 
pictures and so on. This shouldn't be necessary or am I wrong?

Thanks kindly for your replys, comments or suggestions!
Best regards,
Magnus



Magnus RemboldZÜRCHER HOCHSCHULE DER KÜNSTE
Dozent ITZurich University of the Arts

Fon +41 43 446 3256Ausstellungsstrasse 60
Fax +41 43 446 4587CH-8031 Zürich
http://iad.zhdk.chSwitzerland___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Regarding Bug 23310

[David Kilzer]

It is valid and it is still open because it's "Status" is "New".

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

Dave





From: Nilesh Patil 
To: "webkit-dev@lists.webkit.org" 
Sent: Sunday, February 15, 2009 12:02:06 AM
Subject: [webkit-dev] Regarding Bug 23310

Hi

Is this bug is valid and still open?

Thanks & Regards
Niilesh
___
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] Regarding Bug 23310

[David Kilzer]

Please comment in the bug itself if you'd like to work on it; that's what the 
"Comment" field is for.

I would look at Document::completeURL() instead.  Also, please read the HTML5 
reference document for the correct algorithm to fix this issue.

Dave





From: Nilesh Patil 
Cc: "webkit-dev@lists.webkit.org" 
Sent: Sunday, February 15, 2009 3:43:38 AM
Subject: Re: [webkit-dev] Regarding Bug 23310

Hi

Thanks david !!

I am trying to fix it. What i observed till now is following. When
only '/' is encountered the url automatically is set to 'about:blank'.
I think instead of this it should point to base URL inside Document. I
am currently looking at KURL.cpp init() method.

Please comment

Thanks & Regards
Niilesh

On Sun, Feb 15, 2009 at 4:16 PM, David Kilzer  wrote:
> It is valid and it is still open because it's "Status" is "New".
> https://bugs.webkit.org/show_bug.cgi?id=23310
> Dave
>
> 
> From: Nilesh Patil 
> To: "webkit-dev@lists.webkit.org" 
> Sent: Sunday, February 15, 2009 12:02:06 AM
> Subject: [webkit-dev] Regarding Bug 23310
>
> Hi
>
> Is this bug is valid and still open?
>
> Thanks & Regards
> Niilesh
> ___
> 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] error: Cannot find icu-config. The ICU library is needed.

[David Kilzer]

Try installing the libicu package.

Dave





From: nguyen hai 
To: webkit-dev@lists.webkit.org
Sent: Sunday, February 15, 2009 11:56:25 PM
Subject: [webkit-dev] error: Cannot find icu-config. The ICU library is needed.


Hi all,

I build webkit on Fedora 9.
I typed ./autogen.sh and I got a message:

checking for icu-config... no
configure: error: Cannot find icu-config. The ICU library is needed.
[r...@localhost WebKit-r41018]# 

I am looking this error on webkt.org but I have not found any answer.
Can you help me to solve this error?
Thanks in advance!
Hai
 

 Vui vẻ chat thêm trên nhiều blog và website
Hãy thử dùng ứng dụng Pingbox online.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] checking for LIBSOUP... configure: error: Package requirements (libsoup-2.4 >= 2.23) were not met:

[David Kilzer]

The autogen.sh script wants libsoup-2.4 OR NEWER.  libsoup-2.4.1 satisfies that 
requirement, so try installing that version.

Dave





From: nguyen hai 
To: webkit-dev@lists.webkit.org
Sent: Monday, February 16, 2009 1:17:54 AM
Subject: [webkit-dev] checking for LIBSOUP... configure: error: Package 
requirements (libsoup-2.4 >= 2.23) were not met:


Hi all,
I typed ./autogen.sh but I got this message:

checking for LIBSOUP... configure: error: Package requirements (libsoup-2.4 >= 
2.23) were not met:

No package 'libsoup-2.4' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

When I looked for libsoup-2.4 , there were only libsoup-2.4.1.

Can someone help me?
thanks
Hai
 

Thị trường chứng khoán Việt Nam hot tới mức nào? Khám phá tại Yahoo! Hỏi & Đáp___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] checking for LIBSOUP... configure: error: Package requirements (libsoup-2.4 >= 2.23) were not met:

[David Kilzer]

Sorry, I was reading that libsoup-2.23 was older than libsoup-2.4.  It looks 
like configure.ac is not comparing the versions correctly.  Try making this 
change (changing "libsoup-2.4" to just "libsoup" in configure.ac) and rerunning 
autogen.sh:

diff --git a/configure.ac b/configure.ac
index 6ac6f8b..75d986f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -637,7 +637,7 @@ fi
 
 if test "$with_http_backend" = "soup"; then
PKG_CHECK_MODULES([LIBSOUP],
- [libsoup-2.4 >= $LIBSOUP_REQUIRED_VERSION])
+ [libsoup >= $LIBSOUP_REQUIRED_VERSION])
AC_SUBST([LIBSOUP_CFLAGS])
AC_SUBST([LIBSOUP_LIBS])
 fi

Note that $LIBSOUP_REQUIRED_VERSION is set to 2.23 anyway.

Dave




________
From: nguyen hai 
To: David Kilzer 
Sent: Monday, February 16, 2009 7:05:40 AM
Subject: Re: [webkit-dev] checking for LIBSOUP... configure: error: Package 
requirements (libsoup-2.4 >= 2.23) were not met:


Hi David,
Thank you much for your help.
I tried to install libsoup-2.4 but not avaible.
I run on Fedora. I tyed as following:

yum search libsoup-2.4  (first I looked for libsoup-2.4)
yum install libsoup-2.4  

but I got a message:

not matched
nothing to do

Once I installed libsoup-2.4.1, the same error appeared : hecking for 
LIBSOUP... configure: error: Package requirements (libsoup-2.4 >= 2.23) were 
not met

It seems that "autogen.sh" want exactly libsoup-2.4 ( not 2.4.2 or other).
But I can't find libsoup-2.4.
I spent much time for this. It sounds bad.
Hai 

  

--- Thứ 2, 16/02/09, David Kilzer  đã viết:

> Từ: David Kilzer 
> Chủ đề: Re: [webkit-dev] checking for LIBSOUP... configure: error: Package 
> requirements (libsoup-2.4 >= 2.23) were not met:
> Đến: deuxliq...@yahoo.com
> Cc: webkit-dev@lists.webkit.org
> Ngày: Thứ Hai, 16 tháng 2, 2009, 20:43
> The autogen.sh script wants libsoup-2.4 OR NEWER. 
> libsoup-2.4.1 satisfies that requirement, so try installing
> that version.
> 
> Dave
> 
> 
> 
> 
> 
> From: nguyen hai 
> To: webkit-dev@lists.webkit.org
> Sent: Monday, February 16, 2009 1:17:54 AM
> Subject: [webkit-dev] checking for LIBSOUP... configure:
> error: Package requirements (libsoup-2.4 >= 2.23) were
> not met:
> 
> 
> Hi all,
> I typed ./autogen.sh but I got this message:
> 
> checking for LIBSOUP... configure: error: Package
> requirements (libsoup-2.4 >= 2.23) were not met:
> 
> No package 'libsoup-2.4' found
> 
> Consider adjusting the PKG_CONFIG_PATH environment variable
> if you
> installed software in a non-standard prefix.
> 
> When I looked for libsoup-2.4 , there were only
> libsoup-2.4.1.
> 
> Can someone help me?
> thanks
> Hai
>  
> 
> Thị trường chứng khoán Việt Nam hot tới mức
> nào? Khám phá tại Yahoo! Hỏi & Đáp


  Đặt ngay địa chỉ email mới!
Lấy ngay địa chỉ email bạn từng muốn có trước khi có người khác nhanh tay hơn!
http://mail.promotions.yahoo.com/newdomains/vn/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Contributing to the documentation Wiki?

[David Kilzer]

Hi Frank,

I believe it is:

1. Create an account (on macosforge.org; the accounts are shared with 
webkit.org).
2. Edit the wiki.  

Dave





From: Frank Zerangue 
To: Webkit Development List 
Sent: Monday, February 16, 2009 10:19:48 AM
Subject: [webkit-dev] Contributing to the documentation Wiki?

What is the process for contributing to the documentation wiki?

Frank
___
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] checking for LIBSOUP... configure: error: Package requirements (libsoup-2.4 >= 2.23) were not met:

[David Kilzer]

That's a horrible package name.  :(   Is "2.4" is the "so" version or what?

Do all Linux (or *NIX) distributions name libsoup that way?  It doesn't appear 
that Debian packages it this way:

http://packages.debian.org/search?keywords=libsoup

Is libsoup-2.4 older or newer than libsoup-2.23?

Dave





From: Christian Dywan 
To: webkit-dev@lists.webkit.org
Sent: Monday, February 16, 2009 10:38:59 AM
Subject: Re: [webkit-dev] checking for LIBSOUP... configure: error: Package 
requirements (libsoup-2.4 >= 2.23) were not met:

Am Mon, 16 Feb 2009 09:28:53 -0800 (PST)
schrieb David Kilzer :

> Sorry, I was reading that libsoup-2.23 was older than libsoup-2.4.
> It looks like configure.ac is not comparing the versions correctly.
> Try making this change (changing "libsoup-2.4" to just "libsoup" in
> configure.ac) and rerunning autogen.sh:
> 
> diff --git a/configure.ac b/configure.ac
> index 6ac6f8b..75d986f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -637,7 +637,7 @@ fi
>  
>  if test "$with_http_backend" = "soup"; then
> PKG_CHECK_MODULES([LIBSOUP],
> - [libsoup-2.4 >= $LIBSOUP_REQUIRED_VERSION])
> + [libsoup >= $LIBSOUP_REQUIRED_VERSION])
> AC_SUBST([LIBSOUP_CFLAGS])
> AC_SUBST([LIBSOUP_LIBS])
>  fi
> 
> Note that $LIBSOUP_REQUIRED_VERSION is set to 2.23 anyway.

Hey,

this is actually wrong I'm afraid. The API name is 'libsoup-2.4' which
is arguably a bad idea on the side of the library author. The actual
version is something else, in this case 2.23. Pay attention to the
actual release version when looking for a more recent package.

ciao,
Christian
___
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] Queries on Bug: 23310

[David Kilzer]

I don't think modifying KURL to parse JavaScript syntax is the correct approach.

I have a fix for this in my local tree.  I will try to post a patch for it 
today for review.

Dave





From: Vikram Hegde 
To: webkit-dev@lists.webkit.org
Sent: Monday, February 16, 2009 9:50:06 PM
Subject: [webkit-dev] Queries on Bug: 23310


Hi ,
 
The Bug 23310 is Setting an absolute path (/abs) on an  with no src 
doesn't resolve the URL properly.
 
So I have analysed the bug,and here are my comments.Kindly let me know i m on 
the right track of solving the bug.
 
Analysis:
 
The kurl.cpp is the actual place where the url gets resolved and is being 
parsed.So the parameter for the init function in kurl.cpp should have the 
complete format i.e. javascript:document.location.replace('/') instead the 
parameter which is being parsed contains only /.This is the reason why the 
parsing of the url is not done properly and invalidate function gets called 
which redirects the page to reflect nothing.
 
In short i think the scr which the kurl should parse should be the entire 
string (javascript:document.location.replace('/') ) . This is the reason i feel 
the parsing of url is not done propely.
 
Kindly suggest whether i m in the right track or not and the possible solutions 
for the problem.
 
Thanks & Regards,
Vikram
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Thank you very much! I edited configure.ac and...

[David Kilzer]

Hi Hai,

I'm glad I was able to help you get past this particular build error, but I've 
never built the Gtk+ or Qt builds of WebKit before, so I can't help you any 
further.  Please continue using the webkit-dev mailing list or the #webkit IRC 
channel on irc.freenode.net for additional questions.

Also, I would file a bug on <https://bugs.webkit.org/> about the issue with 
identifying the supported version of libsoup in configure.ac.  It seems to me 
that there may need to be multiple checks for the correct version of the 
libsoup package based on your Linux distribution (or *NIX platform) due to the 
inconsistent package names for this library.

Dave





From: nguyen hai 
To: David Kilzer 
Sent: Monday, February 16, 2009 7:01:24 PM
Subject: Thank you very much! I edited configure.ac and...


Hi Dave,
I opened confugure.ac, I saw some scripts as below:

Script_1:
 # optional modules
LIBCURL_REQUIRED_VERSION=7.15
LIBSOUP_REQUIRED_VERSION=2.23
LIBXSLT_REQUIRED_VERSION=1.1.7
SQLITE_REQUIRED_VERSION=3.0
GSTREAMER_REQUIRED_VERSION=0.10

and Script_2

if test "$with_http_backend" = "soup"; then
   PKG_CHECK_MODULES([LIBSOUP],
 [libsoup-2.4 >= $LIBSOUP_REQUIRED_VERSION])
   AC_SUBST([LIBSOUP_CFLAGS])
   AC_SUBST([LIBSOUP_LIBS])
fi

firstly, I changed "libsoup-2.4" in Script_2 to "libsoup" but I got an error 
that meant that  it could not find libsoup.
Then, I changed LIBSOUP_REQUIRED_VERSION to 2.4 (that means 
LIBSOUP_REQUIRED_VERSION =2.4) . Then I typed autogen.sh, what great, it run 
well.

At this moment, I am running "make". It maybe take 3 hours for making.
I don't know if I did right or wrong. 
If you don't mind , I suppose that "make" shell will success. What will I do 
for the next? I mean that How many next steps to have a web browser. I am 
really very new to webkit and web browser. 
thank you again
Hai
--- Thứ 3, 17/02/09, David Kilzer  đã viết:

Từ: David Kilzer 
Chủ đề: Re: [webkit-dev] checking for LIBSOUP... configure: error: Package 
requirements (libsoup-2.4 >= 2.23) were not met:
Đến: deuxliq...@yahoo.com
Cc: webkit-dev@lists.webkit.org
Ngày: Thứ Ba, 17 tháng 2, 2009, 0:28


Sorry, I was reading that libsoup-2.23 was older than libsoup-2.4.  It looks 
like configure.ac is not comparing the versions correctly.  Try making this 
change (changing "libsoup-2.4" to just "libsoup" in configure.ac) and rerunning 
autogen.sh:

diff --git a/configure.ac b/configure.ac
index 6ac6f8b..75d986f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -637,7 +637,7 @@ fi
 
 if test "$with_http_backend" = "soup"; then
PKG_CHECK_MODULES([LIBSOUP],
- [libsoup-2.4 >= $LIBSOUP_REQUIRED_VERSION])
+ [libsoup >= $LIBSOUP_REQUIRED_VERSION])
AC_SUBST([LIBSOUP_CFLAGS])
AC_SUBST([LIBSOUP_LIBS])
 fi

Note that $LIBSOUP_REQUIRED_VERSION is set to 2.23 anyway.

Dave





From: nguyen hai 
To: David Kilzer 
Sent: Monday, February 16, 2009 7:05:40 AM
Subject: Re: [webkit-dev] checking for LIBSOUP... configure: error: Package 
requirements (libsoup-2.4 >= 2.23) were not met:


Hi David,
Thank you much for your help.
I tried to install libsoup-2.4 but not avaible.
I run on Fedora. I tyed as following:

yum search libsoup-2.4  (first I looked for libsoup-2.4)
yum install libsoup-2.4  

but I got a message:

not matched
nothing to do

Once I installed libsoup-2.4.1, the same error appeared : hecking for 
LIBSOUP... configure: error: Package requirements (libsoup-2.4 >= 2.23) were 
not met

It seems that "autogen.sh" want exactly libsoup-2.4 ( not 2.4.2 or other).
But I can't find libsoup-2.4.
I spent much time for this. It sounds bad.
Hai 

  

--- Thứ 2, 16/02/09, David Kilzer  đã viết:

> Từ: David Kilzer 
> Chủ đề: Re: [webkit-dev] checking for LIBSOUP... configure: error: Package 
> requirements (libsoup-2.4 >= 2.23) were not met:
> Đến: deuxliq...@yahoo.com
> Cc: webkit-dev@lists.webkit.org
> Ngày: Thứ Hai, 16 tháng 2, 2009, 20:43
> The autogen.sh script wants libsoup-2.4 OR NEWER. 
> libsoup-2.4.1 satisfies that requirement, so try installing
> that version.
> 
> Dave
> 
> 
> 
> 
> 
> From: nguyen hai 
> To: webkit-dev@lists.webkit.org
> Sent: Monday, February 16, 2009 1:17:54 AM
> Subject: [webkit-dev] checking for LIBSOUP... configure:
> error: Package requirements (libsoup-2.4 >= 2.23) were
> not met:
> 
> 
> Hi all,
> I typed ./autogen.sh but I got this message:
> 
> checking for LIBSOUP... configure: error: Package
> requirements (libsoup-2.4 >= 2.23) were not met:
> 
> No package 'libsoup-2.4' found
> 
> Consider adjusting the PKG_CONFIG_PATH environment variable
> i

Re: [webkit-dev] checking for LIBSOUP... configure: error: Package requirements (libsoup-2.4 >= 2.23) were not met:

[David Kilzer]

Dave, may I suggest that lib version requirements to consider Fedora9? I mean 
can we loose the requirements, or use OS specific one so FC9  just needs 2.4?

Sure.  I'd suggest filing a bug on  with a patch for 
review.  I don't use the Linux port of WebKit--was just trying to help people 
get through their local build errors.  Those who using 
autoconf/autogen.sh/configure.ac will need to review any changes before they're 
committed anyway.

Dave





From: x yz 
To: deuxliq...@yahoo.com; Bo Yang 
Cc: webkit-dev@lists.webkit.org
Sent: Tuesday, February 17, 2009 10:40:54 AM
Subject: Re: [webkit-dev] checking for LIBSOUP... configure: error: Package 
requirements (libsoup-2.4 >= 2.23) were not met:

libsoup 2.23 is newer than 2.4. On Fedora9 only 2.4 is available, on FC10 2.24 
is available.
You need to changed the required version 2.23 in configure.ac to 2.4 then you 
can build. I have not completed the build yet.

FC has older libs than ubuntu or so, when I try to compile openembbed flash I 
got lots of lib problem.
Dave, may I suggest that lib version requirements to consider Fedora9? I mean 
can we loose the requirements, or use OS specific one so FC9  just needs 2.4?
rgds
joe


--- On Tue, 2/17/09, Bo Yang  wrote:

> From: Bo Yang 
> Subject: Re: [webkit-dev] checking for LIBSOUP... configure: error: Package 
> requirements (libsoup-2.4 >= 2.23) were not met:
> To: deuxliq...@yahoo.com
> Cc: webkit-dev@lists.webkit.org
> Date: Tuesday, February 17, 2009, 4:31 PM
> I have came across this error, too.
> The problem is , webkit need is 2.24 or later. But the
> libsoup 2.4 is not
> suitable, and webkit can't build with it because
> libsoup 2.4 miss the
> SoupCookieJar and something which exist in 2.24.
> 
> Install libsoup 2.24 , it will work!
> 
> Regards!
> Bo
> ___
> 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] Problems with JavaScript bison parser

[David Kilzer]

Which revision of WebKit are you using (or closest to)?

Which version of bison (bison --version) are you using to generate the grammar?

The incorrectly-parsed HTML works fine in Safari on Mac OS X for me.

Dave





From: Javed Rabbani 
To: webkit-dev@lists.webkit.org
Sent: Thursday, February 19, 2009 5:41:10 AM
Subject: [webkit-dev] Problems with JavaScript bison parser

 
Hello
everyone,
 
I am
working on a WebKit port for some platform and facing an issue with working of
JavaScript bison parser in "Grammar.cpp". If I execute the following HTML file,
everything is parsed without error:
 





 
However, as
soon I specify the same functionality through a separate function; I run into
trouble as the parser inside Grammar.cpp fails with return value of 1. Here is
the source for the HTML file:
 



function
OnClickHandler()
{
document.write('Hello World');
}




 
I have
figured out so far that parsing fails as it does not get all the tokens. It
only retrieves the first token and interprets it as "FUNCTION (269)". 
Afterwards,
the execution terminates and no further tokens are read by the parser. Ideally
it should continue with tokens for OPENBRACE (314), IDENT(317), STRING(318),
CLOSEBRACE(315) etc. I am not sure what is going wrong to this bison parser? If
anyone has faced somewhat similar issues; any help or suggestion is greatly
appreciated Thanks.
 
Regards,
J R Shah ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] An old dragging problem

[David Kilzer]

Hi Eric,

If you're referring to , please do file a bug on 
 and attach test cases (unless you're going to host 
the test cases indefinitely).

Also, please add the "InRadar" keyword to the bug and note 
"" in a comment.

Thanks!

Dave





From: Eric Gorr 
To: webkit-dev@lists.webkit.org
Sent: Tuesday, February 24, 2009 10:11:42 AM
Subject: [webkit-dev] An old dragging problem

A few years ago I was playing around with dragging text & images. from the web 
browser to elsewhere. A couple of old threads related to this can be found at:

http://lists.apple.com/archives/webkitsdk-dev/2006/Oct/msg00064.html
http://bytes.com/groups/javascript/550644-javascript-drag-drop

My test site can be found at:

  http://ericgorr.net/safaritest.html

Since I just tried the latest Safari 4 beta and found that it is still a 
problem, I was wondering if it is indeed still a bug or of things are working 
the way one would expect them to.

Years ago, it was confirmed as a bug and apparently fixed in a later version of 
webkit, but since that time (Safari 2.x), things have actually gotten worse and 
what used to work in Safari no longer does. (I also checked the latest nightly 
build of webkit.)

While I have reported the bug at bugreport.apple.com, I can report it again at 
https://bugs.webkit.org/ if someone thought it was useful to do so.


___
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] Build error

[David Kilzer]

In this case,  would mean one of:  "JavaScriptCore", "WebCore" or 
"WebKit".

And  would mean one of:  "Release" or "Debug".

Dave





From: bryon smith 
To: webkit-dev@lists.webkit.org
Sent: Tuesday, February 24, 2009 11:34:40 PM
Subject: [webkit-dev] Build error


Ever time I try to build I get the error,
 
Please enshure you have run webkit/webkittools/scripts/update-webkit to 
epenedencies.
 
You can view build error by checking the BuildL.html file located at:
/home/showplace/webkit/webkitbuild/obj//.
 
I'm lost on /. What does it mean ?
 
I looked all over for a config. I did find more then one buildlog.html
 
 
I'm on windows vista, if that helps. ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How to build a webkit release build

[David Kilzer]

You need to check out "trunk" from Subversion first (to get all of the "other" 
files):

$ svn co http://svn.webkit.org/repository/webkit/trunk WebKit

Then update each of the JavaScriptCore, WebCore, and WebKit subdirectories to 
the Subversion branch you're interested in:

$ cd WebKit/JavaScriptCore
$ svn switch 
"http://svn.webkit.org/repository/webkit/releases/Apple/Safari%204%20Public%20Beta/JavaScriptCore";
$ cd ../WebCore
$ svn switch 
"http://svn.webkit.org/repository/webkit/releases/Apple/Safari%204%20Public%20Beta/WebCore";
$ cd ../WebKit
$ svn switch 
"http://svn.webkit.org/repository/webkit/releases/Apple/Safari%204%20Public%20Beta/WebKit";

That should get you started in the right direction.

Dave





From: Meryl Silverburgh 
To: last...@yahoo.com
Cc: webkit-dev@lists.webkit.org
Sent: Tuesday, February 24, 2009 8:29:58 PM
Subject: Re: [webkit-dev] How to build a webkit release build

Thanks.

But after I svn get the release build, there are only 4 sub-directories.

$ ls
JavaScriptCoreJavaScriptGlueWebCoreWebKit

So I can't perform your steps as there is no 'autogen.sh' 'build-webkit', etc.


On Tue, Feb 24, 2009 at 7:35 PM, x yz  wrote:
> check out eveything,
> autogen.sh --pefix=
> set-webkit-configuration --release
> build-webkit --gtk
>
>
> --- On Wed, 2/25/09, Meryl Silverburgh  wrote:
>
>> From: Meryl Silverburgh 
>> Subject: [webkit-dev] How to build a webkit release build
>> To: webkit-dev@lists.webkit.org
>> Date: Wednesday, February 25, 2009, 8:50 AM
>> I read the instructions here in building Webkit trunk build.
>>
>> http://webkit.org/building/build.html
>>
>> But when I check out the 'release' build, it only
>> has 4 subdirectories
>> (different from the trunk project directories) and
>> it does not have
>> 'WebKit/WebKitTools/Scripts/build-webkit'
>>
>> http://trac.webkit.org/browser/releases/Apple/Safari%204%20Public%20Beta
>> http://trac.webkit.org/browser/trunk
>>
>> So my question is how can I build Webkit's release
>> build?
>>
>> Thank you.
>> ___
>> 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] about javaScript parse

[David Kilzer]

Change:




to:




and reload.

Dave





From: zhenghe zhang 
To: webkit-dev@lists.webkit.org
Sent: Friday, February 27, 2009 2:13:06 AM
Subject: [webkit-dev] about javaScript parse

Hi all
When you run the webpage with webkit and click the button,  there is no pop up. But if you use IE it pops up a dialog box.
I'd like to fix the code for the pop up. I've not done it yet and appreciate
any comments or help.







function alertValue()
{
  alert(text1.value)
}




Thank you
Regards 
zh

___
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] wap support schedule

[David Kilzer]

WAP support is not enabled on the Windows or Mac nightly builds on 
.  You must enable it yourself and rebuild from 
source.

Dave





From: 조정흠 
To: webkit-dev@lists.webkit.org
Sent: Monday, March 2, 2009 4:00:15 AM
Subject: [webkit-dev] wap support schedule


Hello,
 
In the previous archive, I found that someone in webkit.org(excuse me if I am 
wrong) was merging code for wap support.
He said that webkit will support WML and WCSS.
 
I tried open a wml page with current nightly builded safari on windows. But 
safari only downloaded the wml page. It doesn't seem to be able to render wml 
page yet.
 
Could I know the schedule for merging work of WML and WCSS?
 
Isn't it true that I already can make safari render wml page through some 
configuration changes of latest nightly builded safari?
 
Thank you very much for your kind answer in advance!
 
Humi
Seoul___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] wap support schedule

[David Kilzer]

Sounds like a bug.  Please file a new bug at <https://bugs.webkit.org/> about 
this issue.  Thanks!

Dave





From: 조정흠 
To: David Kilzer 
Cc: webkit-dev@lists.webkit.org
Sent: Monday, March 2, 2009 8:14:10 PM
Subject: Re: [webkit-dev] wap support schedule

Hi, Dave

Thank you for your kind answer.

I could build WML enabled Safari by enabling ENABLE_WML in WebKit, WebCore and 
in the file build-generated-files.sh under WebCoreGenerated.

But I had to block out some errornous code.

RenderObject* r = renderer();
if (r /*&& r->isEdited()*//*JJH*/) {
dispatchEventForType(eventNames().changeEvent, true, false);

// Refetch the renderer since arbitrary JS code run during onchange 
can do anything, including destroying it.
r = renderer();
//if (r)/*JJH*/
//r->setEdited(false);/*JJH*/
}

Class RenderObject doesn't have function isEdited(), setEdited(false)

I'd like to get updated information on this error code if this is corrected.

Thank you anyway.

Regards
Humi
Seoul

2009/3/2 David Kilzer 

WAP support is not enabled on the Windows or Mac nightly builds on 
<http://nightly.webkit.org/>.  You must enable it yourself and rebuild from 
source.

Dave





 From: 조정흠 
To: webkit-dev@lists.webkit.org
Sent: Monday, March 2, 2009 4:00:15 AM
Subject: [webkit-dev] wap support schedule



Hello,
 
In the previous archive, I found that someone in webkit.org(excuse me if I am 
wrong) was merging code for wap support.
He said that webkit will support WML and WCSS.
 
I tried open a wml page with current nightly builded safari on windows. But 
safari only downloaded the wml page. It doesn't seem to be able to render wml 
page yet.
 
Could I know the schedule for merging work of WML and WCSS?
 
Isn't it true that I already can make safari render wml page through some 
configuration changes of latest nightly builded safari?
 
Thank you very much for your kind answer in advance!
 
Humi
Seoul
 


-- 
조정흠
서울 동작구 신대방동 625-3 아트빌라102호
010-8473-3973
www.humi.or.kr
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] request to add SH4 platform

[David Kilzer]

Hi Simone,

Code contribution guidelines are here:

http://webkit.org/coding/contributing.html

Please open a new bug on  and post your patch there 
with its review flag set.  (Feel free to CC me on the bug.)  Note that your 
patch should also have ChangeLog entries, as explained on the webkit.org web 
site.

Looking at the two patches, I think they're fine as-is and would have no 
problem landing in the source tree.

Thanks for your contribution!

Dave





From: Simone Fiorentino 
To: webkit-dev@lists.webkit.org
Sent: Thursday, March 5, 2009 5:33:27 AM
Subject: [webkit-dev] request to add SH4 platform

Hi,
I would like to gratify you for your great work.
I'm working in porting WebKit for SH4 platform.
I had some problems related to non-aligned memory accesses as done in 
WebCore::equal(StringImpl* string, const UChar* characters, unsigned length) 
function for the SH4 platform.
My question is: can you add support in WebKit sources for SH4 platform?

In attachment you can find two little patches (against WebKit trunk) that 
introduce the SH4 platform and solves the non-aligned memory accesses (I use 
the same code as per ARM platform).

Best regards.

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

Re: [webkit-dev] four perl files hard-code the path to gcc

[David Kilzer]

I agree that the path shouldn't be hard-coded, so I filed:

Bug 24454: Path to perl should not be hard-coded
https://bugs.webkit.org/show_bug.cgi?id=24454

Salvation lies within:

Bug 392184 - Users should be allowed to delete their own account
https://bugzilla.mozilla.org/show_bug.cgi?id=392184

Dave





From: Dennis Heuer 
To: webkit-dev@lists.webkit.org
Sent: Saturday, March 7, 2009 11:42:12 PM
Subject: [webkit-dev] four perl files hard-code the path to gcc

hello

first: i refuse to use bugzilla because it doesn't let me drop or at
least close my account at a later time. take this post or not.

four of the perl files contend hard-coded paths to gcc. my gcc resides
in opt and is not detected (not even searched for). please update these
scripts with the general configure procedure. the scripts are:

WebCore/css/make-css-file-arrays.pl
WebCore/dom/make_names.pl
WebCore/bindings/scripts/IDLParser.pm
WebCore/bindings/scripts/CodeGeneratorObjC.pm

many thanks,
dennis heuer

___
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] Fwd: RSS support

[David Kilzer]

The RSS support (that you see in Safari) is not part of WebKit.

Dave





From: RamaMohanReddy B 
To: webkit-dev@lists.webkit.org
Sent: Sunday, March 8, 2009 9:40:05 PM
Subject: [webkit-dev] Fwd: RSS support

Hi,

Is RSS/Atom supported in Webkit? Is there any patch/bug how to add 
RSS support to Webkit. Please let me know. 
Thanks,
RamaMohan.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Stable tiger engine build?

[David Kilzer]

Try this command:

svn ls http://svn.webkit.org/repository/webkit/releases/Apple/

Or this URL:

http://trac.webkit.org/browser/releases/Apple/

Dave





From: Swp 
To: webkit-dev@lists.webkit.org
Sent: Tuesday, March 10, 2009 12:58:54 AM
Subject: [webkit-dev] Stable tiger engine build?

Hi, 

Can someone tell me stable release of WebKit with Tiger engine? 

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

Re: [webkit-dev] How can I search through webkit-dev mailling list archive?

[David Kilzer]

Yes, use "site:lists.webkit.org/pipermail/webkit-dev" as a keyword in a Google 
search.  For example:

http://www.google.com/search?client=safari&rls=en&q=site:lists.webkit.org/pipermail/webkit-dev+help&ie=UTF-8&oe=UTF-8

Dave





From: 조정흠 
To: webkit-dev@lists.webkit.org
Sent: Wednesday, March 11, 2009 4:44:57 AM
Subject: [webkit-dev] How can I search through webkit-dev mailling list archive?


Hello,
 
I am again ^^;
 
I'd liek to ask a question about the way to search through our mailing list 
archive.
Now when I search some keyword from the archive, I do search for one month of 
archive at a time. This way make me give up on searching the whole one. I can 
only search on the recent archives.
Isn't there another way to search the whole archive at a time?
 
Best regards
-- 
Humi
Seoul___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JavaScriptCore or WebCore

[David Kilzer]

JavaScriptCore/kjs was removed and files were moved to other subdirectories 
like JavaScriptCore/runtime.

Running "svn log -v | less" and searching for the old file name will usually 
help you find what was renamed.  Or look in JavaScriptCore/ChangeLog* files for 
the same information.

Dave





From: Husam Senussi 
To: webkit-dev@lists.webkit.org
Sent: Wednesday, March 11, 2009 12:31:36 PM
Subject: [webkit-dev] JavaScriptCore or WebCore

Hi,

I'm trying to see where should go, I'm writing the code for JSON object and I'm 
not  sure where should  go.

In the patch attached to the bug the code for JSON object exist in 
JavaScriptCore/kjs which doesn't exist in
source tree I checked out, instead I found JavaScriptCore/runtime.

Or should the files go into WebCore/bindings/js but my understanding this 
directory contains
DOM object not Javascript language objects like Array,String, Math ... etc.

Sorry if that sounds like dumb question, I' just trying to understand structure 
of the source code.

Thanks
Husam.
___
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] how to obtain the value of the html by ID

[David Kilzer]

There currently aren't C++ bindings available for the DOM (that mirror the DOM 
available in JavaScript).  They would have to be implemented.  See the scripts 
in the WebCore/bindings/scripts directory.

Dave



- Original Message 
> From: zhenghe zhang 
> To: webkit-dev@lists.webkit.org
> Sent: Tuesday, March 17, 2009 3:03:46 AM
> Subject: [webkit-dev] how to obtain the value of the html  by ID
> 
> Hi all
> I have a problem, I hope you tell me, thank you.
> There is a js function:
> 
> function alertValue()
> {
>  alert(text1.value);
> }
> Now I want to know the javascript function how to obtain the value of
> "text1" through the c++ functions, I hope you tell me,
> Thank you & regards
> zh
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] where strore "html widget" name and id

[David Kilzer]

In WebCore/dom/Element.h, there is a member variable named 'nameAttrMap' that 
holds name/value pairs for the attributes of each element.

If you then look at WebCore/html/HTMLElement.cpp, you'll find an id() method 
that pulls the id out of the map, for example.

Dave





From: zhenghe zhang 
To: webkit-dev@lists.webkit.org
Sent: Tuesday, March 17, 2009 3:39:48 AM
Subject: [webkit-dev] where strore  "html widget" name and id

 
Hi all
I am studying the webkit, now I have a problem, I hope you tell me!
thank you.
there are many html widget in the document, and now I want to konw where
 store the name and id of  html widget
thank you
zhang___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] x86-64 JIT

[David Kilzer]

Which version of gcc are you using?  Older versions (think gcc-3.x) are known 
to have issues compiling JavaScriptCore, although I don't recall reading about 
this particular issue.

Dave



- Original Message 
> From: Mike Hommey 
> To: webkit-dev@lists.webkit.org
> Sent: Tuesday, March 17, 2009 1:51:57 PM
> Subject: [webkit-dev] x86-64 JIT
> 
> Hi,
> 
> I was taking a quick look at the JIT code and also gave a shot at
> forcing a build of the x86-64 code under Linux.
> 
> The main problem right now is the following:
> ../JavaScriptCore/jit/JITArithmetic.cpp:664: error: cast from 
> 'JSC::Structure*' 
> to 'unsigned int' loses precision
> ../JavaScriptCore/jit/JITArithmetic.cpp:674: error: cast from 
> 'JSC::Structure*' 
> to 'unsigned int' loses precision
> ../JavaScriptCore/jit/JITArithmetic.cpp:714: error: cast from 
> 'JSC::Structure*' 
> to 'unsigned int' loses precision
> ../JavaScriptCore/jit/JITArithmetic.cpp:724: error: cast from 
> 'JSC::Structure*' 
> to 'unsigned int' loses precision
> 
> Looking at the code, it seems really too much x86-centric, and
> depending on how the x86-64 ABI is under OSX. I don't know how things
> are going to evolve with Snow-Leopard, as I hear the kernel will finally
> be 64-bits, but maybe the same issue will arise.
> 
> Anyways, I'd need guidance from some people with JIT knowledge to help
> me get it work on Linux.
> 
> Cheers,
> 
> Mike
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] about WebCore\bindings\scripts documents

[David Kilzer]

The *.idl files are a custom Interface Definition Language for generating 
source code for DOM bindings.  On the Apple Mac port, there are (generally 
speaking) two such bindings built for each *.idl file:

- JavaScript bindings in C++ created by CodeGeneratorJS.pm; these files are the 
glue between JavaScriptCore and the C++ implementation files in WebCore.  They 
make the HTML DOM work in the web browser.

- Objective-C DOM bindings created by CodeGeneratorObjC.pm; these files provide 
an interface nearly identical to the HTML DOM interface in JavaScript, except 
in the Objective-C language.

Dave





From: 张正和 
To: webkit-dev@lists.webkit.org
Sent: Wednesday, March 18, 2009 3:13:00 AM
Subject: [webkit-dev] about WebCore\bindings\scripts documents


Hi all
In the webcore\bindings,there are some documents, but they are not c++ 
documents and I don't kown what they are. And what language they use. Now I 
want to konw their function, I hope you tell me!
thank you
zzh 

好玩贺卡等你发，邮箱贺卡全新上线！___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Use SquirrelFishExtreme Alone, Many Questions

[David Kilzer]

On Wednesday, March 18, 2009 9:02:04 AM, Brian Barnes wrote:

> 1) Can I compile SFE alone (without webkit)

Yes.  Squirrelfish Extreme ("SFX") is an implementation "detail" (albeit a very 
significant detail :) of the JavaScriptCore framework.

> 2) Are there XCode and MVC projects (for SPE alone), and is the XCode
> project a  framework?

Yes, it's JavaScriptCore.  Yes it's also an Xcode project.

> 3) Where are the SPE API docs online?

http://developer.apple.com/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/index.html

> 4) Is there a C interface (obviously I can't find the docs :) )


Yes, it's a C interface.

Dave

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

Re: [webkit-dev] Use SquirrelFishExtreme Alone, Many Questions

[David Kilzer]

> [...] Is there good example code for:
> 
> (1) adding an object to the global objects that has it's own functions and 
> properties
> (2) getting call backs for getters, setters, etc, in objects


You might try the files in the JavaScriptCore/API/tests/ directory.  I haven't 
used the API before, so I'm not sure where any good examples would be.

Dave

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

Re: [webkit-dev] Diabling XML, XPATH, SVG, and XSLT features of WebKit

[David Kilzer]

For the Apple Mac port, look at the list of FEATURE_DEFINES in 
JavaScriptCore/Configurations/JavaScriptCore.xcconfig, 
WebCore/Configurations/WebCore.xcconfig and 
WebKit/mac/Configurations/WebKit.xcconfig.

For other ports, look in related build files for the ENABLE_FOO macros.

Dave





From: jagadeesh k 
To: webkit-dev@lists.webkit.org
Sent: Wednesday, March 18, 2009 10:30:52 PM
Subject: [webkit-dev] Diabling XML,XPATH,SVG,and XSLT features of  WebKit


Hi,
How can i disable the XML,XPATH,SVG,and XSLT features of WebKit ?
 
Is their any macros for disabling(as read in one of the threads of WebKit-dev 
forum)the same ?
 
thanks and regards
jagadeesh___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Running test case under debugger "gdb"

[David Kilzer]

On Mac OS X, you can start gdb and use:

(gdb) attach -waitfor DumpRenderTree

Then start run-webkit-tests.

If your gdb doeesn't have "attach -waitfor", you can just put a timeout in 
run-webkit-tests like this after the "dump tool" is opened but before any tests 
are sent to it:

sleep(15); # sleep 15 seconds so gdb can be attached

Dave



- Original Message 
> From: Husam Senussi 
> To: webkit-dev@lists.webkit.org
> Sent: Friday, March 20, 2009 7:32:40 PM
> Subject: [webkit-dev] Running test case under debugger "gdb"
> 
> Hi,
> 
> is there any easy way to use debugger with test case.
> 
> Thanks
> Husam
> ___
> 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] webkit-dev:loadURL failed.

[David Kilzer]

Hi Partin,

Please file a bug report on .  Thanks!

Dave




From: Partin-巴丁 
To: webkit-dev@lists.webkit.org
Sent: Tuesday, March 31, 2009 3:08:45 AM
Subject: Re: [webkit-dev] webkit-dev:loadURL failed.


The project  "WinLauncher", 
file name :WinLauncher.cpp
function: loadURL()
 
following code:
   urlBStr = fileURL;
 
this will destroy the length of urlBStr, may be like this will be work:

   urlBStr = SysAllocStringLen(fileURL, fileURLLength);

Right ?
 
partin___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Customization of WebKit.

[David Kilzer]

The FEATURE_DEFINES variables in *.xcconfig files are only used when building 
WebKit for Safari on Mac OS X.  Unless you're working on that specific port, 
you need to enable/disable those flags elsewhere.  Hint:

$ grep -l -r ENABLE_XSLT WebCore
WebCore/Configurations/WebCore.xcconfig
WebCore/GNUmakefile.am
WebCore/webcore-base.bkl
WebCore/WebCore.pro
WebCore/WebCore.vcproj/WebCore.vcproj

Dave





From: jagadeesh k 
To: webkit-dev@lists.webkit.org
Sent: Wednesday, April 1, 2009 9:17:17 PM
Subject: [webkit-dev] Customization of WebKit.


Hi,
I want to disable the SVG,XML,XPATH,XSLT features of WebKit.
And i came  to know that,disabling of above features can be achieved by using 
FEATURE_DEFINES Variable in JavaScriptCore.xcconfig, 
WebKit.xcconfig,WebCore.xcconfig files.I want to know whether the above method 
is enough or i should remove corresponding XML,SVG,XPATH specific files 
(.cpp,.h files)in WebKit for diasbling.If Yes,please mention which are all the 
files i should remove in WebKit?
 
Thanks and Regards
jagadeesh  
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How to write plug-ins in webkit?

[David Kilzer]

Apple documentation for NSAPI (Netscape) plug-ins and Web (Objective-C) 
plug-ins:

http://developer.apple.com/DOCUMENTATION/InternetWeb/Conceptual/WebKit_PluginProgTopic/WebKitPluginTopics.html

Example/test code in the WebKit source tree:

http://trac.webkit.org/browser/trunk/WebKitExamplePlugins
http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/TestNetscapePlugIn.subproj

Dave





From: Hongwei Huang 
To: webkit-dev@lists.webkit.org
Sent: Thursday, April 9, 2009 10:48:56 PM
Subject: [webkit-dev] How to write plug-ins in webkit?

I want to learn webkit plugins , and then how to write plug-ins in webkit?
Will some give me some advice?
Thangks!

Best wishes！

Hongwei Huang

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

Re: [webkit-dev] WebKit caching

[David Kilzer]

Why don't you just send a couple HTTP headers with the JavaScript and CSS 
resources when they leave your web server:

Pragma: no-cache
Cache-Control: no-cache

Or do you need a generalized solution for any web site?

Note that this may not work except in recent nightly builds due to 
.

Dave





From: Adam Thorsen 
To: webkit-dev@lists.webkit.org
Sent: Friday, April 10, 2009 12:02:18 PM
Subject: [webkit-dev] WebKit caching

I would like to prevent a WebKit WebView instance in Cocoa  from caching 
certain content.  I've attempted to prevent this using several approaches, 
including:

1.  Overriding the NSURLCache cachedResponseForRequest and cachedResponse 
forRequest methods
2.  Handling -(NSURLRequest *)webView:(WebView *)sender resource:(id) 
willSendRequest:(NSURLRequest *) redirectResponse:(NSURLResponse *) 
fromDataSource:(WebDataSource *)dataSource
a) tried setting the cache policy to NSURLRequestReloadIgnoringCacheData, among 
other settings
   b) tried appending a random string onto the end of the resource url 
before passing it along (i.e. something like 
http://blah.com/file.js?23234234234)
3.  Clearing the cache by setting the shared url cache (via NSURLCache ) and 
calling removeAllCachedResponses before each page load.
4. Setting preferences on the WebView:

   WebPreferences *prefs = [webView preferences];
   [prefs setUsesPageCache:NO];

and

   WebPreferences *prefs = [webView preferences];
   [prefs setPrivateBrowsingEnabled:YES];


None of these approaches seem to prevent the webview from caching javascript 
resources.  Based on its behavior, I believe that on initial page load it 
checks the last-modified value in each response header and caches resources in 
memory that have not been modified within a certain period of time.  Recently 
modified files (within the past few minutes) are not cached.

My ultimate goal  is simply to prevent the webview from caching javascript and 
css files, and I am open to any suggestions on how to do that.  However, based 
on my above hypothesis about how WebKit handles caching internally, I believe 
that if I could rewrite the response headers such that last-modified is always 
a recent value, I could prevent WebKit from caching.

Currently I can view the response header by implementing:

- (void)webView:(WebView *)sender resource:(id)identifier 
didReceiveResponse:(NSURLResponse *)response fromDataSource:(WebDataSource 
*)dataSource

and calling allHeaderFields on the response.  However, there appears to be no 
way to modify the response before sending it on to the webview for display.  
Are there any suggestions on how to do this?

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

Re: [webkit-dev] how does Webkit handle font

[David Kilzer]

No, libicu is used to lay out international text.

CSS fonts are handled by files with "CSS" and "font" in their name, which will 
lead you to other files with "font" in their name under the 
WebCore/platform/graphics/ directory.

$ find WebCore -iname \*font\* -print | grep -i css
WebCore/css/CSSFontFace.cpp
WebCore/css/CSSFontFace.h
WebCore/css/CSSFontFaceRule.cpp
WebCore/css/CSSFontFaceRule.h
WebCore/css/CSSFontFaceRule.idl
WebCore/css/CSSFontFaceSource.cpp
WebCore/css/CSSFontFaceSource.h
WebCore/css/CSSFontFaceSrcValue.cpp
WebCore/css/CSSFontFaceSrcValue.h
WebCore/css/CSSFontSelector.cpp
WebCore/css/CSSFontSelector.h
WebCore/css/CSSSegmentedFontFace.cpp
WebCore/css/CSSSegmentedFontFace.h
WebCore/css/FontFamilyValue.cpp
WebCore/css/FontFamilyValue.h
WebCore/css/FontValue.cpp
WebCore/css/FontValue.h

Dave





From: x yz 
To: webkit-dev@lists.webkit.org; ying lcs 
Sent: Tuesday, April 21, 2009 11:10:20 AM
Subject: Re: [webkit-dev] how does Webkit handle font


I think it is handled by libicu.


--- On Tue, 4/21/09, ying lcs  wrote:

> From: ying lcs 
> Subject: [webkit-dev] how does Webkit handle font
> To: webkit-dev@lists.webkit.org
> Date: Tuesday, April 21, 2009, 2:00 PM
> Hi,
> 
> Can you please tell me how does Webkit handle font? (e.g.
> which files
> I should look at)
> e.g. css can specify a particular font for a paragraph ,
> where/how
> does Webkit load the font from the OS (or how does it know
> the font
> actually exists?
> 
> Thank you.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs

[David Kilzer]

> 1b) WINCE actually includes plenty of WIN but in some cases
> does things differently.  How to make this distinction without
> lots of && and ||?


There are various design patterns that may be used to alleviate macros, such as 
subclassing and use of delegates.  Each case will probably require a specific 
solution, but many of the patterns should be reusable.

> 2) We use PLATFORM(TORCHMOBILE) across multiple OS for things
> that are not necessarily platform specific but specific to our
> browsers.  I guess this is similar to PLATFORM(CHROMIUM).
> Honestly I don't like filling the code with these but we all
> do it, including MAC.  MAC tends to win the default right now.
> I'm not sure how best to handle this yet but I foresee a big
> mess if we aren't careful.


I think Maciej said that part of this plan is to break up PLATFORM(MAC) into 
smaller pieces.  I haven't looked at the Torch Mobile source code, but I 
suspect the same thing may need to be done in this case as well.  When porting, 
it's very easy to lump features, library/framework dependencies (I'm thinking 
of CFNetwork vs. libcurl vs. libsoup), and true platform-specific code into a 
single macro.  Part of this effort will be to clean that up.

Dave





From: George Staikos 
To: WebKit Development 
Sent: Monday, May 4, 2009 7:45:41 PM
Subject: Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs


I really like this and it goes in the direction that I was hoping for as well.  
Hopefully we can get the WINCE port merged upstream before we make this change. 
:-)

Some comments I have:

1) In some cases some things apply to more than one OS so we have:
#if OS(x) || OS(y) || OS(z) ...
I think we should use:
#if OS(x,y,z)

1b) WINCE actually includes plenty of WIN but in some cases does things 
differently.  How to make this distinction without lots of && and ||?

2) We use PLATFORM(TORCHMOBILE) across multiple OS for things that are not 
necessarily platform specific but specific to our browsers.  I guess this is 
similar to PLATFORM(CHROMIUM).  Honestly I don't like filling the code with 
these but we all do it, including MAC.  MAC tends to win the default right now. 
 I'm not sure how best to handle this yet but I foresee a big mess if we aren't 
careful.

3) I'm not sure that USE() really applies equally as you described.  In some 
cases it applies to basically the whole system API used (QT), but in others 
it's just a support library (QUICKTIME).

Again, fully support these changes and perhaps some more too.  Just give us a 
bit of time to find the right way to merge the WINCE stuff in first please!


On 30-Apr-09, at 7:12 PM, Maciej Stachowiak wrote:

> 
> I think our set of porting macros has become somewhat confused.
> 
> Originally, our idea was that a port represents primarily adaptation to a 
> particular platform. However, over time it has become clear that most of what 
> is decided by a port is not platform adaptation, but rather policy decisions. 
> For example, ports decide to have different features enabled, or to use 
> different sets of system functionality on the same underlying OS.
> 
> In addition, I think the catchall top-level PLATFORM create confusion, 
> because it is not totally clear if they are policy decisions, platform 
> adaptation decisions, or what.
> 
> Third, it seems wrong that the policy choices of every port are represented 
> as a bunch of ifdef tomfoolery inside a single Platform.h file.
> 
> And fourth, many ports often run on the same OS, but with a different set of 
> choices - for example on Mac OS X it is possible to build the Mac, Chromium, 
> Gtk, Qt and Wx ports (at least).
> 
> 
> Therefore, I propose that we change as follows:
> 
> 1) Strictly separate platform adaptation (mandatory to run on a given OS, 
> compiler, or CPU at all) from policy choices (what features to enable, what 
> optional libraries to use).
> 
> 2) Phase out PLATFORM macros completely - each use should be converted to a 
> policy choice, or a platform adaptation decision.
> 
> 3) Instead of ports being defined by a top-level PLATFORM macro, I propose 
> that each port should have its own header file to define policy decisions. 
> For example, I'd propose that the system Mac OS X WebKit should use 
> PortCocoa.h, and the WebKit used by Safari for Windows should use 
> PortWinCG.h. There may also be a PortIPhone.h. These port definition headers 
> would live in their own top-level WebKit module. Each one would be completely 
> owned by whoever is generally considered the "owner" of a given port. Because 
> related ports on different platforms may wish to share policy choices, it's 
> ok for Port headers to include shared headers for some choices. For example, 
> all Apple-maintained ports may include PortApple.h. We could go even further 
> and have PortDefault.h to make default choices of what features are enabled, 
> that ports would have to explicitly override.
> 
> 4) Platform

Re: [webkit-dev] A problem with the "data" attribute of the "object" tag

[David Kilzer]

Unless the movie was loaded from a file:/// URL, it's probably your web server 
setting the MIME type for the movie file:

$ grep 'avi$' /etc/httpd/mime.types
video/x-msvideo avi
$ grep 'wmv$' /etc/httpd/mime.types
video/x-ms-wmv  wmv

Dave





From: naixuan guan 
To: webkit-dev@lists.webkit.org
Sent: Tuesday, May 19, 2009 1:29:00 AM
Subject: Re: [webkit-dev] A problem with the "data" attribute of the "object" 
tag


PS: I use the webkit which is ported to Qt/E4.5.0


2009/5/19 naixuan guan 

Hi, everyone!
 
The HTML page is as follow:
 

 
when webkit detect the object, it automatically thought the mimetype of this 
object is "video/x-ms-wmv"
when I change the data attribute to "1.avi", webkit thought the mimetype is 
"video/x-msvideo"
 
I really want to know how does webkit do this kind of judge. I search the src 
code with the key word "video/x-ms-wmv", but I got nothing.
Currently I only know two functions may work with this: 
RenderPartObject::updateWidget and HTMLObjectElement::parseMappedAttribute, but 
I can't find out how does webkit check the "data" attribute and decide which 
mimetype to use.
 
Could you give me some tips?
Thanks!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] build on ubuntu not working as expected

[David Kilzer]

Yes, your messages are getting to the list.

Your best bet is to contact the wxWebKit maintainer, Kevin Ollivier, who I've 
copied on this message.

Dave





From: anurag uniyal 
To: webkit-dev@lists.webkit.org
Sent: Tuesday, May 19, 2009 8:13:36 AM
Subject: Re: [webkit-dev] build on ubuntu not working as expected


Can anybody confirm this is getting to the list?




From: anurag uniyal 
To: anurag uniyal ; webkit-dev@lists.webkit.org
Sent: Sunday, 17 May, 2009 9:36:49 AM
Subject: Re: [webkit-dev] build on ubuntu not working as expected


can anybody give any pointers?




From: anurag uniyal 
To: webkit-dev@lists.webkit.org
Sent: Friday, 15 May, 2009 3:34:55 PM
Subject: [webkit-dev] build on ubuntu not working as expected




I first posted it on webkitsdk-...@lists.apple.com but was redirected here.

Hi,

I am facing problem in running latest build on ubuntu.

Problem:
I build revision 41937 sometime back and wxBrowser and my own wxPython browser 
was working fine

Today i updated to revision 43688.
1.
First I got an error at line 329 platform/network/curl/ResourceHandleManager.cpp
url not defined in this scope
so i moved out char* url out of #ifndef NDEBUG 

after that build was successful, regresion test also passed except few date 
test which were same in last revision too

2. now wxBrowser does not work as expected e.g.
on opening www.google.com 
a) it takes too much time
b) image are not displayed
c) it doesn't go to any other link, just stuck at loading...

for build I used 
./set-webkit-configuration --release
./build-webkit --wx --wx-args="wxgc wxpython"

my system is
GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Linux-2.6.24-19-generic-i686-with-debian-lenny-sid'

Any tips are appreciated.

Thanks
Anurag



 From Chandigarh to Chennai - find friends all over India. Click here.

 Share files, take polls, and make new friends - all under one roof. Click here.

 Explore and discover exciting holidays and getaways with Yahoo! India Travel 
Click here!

 Cricket on your mind? Visit the ultimate cricket website. Enter now!___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs

[David Kilzer]

Another aspect of this proposal is how to handle source files that have #if 
ENABLE(FEATURE)/#endif guards around all of their source code, for example:

Bug 25756: Explicit guards for ENABLE_GEOLOCATION
https://bugs.webkit.org/show_bug.cgi?id=25756

There are essentially two options here:

1. Add #if/#endif guards to entire source files, but include every file in 
every build system.

2. Make each build system smart enough to exclude source files that implement a 
feature, thus pushing the policy decision down (up?) into the build system 
(which is where most of the decisions are made today anyway).

I think #2 is a much cleaner way to handle this since it removes clutter from 
the code (at the cost of duplicating knowledge of which files go with with 
features into each build system).

Does anyone else have an opinion on this?

Dave





From: Maciej Stachowiak 
To: WebKit Development 
Sent: Thursday, April 30, 2009 4:12:54 PM
Subject: [webkit-dev] Proposal for a new way to handle porting #ifdefs


I think our set of porting macros has become somewhat confused.

Originally, our idea was that a port represents primarily adaptation to a 
particular platform. However, over time it has become clear that most of what 
is decided by a port is not platform adaptation, but rather policy decisions. 
For example, ports decide to have different features enabled, or to use 
different sets of system functionality on the same underlying OS.

In addition, I think the catchall top-level PLATFORM create confusion, because 
it is not totally clear if they are policy decisions, platform adaptation 
decisions, or what.

Third, it seems wrong that the policy choices of every port are represented as 
a bunch of ifdef tomfoolery inside a single Platform.h file.

And fourth, many ports often run on the same OS, but with a different set of 
choices - for example on Mac OS X it is possible to build the Mac, Chromium, 
Gtk, Qt and Wx ports (at least).


Therefore, I propose that we change as follows:

1) Strictly separate platform adaptation (mandatory to run on a given OS, 
compiler, or CPU at all) from policy choices (what features to enable, what 
optional libraries to use).

2) Phase out PLATFORM macros completely - each use should be converted to a 
policy choice, or a platform adaptation decision.

3) Instead of ports being defined by a top-level PLATFORM macro, I propose that 
each port should have its own header file to define policy decisions. For 
example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, 
and the WebKit used by Safari for Windows should use PortWinCG.h. There may 
also be a PortIPhone.h. These port definition headers would live in their own 
top-level WebKit module. Each one would be completely owned by whoever is 
generally considered the "owner" of a given port. Because related ports on 
different platforms may wish to share policy choices, it's ok for Port headers 
to include shared headers for some choices. For example, all Apple-maintained 
ports may include PortApple.h. We could go even further and have PortDefault.h 
to make default choices of what features are enabled, that ports would have to 
explicitly override.

4) Platform adaptation macros would still be defined in Platform.h based on 
sniffing the environment, this would include things like the compiler, the 
underlying OS, available libc functions, and so forth.


Platform adaptation macros would be:

OS() - underlying operating system; only to be used for mandated low-level 
services like virtual memory, not to choose a GUI toolkit
Examples:
OS(UNIX) - Any Unix-like OS
OS(DARWIN) - Underlying OS is the base OS X environment
OS(FREEBSD) - FreeBSD
OS(WIN) - Any version of Windows
OS(WINCE) - The embedded version of Windows

COMPILER() - the compiler being used to build the project
Examples:
COMPILER(GCC) - GNU Compiler Collection
COMPILER(MSVC) - Microsoft Visual C++
COMPILER(RVCT) - ARM compiler

HAVE() - specific system features (headers, functions or similar) that are 
present or not
Examples:
HAVE(MMAP) - mmap() function is available
HAVE(ERRNO_H) - errno.h header is available
HAVE(MADV_FREE) - madvise(MADV_FREE) is available


Policy decision macros would be:

USE() - use a particular third-party library or optional OS service
Examples:
USE(SKIA) - Use the Skia graphics library
USE(CG) - Use CoreGraphics
USE(V8) - Use the V8 JavaScript implementation
USE(CFNET) - Use CFNetwork networking
USE(NSURL_NET) - Use NSURLConnection-based networking
USE(APPKIT) - Use AppKit views and events
USE(GTK) - Use Gtk+
USE(QT) - Use Qt
USE(QUICKTIME) - Use the QuickTime media engine
USE(QTKIT) - Use the QuickTime media engine via the Mac QTKit API
USE(QUICKTIME_WIN) - Use the QuickTime media engine via its Windows

Re: [webkit-dev] Webkit Rendered Image

[David Kilzer]

Try looking at source in WebCore/rendering/.

Dave





From: webkitUser 
To: webkit-dev@lists.webkit.org
Sent: Wednesday, May 27, 2009 3:59:28 AM
Subject: Re: [webkit-dev] Webkit Rendered Image


Hi,

Can somebody please give me some pointers here.

If you can point me to the part of source where the image/text get rendered
that would help me work backwards atleast.

Regards,


webkitUser wrote:
> 
> Hi,
> 
> I have modified the WinLauncher application to dump what it has rendered.
> 
> Basically I have plugged in the "createBitmapContextFromWebView" method
> from DumpRenderTree Sample, which is supposed to dump a png out of a
> WebView.
> 
> However, I see that the resulting png just has a blank image and not the
> rendered contents. Is this expected?
> 
> If yes, how can I get an image out of the Webkit rendered contents?
> 
> Thanks in Advance,
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Webkit-Rendered-Image-tp23671148p23740216.html
Sent from the Webkit mailing list archive at Nabble.com.

___
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] Multithread issue

[David Kilzer]

This assertion is telling you that the code expects to be running on the main 
thread.

You're also probably running a debug build since assertions are disabled in 
release builds.

Dave





From: Matt Bockt 
To: webkit-dev@lists.webkit.org
Sent: Wednesday, May 27, 2009 5:17:44 AM
Subject: [webkit-dev]  Multithread issue

Hi everybody, 

I'm new to WebKit and I'm developing a C++ application that uses the WebKit 
browser.

It runs on Fedora10, kernel 2.6.27.5-117.fc10.i686.
The WebKit version I'm using is the r44111.

Here is my problem : I'm creating a new web view in the main thread, say, 
thread A. 
The webview is then attached to a gtk_window as it's made in the GtkLauncher 
exemple.

Then webkit_web_view_load_uri() is called, always in thread A.

Finally, the gtk_main() function is called in another thread, say thread B.

And it crashes  with the following trace  : 

ASSERTION FAILED: m_thread == currentThread()
(WebCore/platform/Timer.cpp:206 bool WebCore::TimerBase::isActive() const)

I experience this problem with the webkit r44111 and r43808, but not with 
r38297.

I
noticed that there must have been a modification in the thread management
between the builds r38297 and r43808 since g_threads must be
initialized. 
But I can't figure out why it doesn't work.

Any suggestions or specific rules to follow about multi-threading, gtk and 
webkit ?

Thank you for your help.

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

Re: [webkit-dev] Safari 4: all apps which use Webkit freezing at same time

[David Kilzer]

Hi Ben,

The best thing to do in this case is to file a bug report with Apple on 
.  I'll send you a list of steps on how to do 
this off the list.

Dave





From: Benjamin Jackson 
To: webkit-dev@lists.webkit.org
Sent: Friday, May 29, 2009 6:48:51 AM
Subject: [webkit-dev] Safari 4: all apps which use Webkit freezing at same time

It's happened a couple of times now: all of the open apps which use
Webkit (e.g. Adium, Mail, Safari etc) will hang at the same time and
will not allow the user to force quit.

A restart is required to get the Mac functional again.

Is this a known issue? Any idea what might be up?

Thanks,

Ben
___
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] Coding style

[David Kilzer]

Hi Kenneth,

The examples you give below are correct (with the exception of the number of 
spaces used to indent the code in the else blocks).

Please file a bug on bugs.webkit.org and attach a patch.  The webkit.org web 
site is in the svn repository, so you may create patches against the HTML.

Thanks!

Dave





From: Kenneth Christiansen 
To: webkit-dev 
Sent: Thursday, June 4, 2009 7:52:29 AM
Subject: [webkit-dev] Coding style

Hi there,

I'm having a question regarding the coding style.

According to 2. An else statement should go on the same line as a
preceding close brace.

I would always need a brace when using if-else, in order to but the
else statement on the same line as the preceding close brace, is this
right?
or would something like this is OK:

if (condition)
func1();
else
   func2();

And what about this case

if (condition)
func1();
else {
   func2();
   func3();
}

It would be nice to have this defined in the coding style,  as well as
adding the case that when you have a comment inside a one line if
statement you will need braces, like

if (condition) {
 // comment
 func()
}

Cheers, Kenneth
___
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] What's going on with the debug Leopard bot on build.webkit.org?

[David Kilzer]

I filed two bugs which seem to cover all the failures (although I did not click 
on every single failing SVG result diff):

Bug 26218: REGRESSION: LayoutTests/fast/dom/Window/orphaned-frame-access.html 
fails on Debug builds
https://bugs.webkit.org/show_bug.cgi?id=26218

Bug 26219: REGRESSION: 92 SVG layout tests failing on Leopard Debug buildbot 
with wrong fill color
https://bugs.webkit.org/show_bug.cgi?id=26219

Dave





From: Adam Roben 
To: webkit-dev Development 
Sent: Thursday, June 4, 2009 7:14:02 AM
Subject: [webkit-dev] What's going on with the debug Leopard bot on 
build.webkit.org?

This bot has had 93 tests failing for quite some time. Does anyone know what's 
causing these failures?

-Adam

___
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] to reitveld or not to reitveld

[David Kilzer]

I think this is a great direction to move in, but (IMO) any such tool should be 
tightly integrated with bugs.webkit.org so that (a) you don't have to post the 
same patch more than once, (b) the review status of the patch is visible in 
bugs.webkit.org without clicking on a link and (c) it's easy to switch between 
reviewing the patch and updating the bug itself.

I just filed a Bugzilla bug about adding such a feature to Bugzilla itself 
(although I wouldn't be surprised if it's a dupe):

Bugzilla needs better patch review process with annotations and versioned 
patches


Dave





From: Jeremy Orlow 
To: Ojan Vafai 
Cc: WebKit Development 
Sent: Friday, June 5, 2009 5:08:47 PM
Subject: Re: [webkit-dev] to reitveld or not to reitveld

For what it's worth, I definitely think a tool like reitveld would help the 
code review process.  Inline comments and more context than the couple lines 
the diff provides are really, really helpful.


On Fri, Jun 5, 2009 at 9:25 AM, Ojan Vafai  wrote:

Sorry in advance for the long email. I'm trying to be thorough.
There's been a lot of discussion on #webkit about possibly using a code review 
tool like reitveld for webkit reviews. There's been various suggestions and a 
few misunderstandings, so it seems worth having a more formal discussion about 
this with the larger WebKit community.

The things I'd like to assess here are:
1. Pros/Cons of using a system like reitveld. I listed some below. Please add 
any that I missed.
2. Whether the WebKit community is interested in pursuing something like this.
3. If there is interest, what is the best way to move forward.


WHAT IS REITVELD
It's a code review tool. Reitveld doesn't allow you to do anything that is 
impossible with the current review process, however, it makes the review 
process more efficient and less error-prone. As such, it makes it easier and 
less time-consuming to do good, thorough code reviews.

The basic gist of reitveld is that it allows you to put comments inline and 
send them all in one chunk. Then it lets the reviewee easily respond to each 
comment individually and send all the responses in one chunk.

EXAMPLE CHROMIUM PATCH
http://codereview.chromium.org/119103

Note that you can view the patch in each version that was uploaded and that you 
can diff between versions. Also, if a comment was made in the version you were 
looking at, then you can see all the comments/responses.

To see this nicely, under "Delta from patch set" in patch set 3, click on 2. 
That is where most of the comments in this review were made. For example, 
http://codereview.chromium.org/119103/diff2/14:27/29. You can see all the 
comments and responses along with the diff in the patch to see that the 
reviewer comments were implemented as intended.

Keyboard shortcuts to try out:
-n/p to switch between diff chunks
-shift n/p to switch between comments
-j/k to go to the next/previous file

*Please don't actually click the "Publish all my drafts" button on the publish 
page as you'll be modifying a real code review.*

Other things to try
-try the side-by-side diff and the unified diff views
-adding comments (double click)
-replying to comments
-go to the publish page (click the publish link or type "m") 

Also note that the "Committed" URL is automatically added when the patch is 
committed and the reitveld issue is marked closed. So there isn't extra 
overhead in maintaining list of outstanding code reviews.

HOW TO TRY IT OUT
Here's the process for trying out reitveld with a webkit patch. The current 
workflow is a bit janky, but some scripting and some simple reitveld fixes 
would make this a lot more natural and automated (e.g. chromium uses 
commandline "gcl upload" to put up a new patch).

1. Find a non-git patch
2. Go to http://codereview.chromium.org/new
3. Login with a Google account (e.g. any gmail or Google search account)
4. On that page, type in a subject and paste in the URL to the patch in the URL 
field.
5. Click "Create Issue"

There's a couple apparent bugs that are easily fixable:
1. The ChangeLog files don't get downloaded correct, so the diffs don't work. 
This is an AppEngine problem that Chromium works around with the gcl upload 
script.
2. With an old patch there are often diff chunk mistmatches, which breaks the 
side-by-side diff view (you can use the unified diff in those cases). 

PROS
For the reviewer:
-easier to write thorough review comments since adding comments is so 
light-weight
-easier to make sure that all review comments actually got implemented

For the reviewee:
-easier to see which line the reviewer's comment addresses
-easier to make sure you've completed all the reviewer's comments (you can mark 
them as "done" in reitveld as you go)

For everyone:
-efficient keyboard navigation (e.g. j/k to navigation between diff chunks and 
n/p to navigate between files
-easier to follow the progression of a code revie

Re: [webkit-dev] to reitveld or not to reitveld

[David Kilzer]

On Friday, June 5, 2009 Ojan Vafai wrote:
> This is what I meant by "light-weight" integration. All the review
> information would be reflected in the bugzilla bug. You would never
> be required to use reitveld for anything.

But I'm a reviewer.  Don't you want to be selling me on the virtues of 
Reitveld?  :)

What happens if I choose to update a patch in Bugzilla instead of reitveld 
(assuming I'm not required to use Reitveld as you say)?  Will Bugzilla push the 
status of the patch back to Reitveld?

> A review tool like reitveld is quite a bit of work. Adding 
> similar functionality to bugzilla itself is a non-trivial amount
> of work. I don't see what integrating this functionality any
> more tightly into bugzilla buys us that is worth the order(s) of
> magnitude more effort that approach would take.

The one major thing it would buy us is less maintenance--adding another web 
site would double the amount of maintenance for the bug system.  I can easily 
imagine that upgrading one would break integration with the other and 
vice-versa.  Is there something I'm missing that would mitigate the risk of 
additional maintenance and break-on-upgrade issues?

It's obvious that a lot of work has gone into Reitveld, and I'm sure it's a 
great tool.  I just think it's a shame that no one has stepped up to provide 
similar functionality for Bugzilla, thereby improving the status quo for all 
users of this popular open source tool.

Dave




________
From: Ojan Vafai 
To: Darren VanBuren 
Cc: David Kilzer ; Jeremy Orlow ; 
WebKit Development 
Sent: Friday, June 5, 2009 7:25:40 PM
Subject: Re: [webkit-dev] to reitveld or not to reitveld


This is what I meant by "light-weight" integration. All the review information 
would be reflected in the bugzilla bug. You would never be required to use 
reitveld for anything.

We would be able to:
1. Add a link to bugzilla that would take you to the reitveld code review and 
upload the patch to reitveld if it hasn't been uploaded already.
2. Have all comments published in reitveld be posted to the bug.
3. Have checkboxes in reitveld for r+, r- that would update bugzilla.
4. I think we can even have comments made directly to bugzilla be reflected in 
reitveld by having a bot that monitors bugzilla update emails.

A review tool like reitveld is quite a bit of work. Adding similar 
functionality to bugzilla itself is a non-trivial amount of work. I don't see 
what integrating this functionality any more tightly into bugzilla buys us that 
is worth the order(s) of magnitude more effort that approach would take.

Ojan

On Sat, Jun 6, 2009 at 11:02 AM, Darren VanBuren  wrote:

Surprisingly, the bug isn't a duplicate, or if there is a dupe, it isn't filed 
correctly.

But I agree that any code review tool should be integrated with 
bugs.webkit.org, otherwise there would be a huge disorganized mess and it 
wouldn't be any better.

Bugzilla wouldn't be hard to extend for this purpose, just adding a field for 
review status and then making whatever code review tool you chose update 
Bugzilla solves (b).

Some modifications in the tool could also make it attach the patches to a bug, 
and you could also update any field in the bug.

I mean, retiveld seems like a wonderful tool, it seems like something that 
would extend Bugzilla quite nicely. Pushing data to Bugzilla can simply be done 
with XML-RPC according to this page on bugzilla.org: 
http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/Server/XMLRPC.html
 and there's plenty of XML libraries for Python you could use to work over 
XML-RPC.

Darren VanBuren
onekop...@gmail.com

http://oks.tumblr.com/


On Jun 5, 2009, at 6:21 PM, David Kilzer wrote:

I think this is a great direction to move in, but (IMO) any such tool should be 
tightly integrated with bugs.webkit.org so that (a) you don't have to post the 
same patch more than once, (b) the review status of the patch is visible in 
bugs.webkit.org without clicking on a link and (c) it's easy to switch between 
reviewing the patch and updating the bug itself.

I just filed a Bugzilla bug about adding such a feature to Bugzilla itself 
(although I wouldn't be surprised if it's a dupe):

Bugzilla needs better patch review process with annotations and versioned 
patches
<https://bugzilla.mozilla.org/show_bug.cgi?id=496670>

Dave





From: Jeremy Orlow 
To: Ojan Vafai 
Cc: WebKit Development 
Sent: Friday, June 5, 2009 5:08:47 PM
Subject: Re: [webkit-dev] to reitveld or not to reitveld

For what it's worth, I definitely think a tool like reitveld would help the 
code review process.  Inline comments and more context than the couple lines 
the diff provides are really, really helpful.


On Fri, Jun 5, 2009 at 9:25 AM, Ojan Vafai  wrote:

Sorry i

Re: [webkit-dev] Crash on the Mac (RapidWeaver plugin and Safari 4)

[David Kilzer]

Hi Gilberto,

Please file a bug on either  or 
 with explicit steps on how to reproduce the crash, 
then report the bug number here.

Thanks!

Dave





From: Gilberto De Faveri 
To: webkit-dev@lists.webkit.org
Sent: Friday, June 12, 2009 12:47:22 AM
Subject: [webkit-dev] Crash on the Mac (RapidWeaver plugin and Safari 4)

Hi all,
I'm working on a RapidWeaver plugin (Cocoa) which uses a WebView on its main 
window.

Using Safari 3 everything works as expected, but after installing Safari 4 
RapidWeaver crashes when re-opening the same plugin saving more than once.

The problems seems to be in JavaScriptCore:

*
Process: RapidWeaver [4901]
Path:/Applications/RapidWeaver.app/Contents/MacOS/RapidWeaver
Identifier:  com.realmacsoftware.rapidweaverpro
Version: ??? (4.2.1)
Code Type:   X86 (Native)
Parent Process:  launchd [74]

Architecture:   i386
Date/Time:   2009-06-11 13:25:20.531 +0200
OS Version:  Mac OS X 10.5.7 (9J61)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0xbe8fd800
Crashed Thread:  0

Thread 0 Crashed:
0   com.apple.JavaScriptCore  0x95b8bd83 void* 
WTF::fastMalloc(unsigned long) + 435
1   com.apple.WebCore 0x927623ac 
std::pair, 
WebCore::StringHash, WTF::HashTraits, 
WTF::HashTraits >, WebCore::StringImpl*>, bool> 
WTF::HashSet >::add(char const* const&) + 492
2   com.apple.WebCore 0x921bc2f4 
WebCore::AtomicString::add(char const*) + 52
3   com.apple.WebCore 0x9226a35d 
WebCore::ResourceRequestBase::isConditional() const + 397
4   com.apple.WebCore 0x922698e1 
WebCore::SubresourceLoader::create(WebCore::Frame*, 
WebCore::SubresourceLoaderClient*, WebCore::ResourceRequest const&, bool, bool, 
bool) + 769
5   com.apple.WebCore 0x92268fae 
WebCore::Loader::Host::servePendingRequests(WTF::Deque&, 
bool&) + 942
6   com.apple.WebCore 0x92268be2 
WebCore::Loader::Host::servePendingRequests(WebCore::Loader::Priority) + 82
7   com.apple.WebCore 0x92268598 
WebCore::Loader::load(WebCore::DocLoader*, WebCore::CachedResource*, bool, 
bool, bool) + 280
8   com.apple.WebCore 0x92268469 
WebCore::CachedResource::load(WebCore::DocLoader*, bool, bool, bool) + 89
9   com.apple.WebCore 0x92268400 
WebCore::CachedResource::load(WebCore::DocLoader*) + 48
10  com.apple.WebCore 0x92267bf0 
WebCore::Cache::requestResource(WebCore::DocLoader*, 
WebCore::CachedResource::Type, WebCore::KURL const&, WebCore::String const&, 
bool) + 192
11  com.apple.WebCore 0x92267560 
WebCore::DocLoader::requestResource(WebCore::CachedResource::Type, 
WebCore::String const&, WebCore::String const&, bool) + 192
12  com.apple.WebCore 0x9230697f 
WebCore::DocLoader::requestScript(WebCore::String const&, WebCore::String 
const&) + 47
13  com.apple.WebCore 0x9226fb30 
WebCore::HTMLTokenizer::scriptHandler(WebCore::HTMLTokenizer::State) + 3568
14  com.apple.WebCore 0x92261c9b 
WebCore::HTMLTokenizer::parseSpecial(WebCore::SegmentedString&, 
WebCore::HTMLTokenizer::State) + 2267
15  com.apple.WebCore 0x9224f6df 
WebCore::HTMLTokenizer::parseTag(WebCore::SegmentedString&, 
WebCore::HTMLTokenizer::State) + 9103
16  com.apple.WebCore 0x9224cc9b 
WebCore::HTMLTokenizer::write(WebCore::SegmentedString const&, bool) + 2907
17  com.apple.WebCore 0x921f7c50 
WebCore::FrameLoader::write(char const*, int, bool) + 432
18  com.apple.WebCore 0x9224b3f7 
WebCore::FrameLoader::addData(char const*, int) + 39
19  com.apple.WebKit  0x9322ec0c -[WebFrame(WebInternal) 
_receivedData:textEncodingName:] + 140
20  com.apple.WebKit  0x9322eb33 -[WebHTMLRepresentation 
receivedData:withDataSource:] + 499
21  com.apple.WebKit  0x9322e8db -[WebDataSource(WebInternal) 
_receivedData:] + 91
22  com.apple.WebKit  0x9322e859 
WebFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, char const*, int) 
+ 137
23  com.apple.WebCore 0x9223d356 
WebCore::DocumentLoader::commitLoad(char const*, int) + 70
24  com.apple.WebCore 0x9223cf85 
WebCore::ResourceLoader::didReceiveData(char const*, int, long long, bool) + 69
25  com.apple.WebCore 0x9223c752 
WebCore::MainResourceLoader::didReceiveData(char const*, int, long long, bool) 
+ 114
26  com.apple.WebCore 0x9223c6d8 
WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle*, char const*, 
int, int) + 56
27  com.apple.Foundation  0x950f8ed7 
-[NSURLConnection(NSURLConnectionReallyInternal) 
sendDidReceiveData:originalLength:] + 119
28  com.apple.Foundation  0x950f8e21 _NSURLConne

Re: [webkit-dev] [wxWindows] ubuntu build problem

[David Kilzer]

It sounds like the wxWindows build is broken due to a file missing from its 
build system.  (Find the source file with JSC::jsonTable() defined in it, then 
add it to the wx build system files.)

I've copied Kevin Ollivier, the port maintainer, so that he's aware of the 
issue.

Kevin, any chance of getting the wxWindows buildbot back online?

Dave





From: anurag uniyal 
To: webkit-dev@lists.webkit.org
Sent: Thursday, June 11, 2009 10:56:52 PM
Subject: Re: [webkit-dev] ubuntu build problem


do anybody have a clue, or any pointers for me so that I can fix it myself?



I have checked out revision 44600 today and it gives me build problem
is there some stable version which I should be using?

I am building it on ubuntu machine
with command
./build-webkit --wx --wx-args="wxgc wxpython"

"""
ranlib /home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a
g++ -o /home/anushri/try/WebKit/WebKitBuild/Release/jsc obj-gnu/jsc_jsc.o  -lm 
-L/usr/lib -licui18n -licuuc -licudata -lm 
-L/home/anushri/try/WebKit/WebKitBuild/Release 
-L/home/anushri/try/WebKit/WebKitTools/wx/../../WebKitLibraries/unix/lib 
-L/home/anushri/try/WebKit/WebKitTools/wx/../../WebKitLibraries -ljpeg -lpng 
`wx-config --libs core,base` -g-ljscore -lpthread  
/home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalData.o):
 In function `JSC::JSGlobalData::JSGlobalData(bool, JSC::VPtrSet const&)':
JSGlobalData.cpp:(.text+0x8e1): undefined reference to `JSC::jsonTable'
/home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalData.o):
 In function `JSC::JSGlobalData::JSGlobalData(bool, JSC::VPtrSet const&)':
JSGlobalData.cpp:(.text+0x1241): undefined reference to `JSC::jsonTable'
/home/anushri/try/WebKit/WebKitBuild/Release/libjscore.a(jscore_JSGlobalObject.o):
 In function `JSC::JSGlobalObject::reset(JSC::JSValue)':
JSGlobalObject.cpp:(.text+0x5391): undefined reference to `vtable for 
JSC::JSONObject'
collect2: ld returned 1 exit status
make: *** [/home/anushri/try/WebKit/WebKitBuild/Release/jsc] Error 1
make: Leaving directory `/home/anushri/try/WebKit/JavaScriptCore


rgds
Anurag

 Explore and discover exciting holidays and getaways with Yahoo! India Travel 
Click here!

 Own a website.Get an unlimited package.Pay next to nothing.*Click here!.

 Explore and discover exciting holidays and getaways with Yahoo! India Travel 
Click here!___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How to add Maxthon's port.

[David Kilzer]

Ariya Hidayat  wrote:

> > We're using webkit in Maxthon3.0 and want to submit our changes.
> > How to add maxthon's port?
> 
> http://webkit.org/coding/contributing.html


To expand upon this a bit, you should break up the patch into smaller, logical 
pieces and file one bug per patch on .  (Make sure to 
set the "review?" flag on the patch so that we'll find it for review.)

For others on webkit-dev, I found these links about the Maxthon browser to be 
informative:




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

Re: [webkit-dev] How to add Maxthon's port.

[David Kilzer]

The Haiku port is
Submitting their patches now.
See the details here.

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

Dave





From: zengweihong 
To: bfulg...@gmail.com
Cc: webkit ; opensou...@maxthon.net
Sent: Monday, June 29, 2009 6:52:04 PM
Subject: Re: [webkit-dev] How to add Maxthon's port.

 
After we submit source code to the official, we'll introduce Maxthon 3 browser 
on our website.

Best regards,
weihong.zeng

> Date: Mon, 29 Jun 2009 14:20:43 -0700
> Subject: Re: [webkit-dev] How to add Maxthon's port.
> From: bfulg...@gmail.com
> To: weihong.z...@hotmail.com
> CC: webkit-dev@lists.webkit.org
> 
> 2009/6/29 zengweihong :
> > Hi,
> >
> > We're using webkit in Maxthon3.0 and want to submit our changes.
> > How to add maxthon's port?
> 
> Are the sources to the Maxthon WebKit available somewhere?  I couldn't
> find any link on the http://www.maxthon.com/ site.
> 
> Thanks,
> 
> -Brent


把MSN装进手机，更多聊天乐趣等你挖掘！ 立刻下载！ ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [Request] "Remember me" check button in bugzilla homepage.

[David Kilzer]

This will happen when we upgrade to Bugzilla 3.2.x, which should be very soon!

Dave





From: tonikitoo (Antonio Gomes) 
To: webkit-dev Development 
Sent: Wednesday, July 1, 2009 8:04:25 AM
Subject: [webkit-dev] [Request] "Remember me" check button in bugzilla homepage.

Could we get the basic "remember me" check button available at login
time in bugs.webkit.org  login page ?

It is kind of annoying have to perform login all the time I revisit
the page after relaunching my browser ...

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

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

[webkit-dev] Scheduled downtime for bugs.webkit.org on Thu, 02 Jul, 2009 at 7:00 PM PDT (-0700)

[David Kilzer]

The bugs.webkit.org server will be down for maintenance starting at 7:00 PM PDT 
(-0700) on Thursday, July 2, 2009 for a Bugzilla upgrade.  We expect the server 
to be down for about 30 minutes.



Apologies in advance for any inconvenience this may cause.

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

Re: [webkit-dev] Scheduled downtime for bugs.webkit.org on Thu, 02 Jul, 2009 at 7:00 PM PDT (-0700)

[David Kilzer]

The UTF-8 upgrade of the database takes much longer than expected.  The 
downtime may be closer to 45 minutes.

Dave





From: David Kilzer 
To: webkit-dev@lists.webkit.org
Sent: Wednesday, July 1, 2009 11:32:02 AM
Subject: [webkit-dev] Scheduled downtime for bugs.webkit.org on Thu, 02 Jul, 
2009 at 7:00 PM PDT (-0700)


The bugs.webkit.org server will be down for maintenance starting at 7:00 PM PDT 
(-0700) on Thursday, July 2, 2009 for a Bugzilla upgrade.  We expect the server 
to be down for about 30 minutes.

<https://bugs.webkit.org/show_bug.cgi?id=17457>

Apologies in advance for any inconvenience this may cause.

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

[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

[David Kilzer]

On Friday, July 3, 2009 3:20:58 AM, Alexey Proskuryakov wrote:

> 02.07.2009, в 18:05, Adam Roben написал(а):
> 
> > 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
> > +
> 
> FWIW, I rarely need to know the bug number alone - I need its
> URL to click or to copy/paste. On the other hand, the
> suggested format makes it so that one needs to skip over "Part
> of Bug 25294: " just to read the bug description, which is not
> an improvement.

This probably isn't a typical example since it's a "Part N of M" bug fix, but 
the important part is that the change is summarized on the first line (after 
the date and patch author) to give a quick overview of the patch.

> >>- I like putting angle brackets "<>" around the URL to set
> >>it off visually from other text.
> 
> Typing those brackets is more work. It's also more difficult
> to copy/paste the URL (you could just copy the whole line and
> paste it into Safari address bar when there were no garbage
> symbols around the URL)


Actually, Safari will strip the "<>" characters for you if you paste them into 
the address bar!  I didn't know this until a couple of months ago, either.

Dave

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

Re: [webkit-dev] ChangeLog

[David Kilzer]

On Friday, July 3, 2009 1:01:33 PM, Joe Mason wrote:


> Even if sticking with svn, you just need to run svn2cl once when
> you update to  get a local copy of the changelog.


If each developer had to run that command to get a local changelog, I can't 
imagine the svn server would be very responsive if two or more people ran it at 
the same time.

Also, if you're already disconnected from the network, it's "too late" to run 
svn2cl if you want the full history.

--

Personally, I think git is the long-term solution since (a) git-format-patch 
includes the commit log comments in the patch format, which makes them easily 
reviewable and (b) it operates in an off-line mode making not only the log 
comments but the full repository history available.

However, not everyone on the project is comfortable with git (or is willing to 
give up svn), so I don't see a near-term solution at the moment other than 
improving the existing tools (prepare-ChangeLog, resolve-ChangeLogs, etc.).

Finally, I should note that I've found the detailed ChangeLogs created by 
prepare-ChangeLog--and written with the correct level of detail--to be 
extremely valuable in the past, especially when merging commits to a port.  I 
don't think these should ever go away.

Dave

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