Re: [webkit-dev] Table hit testing

[Roland Steiner]

AFAICT you could have an arbitrary number up to the width or height of the
table, whichever is smaller, by combining row- and colspans - e.g. with 3
([v]aligns just to emphasize the overlapping):


R1C1R1C2\\
R2C1//



- Roland

On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel  wrote:

> Hi David,
>
> Just so I'm certain, there's no way for more than two cells to overlap in a
> single grid slot, is there?
>
> Thanks,
>
> Fady Samuel
>
>
> On Thu, May 20, 2010 at 4:43 PM, David Hyatt  wrote:
>
>> On May 20, 2010, at 3:38 PM, Fady Samuel wrote:
>>
>> > So what are the rules for stacking here? do the cells stack in the order
>> in which they appear in the HTML?
>> >
>>
>> Correct, although note that backgrounds paint behind foregrounds, and hit
>> testing works the same way, so it's not as simple as saying that cell 7 is
>> always above cell 5.  They're interleaved, so from bottom to top:
>>
>> Cell 5 background
>> Cell 7 background
>> Cell 5 foreground (the number "5" in this example)
>> Cell 7 foreground (the number "7" in this example)
>>
>> That's why if you hover over the actual number 5 in that example it will
>> light up, but if you're in the background area overlap, the number 7 will
>> light up.
>>
>> http://www.w3.org/TR/CSS21/zindex.html
>>
>> Therefore you do have to know about all the cells at the position, since
>> when you're in the "foreground" phase of hit testing, cell 7 will say "Nope,
>> you're not inside my foreground", and so you then need to check cell 5,
>> which will say "Yes, you are inside my foreground."
>>
>> The grid structure just isn't expressive enough.  It needs to be patched
>> to track all cells in a given row/column instead of just the first one.
>>
>> dave
>> (hy...@apple.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] 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] Gtk 32-bit Release Bot Wedged

[Adrian Perez]

On Thu, 20 May 2010 12:54:53 -0700
Eric Seidel  wrote:

> We have various other bot support tools checked in under:
> http://trac.webkit.org/browser/trunk/WebKitTools/BuildSlaveSupport/
> and
> http://trac.webkit.org/browser/trunk/WebKitTools/EWSTools
> 
> You should feel encouraged to add more.

Done, I have uploaded the patch to Bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=40053

Hope it helps :)


> On Thu, May 20, 2010 at 12:52 PM, Adrian Perez 
> wrote:
> > On Thu, 20 May 2010 11:12:01 -0300
> > Gustavo Noronha Silva  wrote:
> >
> >> On Thu, 2010-05-20 at 00:20 -0700, Eric Seidel wrote:
> >> > The Gtk 32-bit Release bot has wedged itself.  If someone could
> >> > kick it that would be grand:
> >> > http://build.webkit.org/results/GTK%20Linux%2032-bit%20Release/r59822%20(13001)/results.html
> >> >
> >> > Do we understand why this happens so we can prevent it in the
> >> > future (this is not the first time)?
> >>
> >> I kicked it. What happened was pulseaudio died. What I'll do is
> >> I'll have a daemon monitor make sure the pulseaudio server is
> >> running at all times, and automatically restart it if it drops
> >> again, since I could not investigate this bug.
> >
> > When we set up the Gtk+ debug bots, I was a bit concerned about the
> > fact that Pulseaudio or Xvfb could die, so I decided to run them
> > under daemontools [1], which nicely restarts services when they
> > crash. I can share the supervise scripts if, just ask if you want
> > to a similar setup. Also, we ended up running Buildbot itself and a
> > small crash dump grabber under daemontools, too.
> >
> > Cheers,
> >
> >
> > ---
> > [1] http://cr.yp.to/daemontools.html
> >
> > --
> > Adrian Perez 
> > Igalia - Free Software Engineering
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> 



-- 
Adrian Perez 
Igalia - Free Software Engineering


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

Re: [webkit-dev] Table hit testing

[Fady Samuel]

Ohh, I see, thanks Roland.

Fady

On Wed, Jun 2, 2010 at 3:25 AM, Roland Steiner wrote:

> AFAICT you could have an arbitrary number up to the width or height of the
> table, whichever is smaller, by combining row- and colspans - e.g. with 3
> ([v]aligns just to emphasize the overlapping):
>
> 
> R1C1R1C2\\
> R2C1 valign=bottom>//
> 
> 
>
> - Roland
>
> On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel  wrote:
>
>> Hi David,
>>
>> Just so I'm certain, there's no way for more than two cells to overlap in
>> a single grid slot, is there?
>>
>> Thanks,
>>
>> Fady Samuel
>>
>>
>> On Thu, May 20, 2010 at 4:43 PM, David Hyatt  wrote:
>>
>>> On May 20, 2010, at 3:38 PM, Fady Samuel wrote:
>>>
>>> > So what are the rules for stacking here? do the cells stack in the
>>> order in which they appear in the HTML?
>>> >
>>>
>>> Correct, although note that backgrounds paint behind foregrounds, and hit
>>> testing works the same way, so it's not as simple as saying that cell 7 is
>>> always above cell 5.  They're interleaved, so from bottom to top:
>>>
>>> Cell 5 background
>>> Cell 7 background
>>> Cell 5 foreground (the number "5" in this example)
>>> Cell 7 foreground (the number "7" in this example)
>>>
>>> That's why if you hover over the actual number 5 in that example it will
>>> light up, but if you're in the background area overlap, the number 7 will
>>> light up.
>>>
>>> http://www.w3.org/TR/CSS21/zindex.html
>>>
>>> Therefore you do have to know about all the cells at the position, since
>>> when you're in the "foreground" phase of hit testing, cell 7 will say "Nope,
>>> you're not inside my foreground", and so you then need to check cell 5,
>>> which will say "Yes, you are inside my foreground."
>>>
>>> The grid structure just isn't expressive enough.  It needs to be patched
>>> to track all cells in a given row/column instead of just the first one.
>>>
>>> dave
>>> (hy...@apple.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

[webkit-dev] XMLHttpRequest memoryleak

[Patrick Roland Gansterer]

Hi,

I think WebKit (with JSC) leaks memory for every XMLHttpRequest and I need
to fix this problem.
Can somebody give me a hint where I should start?

My testpage (http://paroga.com/webkit/memory.htm) only creates a request
every second. 
Safari on windows "leaks" about 60KB/minute. QtBrowser on WinCE needs
about 4KB/minute.

I don't think that my values are correct, because of the garbage
collector.
Is there any easy way to dump a list of all used javascript objects (and
references)?
Can I trigger the GarbageCollecter manually to get the real memory usage?

Maybe related bugs:
https://bugs.webkit.org/show_bug.cgi?id=17534
https://bugs.webkit.org/show_bug.cgi?id=27041

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

[イアンフェッティ]

Zip files cannot be streamed (there was a good discussion in [1], so you are
unable to do any operations on the data until the entire .zip file has been
received as the central directory comes at the end. Aside from that, what if
you want to upload a large amount of already compressed files, e.g. a bunch
of JPEGs or MP3s? Zipping them won't actually do much, but it could be a
nontrivial cost in terms of cpu, memory, or both, and would introduce
unnecessary delay. On the server side, this would then require someone to
deal with zip files, and again deal with it as a big chunk rather than
acting on individual files as they come in.

I think the approach taken with  is preferable, and
this seems like a natural extension of that, so I don't see why one would go
back to zip files.

-Ian

[1] http://www.mail-archive.com/public-weba...@w3.org/msg08457.html

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
>>>
>>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http

Re: [webkit-dev] XMLHttpRequest memoryleak

[Mike Marchywka]

> Date: Wed, 2 Jun 2010 15:55:03 +0200
> From: par...@paroga.com
> To: webkit-dev@lists.webkit.org
> Subject: [webkit-dev] XMLHttpRequest memoryleak
>
> Hi,
>
> I think WebKit (with JSC) leaks memory for every XMLHttpRequest and I need
> to fix this problem.
> Can somebody give me a hint where I should start?

I haven't looked at this issue or many code details but on an intial
look and some test builds, it seems ref counted smart pointers
are used everywhere.  Coming from java I can understand the attraction
but they don't just automtically fix anything. Indeed, I spend
more time waiting for VM thrashing in firexfox and icwesel
than I do surfing sometimes as memory usage creeps up.

I guess I would ask if you can empirically relate your test pages
to a memory leak- can you say that simple html lacking javascript
is leak free? Can you generally isolate the leak to JS?

Now the problem with a memory leak,long before you run out of
memory, is performance. Can you or do you have any info on page faults?
I guess you expect these to happen but I'm seeing stuff that looks like 
thrashing,
it isn't like all the stale stuff if on a page that just gets swapped out and
forgotten. 

Thanks. 

>
> My testpage (http://paroga.com/webkit/memory.htm) only creates a request
> every second.
> Safari on windows "leaks" about 60KB/minute. QtBrowser on WinCE needs
> about 4KB/minute.
>
> I don't think that my values are correct, because of the garbage
> collector.
> Is there any easy way to dump a list of all used javascript objects (and
> references)?
> Can I trigger the GarbageCollecter manually to get the real memory usage?
>
> Maybe related bugs:
> https://bugs.webkit.org/show_bug.cgi?id=17534
> https://bugs.webkit.org/show_bug.cgi?id=27041
>
> - Patrick
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
  
_
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with 
Hotmail. 
http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How to convert character offset into VisiblePosition?

[Dan Bernstein]

On Jun 1, 2010, at 10:48 PM, Xiaomei Ji wrote:

> 
> Given a DOM Node and an InlineBox, is there a way to convert the character 
> offset within this InlineBox to a VisiblePosition? considering bidi/RTL.

Not sure how being given a DOM node helps here…

> 
> Using  node in the following example as an example:
> abc ששש def שנב abc סטז uvw 
> זזז xyz 
> Assume the  node is node A, using "(node, offset)a" to represent the 
> node and offset information of Position when caret is before character "a", 
> the position information are:
> .. (A, 4)a(A, 5)b(A, 6)c(A, 7) (A, 0xb)ז(A, 0xa)ט(A, 9)ס(A, 8).
>   
> Given the  node, the InlineBox representing " abc "(with surrounding 
> spaces), and character offset 5 within the InlineBox, is there a way to 
> convert offset 5 into VisiblePosition (A, 0xb) (not (A, 8))? which means when 
> caret is placed after the 2nd space in " abc ", the visible position is (A, 
> 0xb).

I don’t think there’s code to do this—hit testing code will just choose the DOM 
offset that corresponds to the line box you hit—but how about something like 
this?

If the offset is not at the edge of the text box, then just map it to that 
box’s text node
Otherwise, if there is an adjacent text box on that edge, and it has the same 
direction as the first text box, just map to the first text box’s text node 
(or, perhaps you should look at the bidi levels of both boxes and choose the 
one with the higher level?)
Otherwise, of the two adjacent text boxes, choose the one whose direction is 
equal to the block direction, and return an offset into the chosen box’s text 
node, corresponding to the edge

Does this cover all cases?___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Style question: static, protected, or public members

[Darin Adler]

On Jun 1, 2010, at 10:09 PM, Eric Seidel wrote:

> Let me summarize to see if I understand what should be updated in the style 
> guide/check-webkit-style:
> 
> Class static member variables should have an s_ prefix.
> Protected and public member variables should be disallowed.
> Private member variables should have an m_ prefix.
> Struct member variables should have no prefix.

Yes, I think that’s what we discussed. While I don’t love the “s_” prefix, I 
didn’t love the “m_” one either, and I got used to it.

> What about global statics?  Currently I believe most have no prefix. Some 
> have "k" or "g".

We didn’t discuss global variables outside of a class. If we decided to start 
using a prefix, I’d suggest “g_” but I don’t think we need one. What do other 
people think?

-- Darin

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

Re: [webkit-dev] XMLHttpRequest memoryleak

[Alexey Proskuryakov]

02.06.2010, в 6:55, Patrick Roland Gansterer написал(а):

I think WebKit (with JSC) leaks memory for every XMLHttpRequest and  
I need

to fix this problem.
Can somebody give me a hint where I should start?



I don't think this has been fully investigated, but the current theory  
is that the memory is used by Safari Activity window, see .


- WBR, Alexey Proskuryakov

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

Re: [webkit-dev] XMLHttpRequest memoryleak

[Patrick Roland Gansterer]

On Wed, 02 Jun 2010 10:07:59 -0700, Alexey Proskuryakov 
wrote:
> 02.06.2010, в 6:55, Patrick Roland Gansterer написал(а):
> 
>> I think WebKit (with JSC) leaks memory for every XMLHttpRequest and  
>> I need
>> to fix this problem.
>> Can somebody give me a hint where I should start?
> 
> 
> I don't think this has been fully investigated, but the current theory  
> is that the memory is used by Safari Activity window, see
> .
How can I do further investigations? Where is the best point to start in
the source code?
I don't undersand why WebKit needs additional memory for every
XMLHttpRequest. What is the memory used for?

Mike Marchywka:
> I guess I would ask if you can empirically relate your test pages
> to a memory leak- can you say that simple html lacking javascript
> is leak free? Can you generally isolate the leak to JS?
The leak occurs only when I use the XMLHttpRequest. E.g. a setTimeout
seams to cost no memory.

> Can you or do you have any info on page faults?
Safari.exe has about 300.000 page faults.

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

[Sam Weinig]

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
>>>
>>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)

[Sam Weinig]

Now that I have had a little time to think about it, I think my biggest
concern with this type of API is the unintentional ability for an attacker
to gain information from the engine consuming specifics amount of memory.
 Let's take the visited link history stealing attack as an example.  Even
though you can no longer use getComputedStyle() directly to gain information
as to whether a link was visited or not, if the engine allocated subtly
different amounts of memory depending on whether the link was visited or
not, an attacker could detect this and gain that information.

Adam (and other web security people), am I being overly paranoid about this?

-Sam

On Fri, May 28, 2010 at 10:56 AM, Mikhail Naganov wrote:

> Greetings, WebKit deveopers,
>
> As a response to requests from web apps developers, I was intended to
> add a simple API for accessing web app's memory consumption, see
> https://bugs.webkit.org/show_bug.cgi?id=39646
>
> The scenario of using this API is as follows:
>  - a builbot runs web app's common usage scenarios tests;
>  - inside tests, memory usage is recorded via the API proposed;
>  - the results are sent to a server (using XHR or a CGI request);
>  - server plots nice graphs of memory usage status, bound to the
> changes made to the web app;
>  - thus, if someone does a change that blows up memory usage,
> developers will notice.
>
> As Sam points out, this change may be fine, but he suggests to make it
> accessible only when a browser runs in a special "developer" mode.
> This can also be applied to the whole 'console' object.
>
> Please, share your thoughts on this.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)

[Adam Barth]

I haven't looked into the details, but, in general, side channel
information is a rich area for unintentional disclosure.  For example,
timing information leaks a ton of information.

Here's a recent paper that shows a bunch of stuff you can use from the
sizes of things.  In this case, they're looking at the size on the
wire, but you could imagine something similar for in-memory size:

http://oakland31.cs.virginia.edu/slides/sidechannel.pdf

Adam


On Wed, Jun 2, 2010 at 11:52 AM, Sam Weinig  wrote:
> Now that I have had a little time to think about it, I think my biggest
> concern with this type of API is the unintentional ability for an attacker
> to gain information from the engine consuming specifics amount of memory.
>  Let's take the visited link history stealing attack as an example.  Even
> though you can no longer use getComputedStyle() directly to gain information
> as to whether a link was visited or not, if the engine allocated subtly
> different amounts of memory depending on whether the link was visited or
> not, an attacker could detect this and gain that information.
> Adam (and other web security people), am I being overly paranoid about this?
> -Sam
>
> On Fri, May 28, 2010 at 10:56 AM, Mikhail Naganov 
> wrote:
>>
>> Greetings, WebKit deveopers,
>>
>> As a response to requests from web apps developers, I was intended to
>> add a simple API for accessing web app's memory consumption, see
>> https://bugs.webkit.org/show_bug.cgi?id=39646
>>
>> The scenario of using this API is as follows:
>>  - a builbot runs web app's common usage scenarios tests;
>>  - inside tests, memory usage is recorded via the API proposed;
>>  - the results are sent to a server (using XHR or a CGI request);
>>  - server plots nice graphs of memory usage status, bound to the
>> changes made to the web app;
>>  - thus, if someone does a change that blows up memory usage,
>> developers will notice.
>>
>> As Sam points out, this change may be fine, but he suggests to make it
>> accessible only when a browser runs in a special "developer" mode.
>> This can also be applied to the whole 'console' object.
>>
>> Please, share your thoughts on this.
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

Hi,

As most of you have experienced, the precision of a mouse click on
Desktop applications, including Web browsers, is much higher than the
precision of a touch tap on a mobile device. It is not a new problem,
and many solutions have been proposed to improve that situation. One
of the common solutions is to make a small target’s tap-sensitive area
larger, invisibly, than the visible target itself. Of course, it would
not work on a mobile Web browser, since it'd end up breaking the
desired layout of any non-simple Web site.

Mozilla has addressed this problem by implementing the SmartTap
feature [1]. The solution is simple: a "nodesFromRect" method is
available for applications {fennec, firefox, etc}. As the name
implies, given a rect (corresponding to tapped area), it returns a
list of candidate "mouse clickable" target nodes for the tap. This
list is sorted by z-order, larger intersection area, most visited (in
case of links), etc. Call sites can then pick the first element on the
list, or use any different heuristic to choose the target.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=489127

After some initial research, mostly understanding the HitTest system
of WebCore, I am sure we can provide something similar as a cross
platform solution for the problem.

For the moment, my plan is to use better hit testing to make it easier
for users to click & focus hyperlinks and input fields. For that, the
HitTest system would have to be modified to receive a Rect as input,
instead of a Point. It would also have to hold a list of possible
target candidate nodes, instead of only a single target node as it
does currently. In deep, the many ::nodeAtPoint implementations would
have to be adjusted to work with a Rect, not a Point, and probably
renamed to something similar to nodesAtRect. Much of the current
HitTest logic in RenderLayer would not need changes, though.

To keep the current mouse behavior (which is clearly point-based), we
could just pass rects with width and height equal to 1, so a Rect(x,
y, 1, 1) would behavior equally or very similarly to Point(x, y).

Before going this way, I would like to know of any known problem or
show stoppers.

Cheers,

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

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[David Hyatt]

On Jun 2, 2010, at 2:46 PM, Antonio Gomes (:tonikitoo) wrote:

> Hi,
> 
> As most of you have experienced, the precision of a mouse click on
> Desktop applications, including Web browsers, is much higher than the
> precision of a touch tap on a mobile device. It is not a new problem,
> and many solutions have been proposed to improve that situation. One
> of the common solutions is to make a small target’s tap-sensitive area
> larger, invisibly, than the visible target itself. Of course, it would
> not work on a mobile Web browser, since it'd end up breaking the
> desired layout of any non-simple Web site.
> 
> Mozilla has addressed this problem by implementing the SmartTap
> feature [1]. The solution is simple: a "nodesFromRect" method is
> available for applications {fennec, firefox, etc}. As the name
> implies, given a rect (corresponding to tapped area), it returns a
> list of candidate "mouse clickable" target nodes for the tap. This
> list is sorted by z-order, larger intersection area, most visited (in
> case of links), etc. Call sites can then pick the first element on the
> list, or use any different heuristic to choose the target.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=489127
> 
> After some initial research, mostly understanding the HitTest system
> of WebCore, I am sure we can provide something similar as a cross
> platform solution for the problem.
> 
> For the moment, my plan is to use better hit testing to make it easier
> for users to click & focus hyperlinks and input fields. For that, the
> HitTest system would have to be modified to receive a Rect as input,
> instead of a Point. It would also have to hold a list of possible
> target candidate nodes, instead of only a single target node as it
> does currently. In deep, the many ::nodeAtPoint implementations would
> have to be adjusted to work with a Rect, not a Point, and probably
> renamed to something similar to nodesAtRect. Much of the current
> HitTest logic in RenderLayer would not need changes, though.
> 
> To keep the current mouse behavior (which is clearly point-based), we
> could just pass rects with width and height equal to 1, so a Rect(x,
> y, 1, 1) would behavior equally or very similarly to Point(x, y).
> 
> Before going this way, I would like to know of any known problem or
> show stoppers.

I really don't think hit testing needs to be modified to get what you want.  
You can do a scattershot sampling using multiple candidate points within the 
rect and apply whatever heuristics you want to choose a node.  I'm also not 
convinced that we should be complicating core hit testing code in this way, 
since I suspect this is one of those areas where mobile platforms will each 
want to do their own slightly different thing anyway.

dave
(hy...@apple.com)

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

Re: [webkit-dev] Table hit testing

[Fady Samuel]

So I have completed all the following things locally:

* First fix the grid to record all the cells at a given position.  This
fixes a repaint bug.
* Then change the hit-testing to work just like painting.  This makes hit
testing more efficient and ensures hit testing and painting agree.
* Then optimize hit-testing to binary-search if there are no overflowing
cells.  (And optimize painting similarly)
* Fix a table layout bug
* created a bunch of additional simple table layout tests

I did all the pieces locally first to make sure I understand how all the
parts of table rendering fit together. However, I intend to get the pieces
of this work out in in smaller patches to simplify the review process for
reviewers.

While I still have some more work to do testing, and splitting my work up
into the suggested pieces, please expect bug reports and proposed patches to
begin appearing shortly (within the next couple of days or so).

Thanks,

Fady Samuel


On Wed, Jun 2, 2010 at 7:34 AM, Fady Samuel  wrote:

> Ohh, I see, thanks Roland.
>
> Fady
>
>
> On Wed, Jun 2, 2010 at 3:25 AM, Roland Steiner 
> wrote:
>
>> AFAICT you could have an arbitrary number up to the width or height of the
>> table, whichever is smaller, by combining row- and colspans - e.g. with 3
>> ([v]aligns just to emphasize the overlapping):
>>
>> 
>> R1C1R1C2\\
>> R2C1> valign=bottom>//
>> 
>> 
>>
>> - Roland
>>
>> On Wed, Jun 2, 2010 at 8:58 AM, Fady Samuel  wrote:
>>
>>> Hi David,
>>>
>>> Just so I'm certain, there's no way for more than two cells to overlap in
>>> a single grid slot, is there?
>>>
>>> Thanks,
>>>
>>> Fady Samuel
>>>
>>>
>>> On Thu, May 20, 2010 at 4:43 PM, David Hyatt  wrote:
>>>
 On May 20, 2010, at 3:38 PM, Fady Samuel wrote:

 > So what are the rules for stacking here? do the cells stack in the
 order in which they appear in the HTML?
 >

 Correct, although note that backgrounds paint behind foregrounds, and
 hit testing works the same way, so it's not as simple as saying that cell 7
 is always above cell 5.  They're interleaved, so from bottom to top:

 Cell 5 background
 Cell 7 background
 Cell 5 foreground (the number "5" in this example)
 Cell 7 foreground (the number "7" in this example)

 That's why if you hover over the actual number 5 in that example it will
 light up, but if you're in the background area overlap, the number 7 will
 light up.

 http://www.w3.org/TR/CSS21/zindex.html

 Therefore you do have to know about all the cells at the position, since
 when you're in the "foreground" phase of hit testing, cell 7 will say 
 "Nope,
 you're not inside my foreground", and so you then need to check cell 5,
 which will say "Yes, you are inside my foreground."

 The grid structure just isn't expressive enough.  It needs to be patched
 to track all cells in a given row/column instead of just the first one.

 dave
 (hy...@apple.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] Proposal: Rect based HitTest for a better touch experience

[David Hyatt]

On Jun 2, 2010, at 3:22 PM, David Hyatt wrote:

>> 
>> Before going this way, I would like to know of any known problem or
>> show stoppers.
> 
> I really don't think hit testing needs to be modified to get what you want.  
> You can do a scattershot sampling using multiple candidate points within the 
> rect and apply whatever heuristics you want to choose a node.  I'm also not 
> convinced that we should be complicating core hit testing code in this way, 
> since I suspect this is one of those areas where mobile platforms will each 
> want to do their own slightly different thing anyway.

This sounded a bit more negative than I intended.  I don't mind hit testing 
being modified in this way as long as we think we can make it truly 
cross-platform (such that everyone who wants similar functionality can use the 
code), and it would be very important to not regress the single point case.  If 
those conditions can be met, then I would be satisfied.

dave


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

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

Hi David.

Although I understand your concern, however I still do not think the
change would complicate things that much, but basically extend the
current support.

For example, in

bool InlineTextBox::nodeAtPoint(const HitTestRequest&, HitTestResult&
result, int x, int y, int tx, int ty)
{
(...)
IntRect rect(tx + m_x, ty + m_y, m_width, height());
if (m_truncation != cFullTruncation && visibleToHitTesting() &&
rect.contains(x, y)) {
renderer()->updateHitTestResult(result, IntPoint(x - tx, y - ty));
(...)
}

"rect.contains(x, y)" would have to be "rect.intersects(myRect)" and
things like that. (of course, not only that).

To simplify stuff, any sorting mechanism I mentioned on my previous
email could be left to the callers, and so. If a port do not want to
take advantage of the new support, the current functionality should
and would be kept, i.e. Rect(x,y,1,1,) would do the trick.

I can certainly prototype something to see the idea in practice before
any final judgment, if you prefer.

Cheers,

On Wed, Jun 2, 2010 at 5:22 PM, David Hyatt  wrote:
> On Jun 2, 2010, at 2:46 PM, Antonio Gomes (:tonikitoo) wrote:
>
>> Hi,
>>
>> As most of you have experienced, the precision of a mouse click on
>> Desktop applications, including Web browsers, is much higher than the
>> precision of a touch tap on a mobile device. It is not a new problem,
>> and many solutions have been proposed to improve that situation. One
>> of the common solutions is to make a small target’s tap-sensitive area
>> larger, invisibly, than the visible target itself. Of course, it would
>> not work on a mobile Web browser, since it'd end up breaking the
>> desired layout of any non-simple Web site.
>>
>> Mozilla has addressed this problem by implementing the SmartTap
>> feature [1]. The solution is simple: a "nodesFromRect" method is
>> available for applications {fennec, firefox, etc}. As the name
>> implies, given a rect (corresponding to tapped area), it returns a
>> list of candidate "mouse clickable" target nodes for the tap. This
>> list is sorted by z-order, larger intersection area, most visited (in
>> case of links), etc. Call sites can then pick the first element on the
>> list, or use any different heuristic to choose the target.
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=489127
>>
>> After some initial research, mostly understanding the HitTest system
>> of WebCore, I am sure we can provide something similar as a cross
>> platform solution for the problem.
>>
>> For the moment, my plan is to use better hit testing to make it easier
>> for users to click & focus hyperlinks and input fields. For that, the
>> HitTest system would have to be modified to receive a Rect as input,
>> instead of a Point. It would also have to hold a list of possible
>> target candidate nodes, instead of only a single target node as it
>> does currently. In deep, the many ::nodeAtPoint implementations would
>> have to be adjusted to work with a Rect, not a Point, and probably
>> renamed to something similar to nodesAtRect. Much of the current
>> HitTest logic in RenderLayer would not need changes, though.
>>
>> To keep the current mouse behavior (which is clearly point-based), we
>> could just pass rects with width and height equal to 1, so a Rect(x,
>> y, 1, 1) would behavior equally or very similarly to Point(x, y).
>>
>> Before going this way, I would like to know of any known problem or
>> show stoppers.
>
> I really don't think hit testing needs to be modified to get what you want.  
> You can do a scattershot sampling using multiple candidate points within the 
> rect and apply whatever heuristics you want to choose a node.  I'm also not 
> convinced that we should be complicating core hit testing code in this way, 
> since I suspect this is one of those areas where mobile platforms will each 
> want to do their own slightly different thing anyway.
>
> dave
> (hy...@apple.com)
>
>



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

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Peter Kasting]

On Wed, Jun 2, 2010 at 1:52 PM, Antonio Gomes (:tonikitoo) <
toniki...@gmail.com> wrote:

> If a port do not want to
> take advantage of the new support, the current functionality should
> and would be kept, i.e. Rect(x,y,1,1,) would do the trick.


Be careful to check whether you really want 1, 1 or 0, 0 as the size in your
new API.

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

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[David Hyatt]

He would want 1,1.

dave

On Jun 2, 2010, at 3:58 PM, Peter Kasting wrote:

> On Wed, Jun 2, 2010 at 1:52 PM, Antonio Gomes (:tonikitoo) 
>  wrote:
> If a port do not want to
> take advantage of the new support, the current functionality should
> and would be kept, i.e. Rect(x,y,1,1,) would do the trick.
> 
> Be careful to check whether you really want 1, 1 or 0, 0 as the size in your 
> new API.
> 
> PK 
> ___
> 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] On adding 'console.memory' API (and about the whole 'console' object.)

[Mikhail Naganov]

Used memory count can be restricted to include only objects reachable
from the caller execution context. In this case, an app could only see
the amount of memory consumed by itself, not by the whole engine.

Another option, as Sam proposed before, is to expose things like
console.profiles and console.memory only when a browser is launched in
"developer" mode. Although, this still opens the way to unintentional
information disclosure when a developer forgets that she is running
the browser in this mode.

On Wed, Jun 2, 2010 at 23:06, Adam Barth  wrote:
> I haven't looked into the details, but, in general, side channel
> information is a rich area for unintentional disclosure.  For example,
> timing information leaks a ton of information.
>
> Here's a recent paper that shows a bunch of stuff you can use from the
> sizes of things.  In this case, they're looking at the size on the
> wire, but you could imagine something similar for in-memory size:
>
> http://oakland31.cs.virginia.edu/slides/sidechannel.pdf
>
> Adam
>
>
> On Wed, Jun 2, 2010 at 11:52 AM, Sam Weinig  wrote:
>> Now that I have had a little time to think about it, I think my biggest
>> concern with this type of API is the unintentional ability for an attacker
>> to gain information from the engine consuming specifics amount of memory.
>>  Let's take the visited link history stealing attack as an example.  Even
>> though you can no longer use getComputedStyle() directly to gain information
>> as to whether a link was visited or not, if the engine allocated subtly
>> different amounts of memory depending on whether the link was visited or
>> not, an attacker could detect this and gain that information.
>> Adam (and other web security people), am I being overly paranoid about this?
>> -Sam
>>
>> On Fri, May 28, 2010 at 10:56 AM, Mikhail Naganov 
>> wrote:
>>>
>>> Greetings, WebKit deveopers,
>>>
>>> As a response to requests from web apps developers, I was intended to
>>> add a simple API for accessing web app's memory consumption, see
>>> https://bugs.webkit.org/show_bug.cgi?id=39646
>>>
>>> The scenario of using this API is as follows:
>>>  - a builbot runs web app's common usage scenarios tests;
>>>  - inside tests, memory usage is recorded via the API proposed;
>>>  - the results are sent to a server (using XHR or a CGI request);
>>>  - server plots nice graphs of memory usage status, bound to the
>>> changes made to the web app;
>>>  - thus, if someone does a change that blows up memory usage,
>>> developers will notice.
>>>
>>> As Sam points out, this change may be fine, but he suggests to make it
>>> accessible only when a browser runs in a special "developer" mode.
>>> This can also be applied to the whole 'console' object.
>>>
>>> Please, share your thoughts on this.
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Proposal: Link http header support

[蓋文彼德斯]

Hi,

I'm starting hacking at adding support for the Link: http header.  This is
described in RFC 2068, although not RFC 2616.  As well, there's a current
internet draft describing it:
http://tools.ietf.org/id/draft-nottingham-http-link-header-10.html .  This
header is being discussed in the IETF HTTP WG mailing list.  Since it was in
HTTP 1.1 as first published, it is reserved, and legal to use today for this
purpose.

The HTTP Link header should be treated nearly identically to an HTML Link
element.  This means that guidance for stylesheet, subresource & stylesheet
loading can be provided to a browser before any parse of HTML has been
started.  Possibly a win.  Right now, Leon Clarke has a patch he's landing
for the link rel=prefetch case in HTML, see
https://bugs.webkit.org/show_bug.cgi?id=3652 .  I'd like to code this up for
headers as well.

At first, I'd like to take a relatively simpleminded approach.  I don't want
to carry forward DOM implications of the HTTP header (i.e. i'll ignore an
onload attribute), and I don't think I'll share much code with
HTMLLinkElement.cpp.  However, I'm open to feedback on this.  I intend to
catch a few simple rel cases (subresource, prefetch & stylesheet) and launch
appropriately prioritized resource requests.

Any thoughts?

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

[webkit-dev] IDL attribute vs Content attribute?

[Prasad Tammana]

I'm looking at the HTML5 spec for the command element and it talks about IDL
attributes vs Content attributes?  What does each mean?

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

Re: [webkit-dev] IDL attribute vs Content attribute?

[TAMURA, Kent]

http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#terminology

IDL attributes mean properties of JavaScript objects defined by IDLs.
Content attributes mean HTML/XML attributes.

2010/6/3 Prasad Tammana 


I'm looking at the HTML5 spec for the command element and it talks about
IDL attributes vs Content attributes?  What does each mean?



Thanks,
Prasad



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





--
TAMURA Kent
Software Engineer, Google



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

Re: [webkit-dev] Proposal: Link http header support

[Peter Kasting]

On Wed, Jun 2, 2010 at 3:28 PM, Gavin Peters (蓋文彼德斯) wrote:

> I'm starting hacking at adding support for the Link: http header.  This is
> described in RFC 2068, although not RFC 2616.  As well, there's a current
> internet draft describing it:
> http://tools.ietf.org/id/draft-nottingham-http-link-header-10.html .  This
> header is being discussed in the IETF HTTP WG mailing list.  Since it was in
> HTTP 1.1 as first published, it is reserved, and legal to use today for this
> purpose.
>

Is this supported in any other browsers?  Do websites make use of it?

I'm not saying you should necessarily stop if the answers are "no", but it's
good to know the lay of the land.

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

Re: [webkit-dev] How to handle a new protocol for Blob.url support?

[Darin Adler]

On Jun 1, 2010, at 5:14 PM, Jian Li wrote:

> I am working on Blob.url support as defined in the latest version of File API 
> (http://dev.w3.org/2006/webapi/FileAPI/). The Blob.url will return a URL that 
> can be used to refer to the blob object in a resource request, like 
> blobdata:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The blob object can represent 
> a whole file, a partial file (created by Blob.slice), or a byte array 
> (created by BlobBuilder defined in the FileWriter spec). What is the right 
> place I can hook up with in order to interpret and process the blobdata 
> request? Should it be in the WebKit library layer that will be implemented by 
> individual platform or in the higher layer like what application cache does 
> the work?

Definitely a higher level. We don’t want to have to reimplement a feature like 
this for each platform.

-- Darin

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

Re: [webkit-dev] IDL attribute vs Content attribute?

[Prasad Tammana]

Thanks Kent.  And thanks for the offline chat too!

On Wed, Jun 2, 2010 at 5:25 PM, TAMURA, Kent  wrote:

>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#terminology
>
> IDL attributes mean properties of JavaScript objects defined by IDLs.
> Content attributes mean HTML/XML attributes.
>
> 2010/6/3 Prasad Tammana 
>
>> I'm looking at the HTML5 spec for the command element and it talks about
>> IDL attributes vs Content attributes?  What does each mean?
>>
>> Thanks,
>> Prasad
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How to handle a new protocol for Blob.url support?

[Jian Li]

This will probably work for most of the platforms, except the one that uses
multi-process architecture. How do we handle the case that a page is trying
to access a blob URL that is created in another process (assume the
accessing page is in the same security domain)? I think for the platform,
like Chromium, we can choose to delegate to the host to do the right job,
while all other platforms will share the same handling logic defined at a
higher level.

In addition, we might need to hook up additional logic if we want to support
using it in the shared worker process.


On Wed, Jun 2, 2010 at 6:08 PM, Darin Adler  wrote:

> On Jun 1, 2010, at 5:14 PM, Jian Li wrote:
>
> I am working on Blob.url support as defined in the latest version of File
> API (http://dev.w3.org/2006/webapi/FileAPI/). The Blob.url will return a
> URL that can be used to refer to the blob object in a resource request, like
> blobdata:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The blob object can represent
> a whole file, a partial file (created by Blob.slice), or a byte array
> (created by BlobBuilder defined in the FileWriter spec). What is the right
> place I can hook up with in order to interpret and process the blobdata
> request? Should it be in the WebKit library layer that will be implemented
> by individual platform or in the higher layer like what application cache
> does the work?
>
>
> Definitely a higher level. We don’t want to have to reimplement a feature
> like this for each platform.
>
> -- Darin
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Making changes to our copy of the W3C CSS1 test suite

[Darin Adler]

On Jun 2, 2010, at 11:29 AM, Eric Seidel wrote:

> What's the process for making changes to those files?

Here’s how I think we should do it:

1) There’s one directory with a pristine copy of the W3C test suite, with 
no WebKit changes.
2) If there are some tests that need to be fixed, fixed copies of those 
individual tests would go into another directory.
3) The broken tests can be run as-is, and we can land expected results to 
reflect what the broken tests do.

Perhaps I would think differently about some aspect of this if we had 
introduced the “test expectations” concept for platforms other than Chromium.

> (Reminds me that we should move our "do not edit" layout tests to some 
> special place.)

As far as reorganizing LayoutTests is concerned, I think we definitely need to 
do it.

The name of the directory itself is wrong, since they are not really tests of 
“layout” any more.

There should be some set of tests that are faster to run that omits the slower 
thorough tests. This was the original goal of “fast” but we have put tests 
outside “fast” more or less at random. Why are “editing” tests outside “fast”? 
Just the whim of the person who added them. Same comment on directories like 
“accessibility”.

The test suites that are imported from elsewhere should go into directories 
with clear names such as:

ImportedTestSuites/W3C-CSS1

Rather than names like:

css1

There are other categories of tests with special requirements. The ones in 
“http” and the ones in “websocket”, so those should go into clearly-named 
directories too.

But I am loathe to reorganize the tests when new-run-webkit-tests is still 
coming soon. I’d love to only have one test script to modify if we change 
things about the test organization that require changing the script.

-- Darin

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

Re: [webkit-dev] About fixing "old" layout bugs

[Xianzhu Wang]

Hi,

I'm still wondering what the best practice is to deal with many updated
layout tests in a patch. It seems I must run the layout tests on all
effected platforms by myself to ensure a green build after committing the
patch, right? This is really difficult to me. Is there a easier way?

Thanks,
Xianzhu

2010/6/2 Xianzhu Wang 

> Hi,
>
> I'm new to webkit development, and I'd like to hear opinions about the
> problems I met.
>
> Now I'm trying to fix some "old" layout bugs, for example:
>   * white space preceding  (
> https://bugs.webkit.org/show_bug.cgi?id=37261)
>   * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413)
>   * line breaking around some punctuations (
> https://bugs.webkit.org/show_bug.cgi?id=37698)
>
> Some people have warned me about the difficulty of fixing these bugs, and
> now I have realized it. Fixing the bugs themselves is not very difficult,
> for example, only 2 functional lines change can fix the first bug. However,
> the change will break more than 4000 existing layout tests mostly because
> trailing spaces preceding s in current expectations of the tests (for
> example, "PASS " vs "PASS"). I tried to rebaseline all effected layout tests
> (for now on mac only), and the patch is about 6MB (Sorry I overlooked the
> "Bigfile" option when I submitted the patch, so I split it into 4 parts).
>
> My questions are:
>
> 1. The bugs violate the standards and cause some site compatibility issues.
> However, because the bugs are old, some web developers might treat them as
> features and depend on them, so fixing them might break some existing pages.
> Is there any existing policy about this problem? Are these bugs worth
> fixing?
>
> 2. What's the best practice to deal with a patche containing many updated
> layout test expectations? Is there a good way to rebaseline the effected
> tests on all platforms?
>
> Thanks,
> Xianzhu
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How to convert character offset into VisiblePosition?

[Xiaomei Ji]

Hi Dan,

Thanks for your quick feedback.
Please see my comments inline.


On Wed, Jun 2, 2010 at 9:30 AM, Dan Bernstein  wrote:

>
> On Jun 1, 2010, at 10:48 PM, Xiaomei Ji wrote:
>
>
> Given a DOM Node and an InlineBox, is there a way to convert the character
> offset within this InlineBox to a VisiblePosition? considering bidi/RTL.
>
>
> Not sure how being given a DOM node helps here…
>

The node is just for constructing the position.


>
>
> Using  node in the following example as an example:
> abc ששש def שנב abc סטז
> uvw זזז xyz
>
> Assume the  node is node A, using "(node, offset)a" to represent the 
> node and offset information of Position when caret is before character "a", 
> the position information are:
>
> .. (A, 4)a(A, 5)b(A, 6)c(A, 7) (A, 0xb)ז(A, 0xa)ט(A, 9)ס(A, 8).
>
>
> Given the  node, the InlineBox representing " abc "(with surrounding
> spaces), and character offset 5 within the InlineBox, is there a way to
> convert offset 5 into VisiblePosition (A, 0xb) (not (A, 8))? which means
> when caret is placed after the 2nd space in " abc ", the visible position is
> (A, 0xb).
>
>
> I don’t think there’s code to do this—hit testing code will just choose the
> DOM offset that corresponds to the line box you hit—but how about something
> like this?
>
>
>1. If the offset is not at the edge of the text box, then just map it
>to that box’s text node
>2. Otherwise, if there is an adjacent text box on that edge, and it has
>the same direction as the first text box, just map to the first text box’s
>text node (or, perhaps you should look at the bidi levels of both boxes and
>choose the one with the higher level?)
>3. Otherwise, of the two adjacent text boxes, choose the one whose
>direction is equal to the block direction, and return an offset into the
>chosen box’s text node, corresponding to the edge
>
>
> Does this cover all cases?
>

Looks like it works. I tried pure LTR text, RTL text, and mixed text in RTL
div, LTR div, div with span having the same direction, and div with span
having different direction.
Except one case it does not work correctly (neither arrow key works
correctly).
abc ששש def שנב  opq סטז  uvw ששש xyz
Note: there are 2 spaces between "שנב" and "opq" in  node.

The position information of the span node are:
(node, 12)ז(node, 11)ט(node, 10)ס(node, 9) (?)o(node, 6)p(node, 7)q(node, 8)
(node, 3)ב(node, 2)נ(node, 1)ש(node, 4)
Note: I am not able to place caret before 'o'.

When offset is at the left edge of text box " opq ", the chosen box will be
text box " opq " since it has the same directionality as that of its
enclosing box. The computed position will be (node, 4) since 4 is the min
caret offset of text box " opq ".
It is wrong because (node, 4) is at the right edge of text box "שנב".

When there is no extra space between  "שנב" and "opq" in  node, the
computation works correctly.


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